It is almost universally understood in the vernacular that when someone says "OS like Linux", they mean "A non-specific probably-GNU-Linux distro." The space where that understanding is excepted is when discussing actual kernels.
Much like the vernacular meaning of "A computer" usually includes mouse, keyboard, and monitor, even though those parts are completely interchangeable and you can run a computer headless with remote access (or no access at all, the computer simply churning through whatever program it was pre-loaded with and outputting to some exotic peripheral, or maybe even simply generating heat in the corner with no human-discernable output at all).
GP's argument is that Linux (in the sense of what was actually written by a relatively small team in 1990-s) is a kernel - not a full-blown OS, of which there were many at the time.
Applying to the topic about browsers, it's as if you were planning to build a skeleton of a browser, without those equivalents of GNU-tools-to-complete-distro-starting-with-Linus's-kernel. But Linus was able to get parts from GNU project - where would you get necessary parts to complete the browser which you're writing?
I'm hyperbolizing. However I believe the point of the article is that it's actually very hard to build a usable, full-blown browser - not a proof of concept, Unix-kernel-equivalent. Toys for playing - maybe; production quality, so somebody would use it day to day - unlikely.
I'm more interested with where do we go from here. Should we start with fixing W3C standards so that they would permit a simpler implementation? Or are there other ideas?
I'm not sure there's a path forward with fixing W3C standards to be simpler. Once a standard exists and has buy-in from multiple parties (in this case, browser implementers and website developers), it has lock-in; if a simpler standard isn't backwards-compatible with what's already out there, the implementation of the simpler standard isn't compatible with content on the web, and if that content is, say, Facebook, nobody will care about the simpler standard.
OpenGL ended up doing something like this with the death of the fixed-function pipeline (first via OpenGL ES omitting it from the parent standard and then via OpenGL's main standard marking it deprecated and killing it for all cards that don't mark themselves backwards-compatible). But the consequence of this is that some 3D apps simply won't work with some graphics cards (a situation users are accustom to in the brutal Wild West of high-performance gaming, so those incompatible cards aren't crippled in the marketplace for being unable to run older games and such).
Perhaps one could describe a simpler w3c standard that is an orthogonal set of "core" features, and then implement handlers atop that standard for all the legacy crap that browsers can do today? It'd be a hell of a project to even start identifying what the core feature set and architectural layer would look like.
The web as a platform has done this before for things like ActiveX, Java applets, and most recently Flash. Collectively, developers decided they were overcomplicated rubbish and abandoned them.
Thanks. So, practically, developers can move capabilities deemed non-essential into plugins, which are more problematic to install, so end users would apply pressure to site authors to avoid certain technologies. Hm. History says it can work.
That fails to work if what you drop support for breaks Facebook. Newgrounds never had the clout of Facebook, but dropping Flash gutted them. In a world where Newgrounds had become Facebook, Apple would have invested in Flash instead of killing it.
Cynically, the users who need such websites shouldn't use that browser. Fewer users, but potentially more technologically literate ones. Sounds like a win-win to me.
I don't think the internet is well served by a monoculture of user agents all speaking HTTPS (and only HTTPS) and trying to cram everything under the sun into HTML/CSS/JS.
My personal preference would be for more specialized agents speaking protocols designed for their use case: email over SMTP/IMAP (or JMAP!), newsreaders with RSS, chat on XMPP, etc, content browsers with some limited markup language, maybe games and fat apps loaded as binaries to a sandbox VM.
Maybe this is unrealistic and that time is passed, but the internet used to work more like what I've described. Today, more and more things are just a JS webapp that only runs properly in Chrome.
> It'd be a hell of a project to even start identifying what the core feature set and architectural layer would look like.
If browsers are still "browsers" and not "kitchen sinks in disguise", I'd - still - identify 5 major parts: 1) networking 2) parsing (HTML/CSS/JavaScript - others?) 3) DOM rendering (images, video, audio too) 4) JavaScript engine and 5) controlling UI on top of all that.
Thinking out loud: what about a transpiler project that goes from backwards-compatible current standards to stricter but more implementable standards. The idea is that you run everything you receive through this before your browser starts parsing it, so that you can support a larger part of the web while implementing a much smaller set of standards. Like Babel in reverse.
Of course, there's still a monoculture in transpilers, but at least there could be more browser competition after that point.
The statement holds; although it was arguably a bit unusual that Linus only built a kernel, it was just one more unix-like kernel in a world where that wasn't exactly rare. (Which, granted, worked out well with GNU's efforts to build a whole OS that did far better a userland and kinda dropped the ball on the kernel)
