Language portability is a big feature. There's a lot of code that's not JS out there. And JS isn't a great compilation target for a lot of languages. Google switched to compiling Java to Wasm-GC instead of JS and got a lot of memory/speed improvements.
> 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. > 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.
I don't think any Web API exposed directly to Wasm would have a single fixed ABI for that reason. We'd need to have the user request a type signature (through the import), and have the browser maximally try and satisfy the import using coercions that respect API evolution and compat. This is what Web IDL/JS does, and I don't see why we couldn't have that in Wasm too.
> Then what's your excuse for why wasm, despite years of investment, is a dud on the web?
Wasm is not a dud on the web. Almost 6% of page loads use wasm [1]. It's used in a bunch of major applications and libraries.
[1] https://chromestatus.com/metrics/feature/timeline/popularity...
I still think we can do better though. Wasm is way too complicated to use today. So users of wasm today are experts who either (a) really need the performance or (b) really need cross platform code. So much that they're willing to put up with the rough edges.
And so far, most investment has been to improve the performance or bootstrap new languages. Which is great, but if the devex isn't improved, there won't be mass adoption.
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
It's not really a dud on the web. It sees a ton of use in bringing heavier experiences to the browser (i.e Figma, the Unity player, and so on).
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.
> 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 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
JS was dominating web development long before WASM gained steam. This isn't the same situation as "JS beating Java/ActivX for control of the web" (if I follow the thrust of your argument correctly).
WASM has had less than a decade of widespread browser support, terrible no-good DevEx for basically the whole time, and it's still steadily making it's way into more and more of the web.
> 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
I don't understand this objection. If you compile code that doesn't call a function, and then put that artifact on a server and send it to a browser, how is it broken when that function is removed?