zlacker

  > 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+(OP)
Accessibility and UI inconsistency are going to be serious problems with that. And UI inconsistency's already the curse of the Web—definitely not something that needs to get worse.

>>andrek+(OP)
I feel like the point of standards to to provide more structure on top of an execution layer. Think about the browser's file picker dialog. Now imagine if every browser had their own file picker API, and each website only bothered to support one of those APIs. Now as you browse the web, the file picker only works on some websites but not others

>>andrek+(OP)
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

>>andrek+(OP)
IMO No,

The web works because of HTML. HTML is scanable, searchable. It's what allows search engine to exist at all. HTML enables extensions. HTML is also generally responsive. HTML allows uses to be in control (see extensions). HTML allows uses to copy and paste and even for sites that try to prevent it users can go into devtools to get the text. HTML supports all of unicode and so is inclusive across all languages.

A world in which the browser is just an executable environment and people make random UIs means pretty much all of the above disappears. No more searching for content, no more extensions to block ads or block distrdacting feature. No more extensions for language translation, braille, accesabiltiliy. No more all language support, only whatever each framework decides to support, every page with different limits at different versions of the frameworks.

>>andrek+(OP)
QuickJS (and various others) demonstrates that small teams can create fast and efficient JavaScript engines that comply with standards. Even though v8 is faster, it spends an order of magnitude more engineering effort for that marginal benefit.

>>sicp-e+RS
A Javascript engine is pretty far from a browser. It's too much work to write a browser even if you reuse the existing V8.

>>yencab+g14
I agree. The context of this comment is the user asking if Web assembly will make that effort easier. I don't think it will since getting good JS is already reasonable.

>>sicp-e+eI5
Yeah, it won't be the wasm itself that makes anything possible.

What might happen is that it ushers in technically-unrelated fashions, such as standard WASI interfaces to something slightly less insane than DOM+Javascript.

Just Canvas-over-WASI isn't the answer because of accessibility, but something like it might happen.