LWN: Comments on "DeVault: The reckless, infinite scope of web browsers"

DeVault: The reckless, infinite scope of web browsers

ibukanov — Sun, 22 Mar 2020 17:36:46 +0000

One of the target market in 2000-2002 for that Java browser was embedded systems with little memory on devices with no hardware memory protection. So one needed software-based memory protection that JVM provided. As long as one stayed away from JDK standard libraries except for very basic stuff it worked surprisingly good. It was even possible to handle OutOfMemory gracefully. The interesting thing was there were no problems with GC pauses. The heap was relatively small and filled mostly with image bitmaps and arrays with cached network data, so even a simple GC from JDK 1.1 could handle that.

DeVault: The reckless, infinite scope of web browsers

gray_-_wolf — Sun, 22 Mar 2020 12:51:46 +0000

> What the heck is this about?

Firefox might be debatable (even though it has it's share of questionable choices) but chrome, which sends uniq id to multiple domains under google control? I think he's spot on on this one.

DeVault: The reckless, infinite scope of web browsers

smoogen — Sat, 21 Mar 2020 15:38:52 +0000

Yeah agreed. Java had a HUUUGE amount of basic HTML and layout built into in the get-go. That made writing browsers in it much easier than our C base as a programmer we had did in 1996 by rewriting to 'spec' in Java 1.2 what we had with Enhanced Mosaic. [I think it also supported more of DOM than the browser did due to Java builtins] I was really sold on it but its memory usage at that time was not good and the early Java GC made emacs garbage collection look performant :). So after going to 3-4 pages you could start hearing the swap partition smoking in any of our systems. That said, I can only guess that by 2000 though it was a lot faster and the stack traces would be much easier to deal with.

DeVault: The reckless, infinite scope of web browsers

ibukanov — Sat, 21 Mar 2020 15:06:25 +0000

I worked on Java-based browser in 2000-2002. We supported most of CSS and DOM (missing parts were not relevant to Web) and all JavaScript using rhino. The team was like 8 programmers and 3 QA. I believe Java was very relevant to the success. It was so nice to get stack traces for bugs without crashing and GC greatly simplified the design.

DeVault: The reckless, infinite scope of web browsers

zlynx — Fri, 20 Mar 2020 22:51:57 +0000

Edge, heh.

Yeah they did a pretty good job. I made a point of using it on my Windows laptop for work and my personal Surface tablet. Because Edge was the underdog.

Weird to think of Microsoft being the underdog but they were. Even relatively non-technical people seem to download Chrome first thing with a new computer. Probably because they hit Google services and get the Chrome prompt.

DeVault: The reckless, infinite scope of web browsers

BenHutchings — Fri, 20 Mar 2020 22:36:04 +0000

Aside from the other errors pointed out, a lot of the W3C specifications are actually irrelevant to web browsers - Web Services, Semantic Web, etc. are for other applications.

DeVault: The reckless, infinite scope of web browsers

flussence — Fri, 20 Mar 2020 22:04:31 +0000

> "Tossing out the Web", "don't let the Web compete with native platforms", and "everyone use Chromium" would all make things worse.

Things are *already* that bad, thanks to a thousand walled-garden desktop apps (and major desktop environments) using Electron, QtWebEngine, CEF or whatever. People see Google's engine on the desktop, on the phone, and on the web, and that's what they learn and build for.

Google saw how “x86 everywhere” obliterated finger-wagging mainframe manufacturers in the 90s and replayed that strategy perfectly, against competitors who thought desktop developers are an irrelevant demographic.

Everyone's already forgotten why IE6 won: it wasn't just because they yelled louder.

DeVault: The reckless, infinite scope of web browsers

pizza — Fri, 20 Mar 2020 00:30:18 +0000

> You can branch or fork it to make your changes, but Google can then impose whatever maintenance costs on you that they like, as long as you want to keep receiving updates from upstream.

What Google wants only matters because they are funding the overwhelming majority of the work going into Chromium and its underpinnings.

When your collective band of developers out-contributes Google, then you get to call the shots. If Google doesn't cooperate to your liking, then fork away, call it something else, and proceed to pretty much ignore what Google wants. (In other words, do exactly what Google did in forking Blink off of WebKit. Or what Apple did in forking WebKit off of KTHML)

Of course, to accomplish this you'll need tens of millions of dollars in yearly funding, a strong funnel for developer mindshare, plus a natural monopoly you can leverage to "strongly encourage" end-users to use browsers featuring your engine. Nice and simple.

DeVault: The reckless, infinite scope of web browsers

rgmoore — Fri, 20 Mar 2020 00:26:46 +0000

It's true that browsers are the most resource-intensive software for a lot of people, but that's because a lot of people do most of their computing in the browser.

