Definitely related! An old demo on “live game programming” gets linked around this community, although that’s a slightly different topic

m.youtube.com/watch?v=72y2EC5fkcE

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"

What I like about this proposal is that it separates ARIA out into something that stands alone. This gives people a web-standard (read like "bog-standard") way to add accessibility to their <cancas> apps.

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.

One of my favorite W3C documents: The Rule of Least Power

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.

@Jeffrey Tao

What would abandoning the DOM mean for search engines?

Who uses search engines anymore? Anyway, just use Aria.

Web scraping in general?

Just use Aria somehow.

Element-based ad blocking?

Use Aria. Another interesting approach would be to make a tracing Wasm interpreter that can determine which pixel on the screen was derived from which byte received from an ad server and can automatically find all relevant Wasm code on the way from the ad server to the pixel so it can be disassembled and patched.

And the inspectability of websites via browser dev tools?

Every framework is going to add dev tool interoparability just as hardware manufacturers add Jtag.

This is cursed.

Also, I heard a "useMeemoo" @Forrest O. :)

It's definitely worth a closer look at! You might also consider Pharo and Cuis, both of which branched off Squeak developement after 1998 in order to pursue different directions. Pharo went for a larger system supporting small-scale commercial software development, whereas Cuis went for minimalism.