This is an argument in favor of demand having leveled off.

Got any data?

It happens daily? Weekly? Monthly?

What is "regularly"?

> terrible no-good DevEx for basically the whole time

I'm telling you why.

> still steadily making it's way into more and more of the web.

It is, but you can still browser the web without it just fine, despite so much investment and (judging by how HN reacts to it) overwhelming enthusiasm from devs

It's a big feature of JS. JS's dynamism makes it super easy to target for basically any language.

> Google switched to compiling Java to Wasm-GC instead of JS and got a lot of memory/speed improvements.

That's cool. But that's one giant player getting success out of a project that likely required massive investment and codesign with their browser team.

Think about how sad it is that these are the kinds of successes you have to cite for a technology that has had as much investment as wasm!

> Almost 6% of page loads use wasm

You can disable wasm and successfully load more than 94% of websites.

A lot of that 6% is malicious ads running bitcoin mining.

> Wasm is way too complicated to use today.

I'm articulating why it's complicated. I think that for those same reasons, it will continue to be complicated

I'm trying to explain to you why attempts to make wasm mainstream have failed so far, and are likely to continue to fail.

I'm not expressing an "opinion"; I'm give you the inside baseball as a browser engineer.

> Getting rid of the glue layer

I'm trying to elucidate why that glue layer is inherent, and why JS is the language that has ended up dominating web development, despite the fact that lots of "obviously better" languages have gone head to head with it (Java, Dart sort of, and now wasm).

Just like Java is a fantastic language anywhere but the web, wasm seems to be a fantastic sandboxing platform in lots of places other than the web. I'm not trying to troll you folks; I'm just sharing the insight of why wasm hasn't worked out so far in browsers and why that's likely to continue

> Where it is currently fairly painful is in writing traditional websites, given all the glue code required to interact with the DOM - exactly what these folks are trying to solve.

I don't think they will succeed at solving the pain, for the reasons I have enumerated in this thread.

I'm being serious.

> Why should web-devs switch to WASM unless they have a specific problem to solve where WASM is the better alternative to JS?

They mostly shouldn't. There are very few problems where wasm is better.

If you want to understand why wasm is not better, see my other posts in this thread.

So does JavaScript.

> It's almost impossible to statically reason about JS code, and so browsers need a ton of error prone dynamic security infrastructure to protect themselves from guest JS code.

They have that infrastructure because JS has access to the browser's API.

If you tried to redesign all of the web APIs in a way that exposes them to WebAssembly, you'd have an even harder time than exposing those APIs to JS, because:

- You'd still have all of the security troubles. The security troubles come from having to expose API that can be called adversarially and can pass you adversarial data.

- You'd also have the impedence mismatch that the browser is reasoning in terms of objects in a DOM, and WebAssembly is a bunch of integers.

> There are dynamic languages, like JS/Python that can compile to wasm.

If you compile them to linear memory wasm instead of just running directly in JS then you lose the ability to do coordinated garbage collection with the DOM.

If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upside.

> Also I don't see how dynamic typing is required to have API evolution and compt.

Because for example if a browser changes the type of something that happens to be unused, or removes something that happens to be unused, it only breaks actual users at time of use, not potential users at time of load.

> Plenty of platforms have static typed languages and evolve their API's in backwards compatible ways.

We're talking about the browser, which is a particular platform. Not all platforms are the same.

The largest comparable platform is OSes based on C ABI, which rely on a "kind" of dynamic typing (stringly typed, basically - function names in a global namespace plus argument passing ABIs that allow you to mismatch function signature and get away with it.

> The first major language for WebAssembly was C++, which is object oriented.

But the object orientation is lost once you compile to wasm. Wasm's object model when you compile C++ to it is an array of bytes.

> To be fair, there are a lot of challenges to making WebAssembly first class on the Web. I just don't think these issues get to the heart of the problem.

Then what's your excuse for why wasm, despite years of investment, is a dud on the web?

My points are validated by the reality that most of the web is JavaScript, to the point that you'd have a hard time observing degradation of experience if you disabled the wasm engine.

JavaScript is the right abstraction for running untrusted apps in a browser.

WebAssembly is the wrong abstraction for running untrusted apps in a browser.

Browser engines evolve independently of one another, and the same web app must be able to run in many versions of the same browser and also in different browsers. Dynamic typing is ideal for this. JavaScript has dynamic typing.

Browser engines deal in objects. Each part of the web page is an object. JavaScript is object oriented.

WebAssembly is statically typed and its most fundamental abstraction is linear memory. It's a poor fit for the web.

Sure, modern WebAssembly has GC'd objects, but that breaks WebAssembly's main feature: the ability to have native compilers target it.

I think WebAssembly is doomed to be a second-class citizen on the web indefinitely.

I'll try again, maybe I was doing something else wrong, or something changed

Thanks for making it!

But the interesting comparison when evaluating coding agent capabilities is to evaluate the offerings given to users.

So this means comparing Claude Code to Codex to whatever CLI tools Kimi, GLM, and others give you.

And it might mean throwing Cursor, OpenCode, Amp, Pi, mini-swe-agent, etc into the mix

But it was in codex

Works great

This isn’t that kind of duplication.

> It can't be that replacing 20 C/C++ shared objects with 20 Rust shared objects results in 20 copies of the Rust standard library and other dependencies that those Rust libraries pull in. But, today, that is what happens. For some situations, this is too much of a memory usage regression to be tolerable.

If memory was cheap, then maybe you could say, "who cares".

Unfortunately memory isn't cheap these days

Am I wrong?