As a practical matter, web browsers have gone from being viewers for text and graphics into what is essentially a guest OS capable of running sandboxed applications. Naturally, their complexity and security requirements have grown to match. In much the same way that there are only a handful of independent implementations of a desktop OS, there are now only a handful of independent implementations of a web OS.

DeVault: The reckless, infinite scope of web browsers

roc — Thu, 19 Mar 2020 23:42:31 +0000

> Chromium is controlled by Google in only in the sense that they are willing (and obviously able) to outspend everyone else combined,

Google also controls Chromium in the sense that they control all the infrastructure, branding etc and don't have to accept any commits that they don't like. You can branch or fork it to make your changes, but Google can then impose whatever maintenance costs on you that they like, as long as you want to keep receiving updates from upstream.

It's true that you could fork Chromium and diverge irrevocably from upstream in some or all areas, and in that sense Google doesn't "control" that existing code, but then it's far from "a single open implementation usable by everyone".

DeVault: The reckless, infinite scope of web browsers

roc — Thu, 19 Mar 2020 23:37:36 +0000

> Chromium is controlled by Google in only in the sense that they are willing (and obviously able) to outspend everyone else combined, and nobody else has a hope of keeping up.

It's not that bad. Google does a lot of "throw stuff at the wall and see what sticks" that other vendors can ignore. Mozilla and Apple have much smaller teams yet have been mostly able to keep up. Apple could certainly keep up if they were willing to invest more, and not a crazy amount more.

Edge actually did an OK job of checking off features, but that they couldn't get the marketshare/mindshare to overcome Web compatibility issues and it cost a lot of money. I guess that's why Microsoft canned it.

DeVault: The reckless, infinite scope of web browsers

roc — Thu, 19 Mar 2020 23:28:29 +0000

It was a small but very good team. It's bigger now but still relatively small and very good.

"How much time it took"... to get to what? It wasn't very Web-compatible at the beginning, and would not have been competitive as a stand-alone product, but that didn't matter *too* much since Safari was the default browser on Mac and Apple fans would use it no matter what, and they didn't need users to survive as a product. Then the iPhone took off and because Webkit was/is the only engine allowed on the iPhone, they had guaranteed market share, which then drove Web compatibility. Google adopting Webkit for Chrome was the icing on that cake. The main take-away here is that Webkit rode Apple advantages in a way that would not have worked for an independent browser vendor.

A couple of strategic decisions worked very well for them along that journey. One was that, instead of competing head-on with IE for Web-compatibility and features, or with Firefox on Web standards correctness, they focused more on performance, reasoning correctly that if you get users somehow then Web compatibility will take care of itself. (They did manage to portray Webkit as highly standards compliant by sprinting to complete various "Acid" tests by any means necessary, e.g. by implementing the one SMIL element Acid3 used.) This performance focus differentiated their product and made it more attractive to embedders, and eventually Chrome (Again, an independent browser vendor trying to follow this strategy probably would have died for lack of users.) Another was that instead of providing a whole browser --- networking, UI widgets, etc --- their initial model was to depend on OS components as much as possible, which meant less work for their team and an image as a more light-weight browser engine. Over time it's become clear that you can't actually use native widgets with CSS, and Web-compatible high-performance HTTP/TLS/caching is so difficult you really need one designed for a browser, but that happened later.

DeVault: The reckless, infinite scope of web browsers

smoogen — Thu, 19 Mar 2020 18:00:42 +0000

Many of us using konqueror in 2000 were quite happy if a page didn't render picture perfect to some other browser.. but to others it was a constant stream of support tickets I had to deal with.

Konqueror and other opensource browsers did a good job implementing standards which had been around for a while. You could get a HTML3.5 page in Konqueror but anything using the various non-strict 4.0 would look 'odd' depending on various tweaks and oddities which were in pages. You could also end up quickly with a page which was completely stuck in the top left corner in Konq but not in IE (and maybe just off in Netscape).

So yes a small team could create a browser in 2000... and I expect a small team could create a browser based off of say 2019 standards today in 2020. But whether they could not keep up with the constant changes.. that is another matter.

DeVault: The reckless, infinite scope of web browsers

sorpigal — Thu, 19 Mar 2020 09:54:38 +0000

All I'm hearing are laments that the browser has become the software platform for everything, and therefore requires APIs to support doing everything (and everything is a lot). As long as things stay open source and remain driven by published standards this is all to the good. If you'd told me in 1995 that the future of applications would look like a series of cross-platform, vendor-neutral (Google notwithstanding), open standards I would have told you that you were living in a pleasant fantasy.

I'm not saying this is the best possible future, but it's pretty nice.

DeVault: The reckless, infinite scope of web browsers

mgedmin — Thu, 19 Mar 2020 09:22:45 +0000

I would very much like to know how much work Apple had to do on KHTML to make Webkit, how big a team they had, and how much time it took.

