I was wondering how long it would take for the web to get to this point. It seemed inevitable once canvas became a thing. You don’t even technically need gl or wasm to rewrite an entire rendering engine in js that can just blast pixels at the full-size canvas.

Cool that you’re creating an actual desktop-style gl app with it.

▲

timschmidt 2 days ago | parent [-]

I'm looking forward to the day when Javascript can be just another WASM polyfill loaded with the page with a well-defined, portable, and fast API to the DOM. Also can't wait for WebGPU to be adopted in more places. Right now I rely on WebGL2 because WebGPU isn't available in Firefox/Linux stable by default.

Another minor annoyance is that 'cargo bloat' and similar tools don't yet have backends for wasm, so I need to fix up the native build to make use of that sort of analysis, which I'd like, because I serve the whole application from microcontroller flash where I only have 4 - 16mb to hold application and firmware, including the http server and network stack.

▲

sneak 2 days ago | parent [-]

I don't. I don't want the web to become just a runtime for opaque binary applications. Right now we still maintain some semblance of user control over the DOM and the application; when everything is WASM and WebGPU using its own custom renderer, the ability of people to casually inspect, modify, hack, tinker, and tweak will be completely over.

I learned how to build for the web by looking at webpages and seeing how they worked. What you're describing is the switch from circuit boards of discrete components to everything in a single microscopic IC under a blob of epoxy.

	▲	timschmidt 2 days ago \| parent \| next [-]
		I recognize it as a more or less universal optimization process. Everything important ends up in silicon, if it remains important long enough. And there are several stages of that. Like you, a part of me years for SGML and The Semantic Web, and where it makes sense in Alumina I am using RESTish APIs. But I do not pine for Javascript. Language or frameworks. 20 years has been enough. And I do not believe that some of the 4mb minified obfuscated js downloads from a CDN I've seen are in any way more accessible than a WASM binary of similar size. At least there is advanced tooling for the WASM representation. Folks who want you to read their code will still make it easy, and folks who don't won't. To your point about learning, WASM makes some really incredible systems like https://lovr.org/ available in the browser, which I would have loved to have as a kid, but which also aren't javascript. It's related to Turing completeness somehow, once you let a little software into your structured document, it all wants in. Or maybe it's "if you give a mouse a cookie"? I understand what you're saying about discoverability. But the developer in me really likes having a relatively simple binary interpreter to target for network-delivered cross-platform binary applications. My hope is that offering such a juicy target to the folks who want to develop applications (including myself) gets them out of all the semantic document features, allowing both sets of code to get simpler and more focused. Because I think they're two different, both entirely valid, tasks folks use the web for.
	▲	osigurdson 2 days ago \| parent \| prev [-]
		If you look at a typical next.js type app with all of the build steps, minification, post-css, tree-shaking, client side / server side, etc., it isn't exactly optimized for reverse engineering. Maybe that ship has already sailed.