I completely appreciate what you're saying. Then I look at the level of crazy complexity and backward compatibility in html/css/js/wasm processing. And then I wonder: what are you actually proposing here?
People say HTML/CSS/JS/WASM is complex, but the Ladybird team is proving that a very small team can make a working browser in a few years. Thanks to the efforts of dedicated developers behind browsers, most of the web API, including rendering algorithms and such, has been painstakingly written out in detail.
Most people don't need insane levels of backwards compatibility or intense PWA support. That's just cruft that slows everything down and increases the attack surface for, to the user, no real gain.
Perhaps what we need is a lot of lightweight general-use browsers (based on a small number of engines) and then some heavyweight power-user browsers that can WASM to their hearts' content.
No, what you mean is 'most greenfield web dev projects don't need...'.
Most people do need those things, because assuming there's no civilisation spanning project to literally rewrite 90% of the web, without them their sites would break.
Sites most people visit do not require backwards compatiblity. And aside from like Google Docs, I doubt most folk are doing anything with WASM (outside plugins).
Look, in a world where Google subsidises browser development, this isn't an issue. We don't need to compromise. But if that funding stream disappears, you do have to compromise. And I'd argue a simple browser doing away with some of the more-complicated stuff would be (a) maintainable and (b) popular enough to pay itself back.
I think it could—it’s sort of the case on mobile—but it’s not a view I hold with the strongest conviction.
Large numbers of users use lots of features. That doesn't change that most of them use none of them. WASM would continue to exist. It just doesn't need to be in every browser.
This might not be cheap to serve, but it’s cheap to build, and it makes you wonder about the intersection and inflection of those cost curves. And of course we haven’t spent decades optimizing for it.
Don't get me wrong.. REST APIs, HTTP, HTML5, all wonderful. But as a user, the cost/benefits of ubiquitous JavaScript in depth simply to win interactivity and single page apps at the cost of um, everything wrong with the web (and by extension much of the world economy via surveillance capitalism) are a bit suspect.
It's a lot easier to maintain a WebAssembly engine than a JavaScript engine.
On the do-browsers-need-js point, you might be interested in:
Browsers were being used for more complex things, which resulted in companies adopting hacky solutions to enable more performance.
WASM is seeking to develop a consistent standard for these use cases.
Browser complexity is made more tractable by Wasm, not less. Maybe remove JS now that Wasm exists.
Practically at this point it’s configuring a Skia render context. This gives a known api to target for the graphics stuff.
There is near 0 value for designers to pain themselves over this.
The design interface should be 85% graphical.
The implementation should be a runtime for a configurable context and it should be configurable with code.
The ui given to designers should be a graphical tool. There could be many, many such tools!
I’m writing this as a graphics engineer who has followed this for over 20 years. I would love to hear engineering based counter arguments to this pov.