I remember using Konqueror as my primay web browser a while back, some time around 2000. It was not bad! (I also used to use MSIE 5.5 in a fullscreen VMWare session, with my native Linux terminal windows floating in front. It also worked great.)

DeVault: The reckless, infinite scope of web browsers

pizza — Wed, 18 Mar 2020 22:51:58 +0000

> One big problem is that the only viable candidate for that single codebase is Chromium, and that is controlled by Google.

Chromium is controlled by Google in only in the sense that they are willing (and obviously able) to outspend everyone else combined, and nobody else has a hope of keeping up. Not even "billions in cash in the bank and a near-monopoly on the desktop" Microsoft.

> This actually helps everyone, including Chromium developers. Going to a single codebase eliminates that advantage.

While there are (mostly "bigger picture") disadvantages to a complete monoculture (although less so since we're talking about Free Software here) there are also significant advantages as well.

DeVault: The reckless, infinite scope of web browsers

roc — Wed, 18 Mar 2020 22:44:30 +0000

> a lot of people do most of their computing in the browser.

I should add "on desktop computers" which I assume is the context for the comment I was responding to.

DeVault: The reckless, infinite scope of web browsers

roc — Wed, 18 Mar 2020 22:42:56 +0000

There's so much wrong in this blog post. Start with the first paragraph:
> web browsers have been using features as their primary means of competing with each other.

Not at all. Users do care that the Web works in your browser, so you don't want to fall behind on platform features. Adding platform features beyond that does very little to increase your market share. What does increase market share is what Chrome rightly focused on at the beginning: performance, stability, security, marketing (especially via Google's prime Web real estate), and bundling deals (e.g. download Flash -> get Chrome).

> Browsers are the most expensive piece of software a typical consumer computer runs.

Depends on what you mean by "typical" but AAA game titles are far more intensive than regular Web sites. It's true that browsers are the most resource-intensive software for a lot of people, but that's because a lot of people do most of their computing in the browser.

> Web browsers are responsible for more than 8,000 CVEs.

Compare Web browsers to another application platform: Android. Android has 2563 CVEs.
https://www.cvedetails.com/product/19997/Google-Android.h...
Considering that 8000 number covers multiple completely independent products, and Android is just one product, I'd say browsers as a category are not obviously worse (or better). And Web browsers tackle a harder problem: safely running content that the user doesn't trust at all.

> browsers have also been free to stop being the “user agent” and start being the agents of their creators instead. Firefox is filling up with ads, tracking, and mandatory plugins.

What the heck is this about? Firefox has taken major strides to block tracking over the last few years. Browsers, unlike competitor platforms, continue to provide powerful APIs so third-party extensions can manipulate content in all kinds of ways.

> The browser wars have been allowed to continue for far too long.

Allowed by whom? What exactly is actionable here? Is he calling for government intervention to make new Web platform features illegal?

Having said all that, I agree that the ever-expanding complexity of the Web platform is a problem. Some of that is due to technical errors, a lot of it is a reaction to the expanding scope of non-Web platforms. But there isn't an obvious solution that doesn't make things worse. "Tossing out the Web", "don't let the Web compete with native platforms", and "everyone use Chromium" would all make things worse.

DeVault: The reckless, infinite scope of web browsers

sroracle — Wed, 18 Mar 2020 22:24:56 +0000

> To be fair, merging work is one-time, but maintaining that work is forever. They're likely not so much declining the changes as declining to maintain the changes forever.

Drive-by fixes are common, but part of the beauty of open source is... you can onboard people to maintain those changes. This also incurs a cost of course. Now, I am not entirely familiar with the matter at this level, but I suspect the people who have a vested interest in making Chromium more portable would agree to maintain those fixes going forward...

DeVault: The reckless, infinite scope of web browsers

roc — Wed, 18 Mar 2020 22:24:42 +0000

There are serious problems with that. One big problem is that the only viable candidate for that single codebase is Chromium, and that is controlled by Google. Google has shown no interest in yielding governance to anyone else (e.g. an independent foundation). Eliminating all possible competition would increase Google's power dramatically (even starting from its current high baseline).

Another problem is that one of the things the Web currently has going for it is multiple implementations. You can distinguish "behaviour my app can rely on" from "Chromium bug" by testing your app on multiple browsers. This actually helps everyone, including Chromium developers. Going to a single codebase eliminates that advantage.

DeVault: The reckless, infinite scope of web browsers

pj — Wed, 18 Mar 2020 22:19:36 +0000

> when someone offers to do all the work for you and you still refuse to merge the changes... it strikes as not being very friendly or "open source".

To be fair, merging work is one-time, but maintaining that work is forever. They're likely not so much declining the changes as declining to maintain the changes forever.

DeVault: The reckless, infinite scope of web browsers

Jonimus — Wed, 18 Mar 2020 21:34:51 +0000

