-> Towards a modern Web stack Cool new take on the Extensible Web Manifesto, this one from Hixie (Acid2, Acid3, WHATWG, Pingback, Flutter, etc). I love the breakdown — Wasm, WebGPU, ARIA, and HID. I would build on that stack!

That's the only web stack I would actually like to build on. I've been wanting something like that for many years already, but have found out that Wasm is worse than JS whenever interacting with the outside world is a major requirement, because it's confined to its private linear memory. It seems to be better now with the GC extension.

Naturally I see the benefits. But I’ll highlight that this proposal entirely abandons the DOM as an open, addressable substrate, so, you know, no more browser extensions or web scraping or anything like that. (The DOM is certainly an imperfect substrate, but it’s kinda amazing that it’s stuck around this long and still functions as an entry point for malleability.)

@Joshua Horowitz There's still Aria that provides the open semantic part that can be used for scraping and extensions.

@Joshua Horowitz I believe the point is to turn the DOM into an optional module. If you're making a website that is structured, you'd probably still want to use the DOM. If you're making something like a game or a canvas app, where all your rendering is going into a <canvas> element, you (developer) have the option to tell the browser "hey, don't bother initializing the DOM module, we don't need it, just give me a pixel buffer the size and shape of the window"

@Ivan Reese FWIW, I didn’t get the impression that the doc’s vision is centered around “non-structured” applications (games, canvases, etc). The motivation in the intro section seems very general, and I think it’s speaking to all sorts of application developers who want to throw out HTML/JS/CSS in favor of better languages & UI systems. That includes application developers making the next social media site or whatever. (E.g., see doc’s mention of Flutter.) Extending standards to make non-DOM apps more accessible is certainly a good thing.

I'd love to counter "well, most devs, especially at big orgs, would keep using the DOM because it's richly featureful, easy to hire for, has great tooling, etc" but like React and Tailwind are the two bolts in the neck of the Frankensteinian monster that is modern web dev. So I must, reluctantly I assure you, see your point.

I think this proposal is a bit too focused on standalone apps that happen to be delivered via web browser. What would abandoning the DOM mean for search engines? Web scraping in general? Element-based ad blocking? And the inspectability of websites via browser dev tools? I think a lot of those concerns are maybe hand waved by "use ARIA somehow"

My point of view as someone who is not a Web developer: this is one more proposal that says "let's give more power to developers, and less to users" (see @Joshua Horowitz' argument about extensionsand malleability) plus "let's forget the Web as an information sharing platform, and turn it into an application deployment platform". There clearly is a place in today's world for the Web as an application deployment platform. No objections to that. But please don't take the malleable stuff away from us.

@Ivan Reese

I believe the point is to turn the DOM into an optional module. If you're making a website that is structured, you'd probably still want to use the DOM.

I think proposal means that the DOM is going away. People are not making plain old websites anymore. They're throwing in at least some React even if they're making something simple. React is a weird thing that shouldn't have to exist. It takes an internal single-use DOM and translates it to commands to manipulate the external long-lived DOM that React developers don't want to touch. This translation is a lot of complexity and very very leaky abstraction that exists for no reason other than backwards compatibility. Instead of doing this unnecessary translation, every framework is going to make their own stateless immediate mode renderer, say they had to do so as to free developers from having to deal with different bugs in different DOM implementations, and then say that you can use the same renderer both for native apps and for the web, and that by the way, their own renderer runs 10x faster on every benchmark.

Sorry for reviving this zombie but i'm genuinely curious how likely this is to be implemented? (Esp WASM access to WebGPU. spinning up threads, and direct device data). Otherwise curious where i'd go to even find this out.