In conversations with @simulacracid and @arobertlong about the Stellar Mesh one of the repeating ideas is that web browsers have crossed over into unmaintainable messes because they work so hard to be everything to everyone. How can we give the web a break?

This mess drives consolidation. There are exactly two organizations with the resources and will to maintain a "full" web engine so we effectively have two (~incompatible) options: Google Blink and Apple WebKit. Luckily Google allows others (e.g. Microsoft) to use their code.

One way to give the web a break would be to hard fork Blink and delete features that aren't in some vision of "the web". Most of us can think of a list of APIs that we would can. WebGL and now WebXR are the ones I hear about most often but most web folk have a list.

Another way to give the web a break is to pick a type of use that creates a mess in general purpose web browsers and create a similarly open system that is complimentary instead of compatible. For the Stellar Mesh idea, that type of use is immersive XR experiences.

Another way to give the web a break is to admit that it no longer works to have "one engine to rule them all" and redefine a web browser as a lower level shell into which we dynamically load ever-changing, specialized, and hopefully smaller "engines" than Blink.

The general way this would work is that a web author would declare the specialized engine on which they'd like their page to run. The (now thin) web browser would fetch the engine and then run both the page and the engine in a sandbox.

I write XR pages so I'd specify the Unity engine (no JS, no DOM, thank you very much). My bank would specify a tiny (relative to Blink) DOM-oriented engine because it works well for them. In ten years web creators would specify some futuristic flimflam that I can't even grok.

The standardized APIs that a web browser implementation needs to maintain simplify (mostly leaning on the OS) and move down-stack. They become more like WASI and less like the DOM APIs. It actually makes sense for OS teams to maintain and ship this!
https://wasi.dev/ 

One of the outright failures of the web is that accessibility is a joke; a nice-to-have for most teams. We made the mistake of having a "default" way to access content, controls, and context (flat, visual, page in window) and try with WAI-ARIA to backfill semantics.

This is baked into Blink and WebKit and with "one engine to rule them all" there's no path to actual, no-fooling universal access. We'd "break the web" and we don't do that (much). Decoupling the engine and the browser is the (last?) opportunity to fix that terrible mistake.

There are downsides to decoupling engines from the browser. Like we currently see fat and slow JS bundles we'll see fat and slow engines. There are some things we can do with pre-loading, pre-compiling, and caching but the bits must flow where they didn't before.