What even is a web browser?
A number of things (some of which I will share later this month) have me thinking about this question. It probably seems silly at first, but it's suprisingly kind of interesting - and maybe important question.
The other day, Chris Coyier wrote a post called What is Chromium without Chrome on top that hit on some things I've been thinking about/discussing recently too, so I thought I'd share a bit more.
To the vast majority of people, a web browser is - you know, "the button for the internet". It's that icon that you click to somehow navigate the web. I mean, what could be simpler?
Within the web community, we break this down pretty commonly into "engines" and "browsers". The common description of which is roughly something like...
The browser provides the window(s) and interface (the 'chrome') around the stuff inside. The actual rendering of the website inside the window is handled by the rendering engine.
However, this is actually kind of incomplete, and quite a lot of interesting and important conversations and debates require more. Sadly, as you dig into it - things can get a little overloaded and confusing.
The un-browser
Most browsers can be launched, from the terminal, in a "full screen" mode. Many can be launched in a true "kiosk" mode, even. In both cases, with none of the typical "browser" user interface parts at all. What if someone released a product that only did that.... Is that still a browser?
Given a good start page (any popular search engine, for example), the web would still work pretty darn well. If there is some fundamental need for something (back in history, seems important), providing it via a typical window chrome with a URL bar and so on isn't the only possible way to provide that.
If it isn't a browser - what is it? Perhaps the closest answer is that it is a WebView.
Web standards, platform neutrality and good rendering are super useful to just about any program. Many "regular programs" from Sublime Text to Slack contain some kind of WebView to do all of that. WebViews (or any of the few things like it) are often called "embedded browsers".
But... is a WebView really a browser? Hmm... Tricky.
No True Scotsman
You might have had that experience where you are in some "regular program" and clikcing around, reading - and everything is pretty much fine. And then you click a link to read something and are asked to login. But wait... you are logged in, in your browser! That kind of stuff is painful for users, and some people say that that is because it isn't a "real browser". However, that this is what happens if you have more than one "real browser" installed too. An important distinction here, perhaps, is the concept of a "default browser".
But now we get into a very uncanny valley and a lot of intersting challenges and further distinctions.
If you download Firefox, launch it and don't make it your default browser, clicking a link from a page within Firefox still opens in Firefox. You, as a user, chose to browse with Firefox right now.
That is, sort of what is happening when you use something with an embedded browser too. You've chosen to browse with, say, Facebook Messenger - and, is it a browser? Kinda?!
We really haven't entirely sorted this out.
One common technique when making a "real program" with a WebView is to just not have it handle HTTP requests at all. All of the "program stuff" uses some local, non-HTTP scheme. When a user clicks a regular HTTP-based hyperlink, then, most GUI operating systems receive the notification of an effort to open a HTTP URL. To deal with this, they launch the program registered as the default handler for that - the default browser.
Are you a browser? If you are, you have to tell me.
In other words, applications built like this have to decide: "should you be handling this?" and provide an answer to the question "are you really a browser?".
Nearly all "regular programs" built with WebViews don't actually claim to be a browser, and don't offer the ability to be registered as the default browser. The first question though is often stickier - especially on mobile.
"Should you be handling this?" is often a kind of tricky question. They are after all, mostly capable of rendering anything your "real browser" can and there are valid reasons to open their own content, like documentation, that actually lives on the web, at least. The perceived cost of leaving the experience on mobile is also much higher. So, it gets tricky.
But operating systems vary too, and they change over time, learning lessons and adapting along the way. It's kind of hard to pin down.
Default WebView
Since WebViews are super useful for all apps, every GUI OS/desktop today also ships with a default WebView that programs can use. That makes a lot of sense, because there's no point in everyone independently packing up and managing their own - and this way you could share logins and stuff.
It makes even more sense when you realize how intertwined the OS and the rendering engine are.
In fact, "engine" is a better metaphor than the way we usually describe it. An engine, all by itself, can't do anything. It only has potential. It needs to be hooked up in all directions: Something to provide it fuel, something to transfer its power into useful motion, and something to govern that with input.
Web engines aren't different in that respect - they provide consistent abstractions for features but need to be connected in all directions to the OS. Each of the engines have different philosophical/design differences about what needs to be hooked up, or how.
Form controls are one example. Some controls are always provided by the OS, others, in some engines are provided by the engine itself. WebSpeech is another. WebKit, for example supports WebSpeech - but some ports of WebKit don't. Chrome is similar. Speech itself can be wired up in many ways. In some browsers this wires to a service on the Web. In some browsers this uses a local speech engine packed up with the browser. In some it wires up to the OS level speech engine. In some browsers it uses one as a preference and the other as a backup, and so on.
So, WebViews (or evolutions of them) are an even higher level abstraction. They're more like a kit car which is pretty much drivable - it just doesn't look like much.
Whose job is it anyways?
There are a lot of choices that go into all of this. Think about it: There is no keyboard on some devices. Whose job it is to present a virtual keyboard? The "easy" answer is that the OS itself fundamentally needs that concept so it can offer it as a service. That's pretty cool until the site decides you need animated gifs or emjoiis or a particular keyboard layout, etc. Actually, some apps kind of like having control because it means that all of their users have a more similar experience, regardless of mobile OS.
The OS uncanny valley
So... OSes pretty much always also ship a default browser, and you can change what the default browser is. Lots of apps use WebViews, so the OSes provide a default WebView that they can use instead of shipping their own.
At some level, it would make sense if the default browser itself used the default OS level WebView. That would make our initial statement almost true: The browser handles the stuff on the outside, and the WebView handles the stuff on the inside.
Wait... But... Do they work that way?!
¯\_(ツ)_/¯
Recently Duck Duck Go announced that they would do something just like this - depend on the OS level default view. That is... kind of an interesting take.
The ecosystem interplay
There is a really interesting aspect to all of this: The Duck Duck Go version kind of leans into what others are upset about in iOS. Basically, "That's not the choice of a browser - because there is only one rendering engine allowed".
But... is it? I mean, everyday humans don't really choose engines. They choose something higher level: A device. They use what that device makes available to them unless it gets real bad. IE won the first browser wars because they were the default, and they more than met expectations. There was no need to go elsewhere - you had, at the time, the best browser. A browser with a synergy with the OS too.
People only began looking beyond IE when lots of stuff just stopped working. Is it great that there was a competitor who could step in on the same OS - sure. Definitely but a lot of things have changed too.
Contrast this with Android today. The default browser has the lion's share for lots of reasons - some of them are pretty good ones even. Most of what isn't that is still Chromium based. Gecko is technically "there" but it exists only at a non-trivial cost which ultimately hasn't amounted to much in terms of users. I guess this is important for Mozilla because they don't have a default OS, but you'll note that there's not a WebKit option there (yet), and there wasn't an Edge option when that was it's own engine either - until sharing the burden through Chromium made that a lot easier.
If tomorrow, Google disbanded the Chrome team though - one has to imagine that the natural successor on Android is still chromium based.
...If there is a successor.
Chromium is bordering on 30 million lines of code - it takes an army of unparalleled size, 80% of which today is Google committers. Only a company of astonishing size and means could step in and fill the gap just to take it over and keep the lights on - Microsoft, probably, is our best hope - but I wrote lots of words around those kinds of worries and possibilites in my post Webrise
From another angle ...
Of course, there are those that claim that WebKit is too bad and people would choose differently on iOS if they could. I am biased, of course, but I don't see any anecdotal data that the general public actually agrees. I know very few iOS users who aren't engineers who complain about Safari - and I know very few engineers who won't admit that WebKit has made huge strides in the last few years.
If there's a random person I know who has installed another browser on iOS, it's not been about shortcomings, but everything to do with seamless integration with other Google products they own, or the payment model on Brave, or something.
What's interesting to me about all of this is that one can think about it from another angle: While it's easy to agree with diversity of choice - keeping a competitive market of actual choices around in the first place is maybe even trickier with the current model we've built. It's interesting to think about how differently things might have played out if everything had followed the "browser is built on the OS level default WebView" model, where those WebViews were spaces of great collaboration and flexible architectures allowing differentiation.
The cost to making the standard stuff would go way down - the cost toward providing the actual products would go way down. As long as there is variety of OS (there definitely will continue to be, with so many devices and uses floating out there) there would be a diversity of engines, and competition on more or less equal footing at the space of the stuff around them.
I'm not suggesting that's the way it should be, but -- it's kind of interesting to think about.