Browser engine versioning standard, allowing breaking changes, moving the web more forward without the cruft

I think it’d be neat if there was a standard that allowed browser engines to move forward with breaking changes (or any changes) under the concept of “versions”.

Websites could specify which version of features they use. Engines could by default ship with the latest version. If a website is using an older version of features, then the browser prompts the user to install those older features.

This could allow, for example, things like the problematic new EcmaScript class fields to be fixed in a way that newer websites could specify that they use that version of the engine, while older browser continue to use a previous version.

The only thing back-ported to older versions are security fixes (and bug fixes if vendors care enough).

How would that look like? Maybe a root-level entry in manifest.json or something could specify a webVersion field, or something.

As specs move forward, a snapshot of all the specs is created at some version number. This includes the spec’d state for HTML, CSS, DOM, EcmaScript, etc.

This would help to reduce the size of browser engines while bringing the web forward. Eventually, hen old websites are no longer visited and old features are no longer used, the average user will not download that version of the engine. They’ll only by default have the latest version with latest features, and sometimes they’ll need to accept a version download for websites still using older versions.

Perhaps a browser would ship with the most common versions still in use. There’d be some statistical threshold for determining which versions to ship with by default. Etc.

New versions doesn’t mean removing old features (though it might). A new versions might remove bad features of the web, or only make some fixes to bad parts.

A main downside of this would be that more code has to be maintained by vendors.

Anyway, I am dreaming of a better landscape.

1 Like

I’m not sure that a prompt to install an older version of the engine when visiting older sites is a good user experience for the web. Would people even understand what is being asked?

If the prompt said something like

This website requires older browser features to be installed. Proceed?

it would be understandable.

Maybe it would have more information, like

This website requires browser features v3 to be installed. Proceed?

How can we bring the web forward without all the cruft? It isn’t scalable to simply keep adding more and more web features. Just imagine if we continue at this pace how the web will be in 20 years.

1 Like

We deprecated Flash. Surely we can do this with builtin features too.

Removing features is one thing. I am also suggesting maybe there is a way to manage the (older) features, to allow them to be optionally installable. Perhaps it would be based on snapshots of the browser engine. Rather than modifying browser implementations so that the code has a bunch of conditional checks, it would instead download snapshots of the engine code, where a previous version may contain entirely different code that may have existed prior to a total refactor (for example).

I have a feeling that browser vendors would not want to do this. I remember a blink-dev discussion where a legacy feature was used by 0.08% (IIRC) of web pages, and they were hesitating to remove it. Compatibility with the legacy web is like a law of physics to them, unbreakable.

Are you aware of how long it’s taking to remove Flash? Or how long it took to remove Java for that matter? It took about five years (2013-2018) to remove Java applets, and Flash is still on the tail end of its three-year deprecation timeline scheduled to finalize December 31 of this year. (For context, removal of both of these were a massive, genuine necessity to protect end users, not just little nice-to-haves for browsers.) Even on the JS side, it was a struggle to ensure that let[x] = 1 could be repurposed from indexed assignment to a variable declaration, and removing arguments.caller itself was a monstrous task that started back in ES5 and took until ES2017 for them to finally be able to pull the plug.

Removing features is nearly impossible on the web, and even the biggest hacks generally have to be maintained. And not only that, browsers will still have to implement them for possibly years to come. Tf you want to see how well it works out in practice, just look at how well Firefox’s old JS versioning attempt worked out (spoiler alert: it didn’t and they dropped support for it only a few versions in, before it even really took off).

Keep in mind 0.08% of websites is still almost 1.5 million websites. And that’s just websites, not web pages. 0.08% of the web is a lot of web, and do you really want to unilaterally break millions of pages and likely annoy or anger millions of users?

You know how in JavaScript new features enable the removal of others by means of introducing a new mode (f.e. “use strict”, or modules)?

Maybe we need two things:

  • A standard way for browsers to introduce new modes (not just for JavaScript, but for HTML/CSS) that can introduce new features while dropping others.
  • An official way to deprecate the old features (old modes) after some time (even if that happens to be spec’d to 3 or 5 years).

Could that be possible?

do you really want to unilaterally break millions of pages and likely annoy or anger millions of users?

Well I’d like to avoid it, but maybe that’s part of the problem.

Libraries need to accept that some people dislike changes, but changes are required to bring libraries to a new and better future. Maybe the web needs that, and can accept that some few portion of people will not like it.

Maybe the annoyance to that fraction of users will ultimately make them happier and everyone else happier in the longer term?