Why do people keep giving more airtime to Drew? He has been banned from more communities than I can count on one hand and even when he has half good points he tends to be such an arrogant donkey about them that it makes any real conversation on the topic much harder.

Yes he has a point here but he also ignores any of the causes of the complexity nor does he prescribe any suggestion as to what to do about it. Sure the web standards are huge, and web browsers are complex beasts but complaining about it without any discussion of why and how we got there is of minimal use.

DeVault: The reckless, infinite scope of web browsers

sroracle — Wed, 18 Mar 2020 19:34:04 +0000

> Of course, the difference is that the Chrome engine is open source and cross platform.

Google / the Chromium developers are diametrically opposed to accepting changes that make it more portable. This is kind of understandable when you consider the size of the project they maintain, but when someone offers to do all the work for you and you still refuse to merge the changes... it strikes as not being very friendly or "open source".

There is also the open question of whether all the various licenses of the software Chromium incorporates are actually compatible with one another. I believe someone was investigating this for the FSF but I don't think they ever finished.

DeVault: The reckless, infinite scope of web browsers

halla — Wed, 18 Mar 2020 19:13:01 +0000

And isn't it strange that in 2000 a small bunch of unpaid volunteers released KHTML, which is the basis of the most-used browser engine in the world? No paid developers, no paid Q/A people...

I think they did a great job, but I remember one of the developers proudly showing off the tibook Apple had given him "for his work on what had become webkit".

DeVault: The reckless, infinite scope of web browsers

yodermk — Wed, 18 Mar 2020 16:54:03 +0000

Well, many people have expressed concern that Chrome and others that use its engine makes for an ecosystem so monogamous that it will put the old IE to shame.

Of course, the difference is that the Chrome engine is open source and cross platform. IE was neither.

The main concern now would seem to be a vulnerability in Chrome, or perhaps Chrome going in a direction we don't want, and it would be nice to have a fallback. Firefox is that. Glad they're keeping up so far. It's good to have two engines, but having a third is probably untenable and unnecessary.

DeVault: The reckless, infinite scope of web browsers

juliank — Wed, 18 Mar 2020 16:10:13 +0000

> How can a new team possibly keep up with this on top of implementing the outrageous scope web browsers already have now?

They shouldn't. There is no reason for there to be multiple code bases implementing the same thing. There should be a single open implementation used by everyone.

DeVault: The reckless, infinite scope of web browsers

scientes — Wed, 18 Mar 2020 15:57:47 +0000

> With the HTML5 standard being a living standard that you can't code to anything but yesterdays version..

This is the thing that annoys me about the web the most. After support for Firefox 3.5 was dropped all concern for writing portable web was lost, to the point that YouTube doesn't even work with Firefox anymore if you don't send a Firefox user-agent (to which it then sends "compat" code).

DeVault: The reckless, infinite scope of web browsers

smoogen — Wed, 18 Mar 2020 15:56:17 +0000

I am trying to remember who said the original but it was something like "The Web is like the fashion runways in Milan. Something always new and never in vogue for more than a month. The browser is like the clothes factory trying to keep up. Somedays you are a Gucci and the next you are a ripoff Gucki"

DeVault: The reckless, infinite scope of web browsers

smoogen — Wed, 18 Mar 2020 15:51:15 +0000

In 1995, I went to work for a company called Spyglass who had a license for a product called Enhanced Mosaic. Our corporate executives goal was to compete against Netscape by licensing our product into every ISP and OS as a default browser. We ended up writing the core of IE1 and IE 2 (and that code ended up being in parts until 5 I think). Pretty much in early 1996, there were 8 developers and 4 QA people and 2 sysadmins doing the work on 6 different Unixes, 2 different MacOS, and Windows. The Enhanced Mosaic browser was meant to be strictly standards compliant so no Javascript, no <blink>, no a dozen other things Netscape and IE had in them. We figured doing that would keep our scope down and we could just provide a core set that companies would buy and module into other software...

The core developers realized the race was over for a small team when they got the specifications back after the first set of conferences and had gone on a visit to IBM, Microsoft and Oracle to see how many engineers they had to do work on browsers.. the smallest was 200 developers and 30 QA people.. Those 200 developers were struggling to keep up in 1996 with all the changes and 'non-approved' standards that everyone had made a defacto standard by being in IE3 and Netscape and ... trying to keep up with a small team was not going to happen in a general format.

The small teams which did end up producing browsers ended up doing ones which were always a sub-set of the standards and for a particular work case. You go outside of that and you would end up with horrible misrenderings or crashes onto other crashes.. I think the later explosion of browsers in the early 2000's was due to a sort of slow down in specifications as HTML-4.x was always in progress. With the HTML5 standard being a living standard that you can't code to anything but yesterdays version.. it is now back to needing mountains of developers and also just saying somehow 'sorry cant render that mate'