[3cats-in-a-coat]

It's not a criticism. I'm just pointing it out. For good or bad, it is what it is. There are two sides to it. For anyone familiar with system theory, this was the inevitable end game of the web.

However, the web also has a terrible bloat/legacy issue it refuses to deal with. So sooner or later, a new minimal platform will grow from within it, the way the web started in the 90s as the then humble browser. And the web will be replaced.

[anon35]

I think we've already seen the first shoots from that nascent new system: https://webassembly.org/. And this hilarious talk will continued to be viewed by future generations for marking the 2013 inflection point: https://www.destroyallsoftware.com/talks/the-birth-and-death...

[3cats-in-a-coat]

I had great expectations of WASM, and maybe it can evolve into what we're discussing. But as it is, this system is too limited in two crucial ways.

First, it's explicitly designed to be easy to port existing software to. Like C libraries, say. Sounds good right? Well, it's not designed as a platform that arose from the needs of the users, like the web did. But the need of developers porting software, who previously compiled C libraries to JS gibberish and had to deal with garbage collection bottlenecks etc. This seems fairly narrow. WASM has almost no contact surface with the rest of the browser, aside from raw compute. It can't access DOM, or GPU or anything (last I checked).

Second, for reasons of safety, they eliminated jumps from the code. Instead it's structured, like a high-level language. It has an explicit call stack and everything. Which is great, except this is a complete mismatch for all new generation languages like Go, Rust etc. which focus heavily on concurrency, coroutines, generators, async functions etc. Translating code like that to WASM requires workarounds with significant performance penalty.

[naillo]

WASM can access the GPU via middle layers like SDL. I.e. you can write a C program that uses opengl and compile it and as long as you include the right flags etc into `emcc` you will barely need to touch or glue it together on the JS side at all.

[3cats-in-a-coat]

All those go through JS as far as I'm aware. Emscripten bridges everything for you, but technically it goes through JS so SDL's calls also go through JS.

[naillo]

You're correct but I don't see why that matters. From your perspective as a C coder you get webgl access without having to write JS, that's what's important. Everything is "mixed together" into asm in the end anyway whether it's glue code in JS or browser side glue code.

[Aerbil313]

I for one am very happy for it. The promise of Java “write once, run anywhere” is mostly realized now. Now all we need is the browser to ship with interpreted language runtimes and language native bindings to DOM, GPU etc.