zlacker

>>dochtm+(OP)
The chromium-only web is not google’s fault. It is a symptom of a body of web standards that has grown wild to the point of being all but unimplementable.

Building a browser for the modern standards-based web is effectively impossible, because it costs too much, takes too long, and requires a standing army to keep up with.

We are at an impasse. The standards cannot be deprecated because they are used all over the web, and because they are used all over the web a new browser maker has little choice except forking chromium or firefox. Even microsoft couldn’t afford to keep adding all the standards to their browser engine. Normally the solution for a messy overgrown implementation is a grand reboot. But we can’t do a grand reboot of the web because we cannot get rid of the legacy. The only viable strategy I see to have real browser engine diversity without giving up on compatibility is moving as much of the standards implementation as possible into JS modules, so new browser makers can start with a small engine that loads the publicly hosted standards modules.

>>Joeri+Pc

  > Building a browser for the modern standards-based web is effectively impossible, because it costs too much, takes too long, and requires a standing army to keep up with.

  > We are at an impasse. The standards cannot be deprecated because they are used all over the web, and because they are used all over the web a new browser maker has little choice except forking chromium or firefox.

could web assembly be a way out?

the browser just becomes an execution engine, the current "web stack" becomes a (cacheable) downloadable library, meanwhile other languages, ui frameworks etc can flourish in the browser (now a much more simple thing that anyone can implement)

maybe just pie-in-the-sky?

>>andrek+sy
You cannot escape the politics of browsers by going to WebAssembly, because that's where WebAssembly was born. To use features outside of the original WASM spec, you have to consult a table and perhaps use a polyfill, like with CSS or JS features. Browser implementers have a large influence on the direction of the VM. For example, around a year into the original spec's development, it switched from being based on an abstract syntax tree to being based on a stack in a decision made by the browser teams [1]. A big change like that, a year in! The s-expressions in the text format are an artifact of that period, since tools already relied on their existence for optimization.

Anyone who writes a compiler or engine for WebAssembly is going to have to deal with the mess of web standards, unfortunately.

1. https://github.com/WebAssembly/design/issues/755