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.
A body of web standards that they lobbied for and to be in the form that they are...
Heh. Now you have two problems. One of them is JS, which was a mistake in the first place and now we can't get rid of it for similar reasons.
what exactly is the benefit of having a byzantine set of standards in the first place? Like why not just have a standard and not dick around with it?
>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.
I wonder which company grew their browser marketshare through ruthless advertising on their already-a-monopoly search engine, then began to compete with the other browsers by purposefully breaking their websites on other browsers (all by accident of course, hundreds of times), then began to implement their websites with alpha versions of their proposed web standards that only their browser properly implemented, leaving other browsers with a dreadful polyfill that had horrible performance on purpose, only to then basically force their proposals through the web standards body that they had made because they couldn't control the W3C, leaving everyone having to follow such great APIs as WebUSB or other badly-implemented-but-only-by-them flavor of the day API, all the way to forcing dreadful protocols like QUIC and HTTP/3, justified by their need to save up three bytes per request and making the user's experience better while they serve 2MB of tracking javascript and ads through DNS-cloaked servers.
I think the name was like... Gogle ? Golgool ? Can't remember.
As an example, Google holds 18 of 39 seats on the Web Assembly Working Group. This means that if they whip their seats, they only need 2 additional votes to pass anything.
> we can’t do a grand reboot
(inb4 XKCD) Yes, like a new standard.
They got exactly what they wanted, but its not their fault?
If there are things browsers can't do natively, then someone will build their own way to do it and then you end up with non-standard implementations.
It's better to get everyone on the same page and develop an open standard.
> 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.
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?
The first step in saving the web needs to be to stop adding so many new standards that are only needed for "apps".
That's making big assumption: that decisions are made by votes, and those votes are done purely based on participation.
And they're not. For decisions within the WG, they're normally done by some notion of rough-consensus (frequently, lack of significant dissent); actual votes within most WGs are relatively rare.
For decisions at the W3C level, it is admittedly done by votes, but it's one-Member, one-vote, so in that case all W3C Member are equivalent in power: Google, Apple, Microsoft, Mozilla all have their votes count as one.
This is pretty normal within industrial standards development organisations: voting happens at an organisational level, representing the industrial members, not based on individuals participating from those members. (There certainly are negatives associated with a disproportionate number being from a single organisation, but that's mostly related to disputes in meetings ending up with one individual arguing against ten.)
That is the standardization process. The W3C won't ratify a standard that does not have draft implementations in the wild.
Making it the default and making the fallback only reasonably accessible by installing an extension that will rewrite your links (that all send back to the alpha-using version), causing every browser that isn't Chrome to slow down to a crawl while you happily display a "Hey, did you know the web is faster with Chrome?" isn't working through the standardization process, it is weaponizing it to sabotage other browsers.
Anyone who writes a compiler or engine for WebAssembly is going to have to deal with the mess of web standards, unfortunately.
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.
Adobe / Macromedia started from the designer perspective but Flash soon became a goal of its own because Adobe wouldn't give up that marketshare.
Only now all parties realise it's too big for one company to own. Well except Google perhaps.
Users and website creators wanted these features and Flash was the way to do them.
Sure, other technologies like Microsoft's Silverlight allowed similar things, but Flash was so widely used it could be relied on to offer these features.
Even now things like clipboard access aren't supported in the same way across all of the major browsers.
I think the disconnect was more with designers. They wanted visual tools back in those days and had no time for CSS and JavaScript. Adobe/Macromedia gave them what they wanted and also entrenched their commercial position this way (which Adobe already had in the paper publishing market!). It took a long time for the graphical guys to come on board with the open toolchains.
Macromedia wasn't a bad company as such as they did make the excellent Dreamweaver which did promote open standards, but Adobe corrupted them badly.
The problem is not in the lack of browser rendering engines, but the lacking innovation and product features of the browsers running these rendering engines.
And I recall it enabled a progress bar, too.
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.