Programming

The most compelling argument I heard is that WASM can’t manipulate the DOM and a lot of people don’t want to deal with gluing JS code to it, but aside from that

But other than that, Mrs. Lincoln, how was the play?

You've gotten several other answers that are true and correct - the pain of implementation at this point is greater than the pain points that WASM solves. But this is also a non trivial one - most of what Javascript should be doing on a webpage is DOM manipulation.

At some point, WASM will either come out with a killer feature/killer app/use case that Javascript (and all the libraries/frameworks out there) hasn't figured out how to handle, and it will establish a niche (besides "Javascript is sort of a dumb language let's get rid of it"), and depending on the use case, you might see some of the 17.4 million (estimated) Javascript developers chuck it for....what? Rust? Kotlin? C? C#? But the switching costs are non-trivial - and frankly, especially if you still have to write Javascript in order to manipulate the DOM....well, what are we solving for?

If you're writing a web app where one of the WASM languages gives you a real competitive advantage, I'd say that's your use case right there. But since most web applications are basically strings of api calls looped together to dump data from the backend into a browser, it's hard to picture wider adoption. I've been wrong before, though.

Faster than JavaScript

For pure computation, using the right language it can be faster. For a general website that needs to manipulate the DOM the performance is about the same as what popular JS frameworks can do (and can be faster than popular ones like react). But there are faster JS frameworks that react already available and people are not flocking away from react to these other frameworks. So speed is not a big enough issue here for people to want to move to a new language with WASM.

Has a smaller file size

Not sure this is true. Maybe for a single function. But for a general application? I don't think so. WASM tends to be a bit larger than JS code I think as you often need to ship more code, where JS can rely more on things built into the browser. But we are at a point where this difference is not a huge concern any more either. So is not really a point for or against WASM here.

Can be compiled to from pretty much any programming language

This is a huge misleading point. Even if you could do it from any language not all languages have a ecosystem that is useable for it and a lot of languages require large runtimes that need to be shipped with the WASM bundle (making the points above far worst).

Can be used outside of the browser easier thanks to WASI

So can JS? And native code? So I don't really see what this statement is meant to be arguing for? It is irrelevant when talking about websites using WASM in the browser.

So why aren’t most websites starting to try replacing (most) JS with WASM now that it’s supported by every major browser?

Why should they start using it? They all have existing code, their devs already know JS. What major advantage would WASM give them over what they currently have? The points above I have already gone through and are not a big enough reason for this change outside of niche use cases. JS is good enough for most use cases and people that are already working in the web browser side of things already know it. There is little reason to make the switch to WASM as even in languages like rust, which likely has the most mature eco system, still has a vastly less mature eco system for web dev than JS.

There is no line that needs to be passed that will cause floods of people to start adopting it and start converting everything they maintain over towards it. If there is a good enough reason to adopt this technology then it will be done very gradually over many years if not decades. People wont suddenly throw out everything once some line is crossed without some extreme and unconditional benefit to doing so.

I've ported games to web using WASM. You still need to interact with HTML DOM using JS, no way around it.

You use WASM when you either need raw CPU speed, or you have some C++ code that you don't want to rewrite in JS.

If you just want to make a website, pure JS is better, unless you're that kind of dev who prefers to render their own text strings pixel by pixel.

The truth is that JS is currently "good enough" and all the best (adopted) web frameworks are either server or JS based.

I believe the chunking of script files is currently a bit more natural as well.

WebAssembly is the best choice for certain kinds of apps but most web apps are good enough with JS. If communities pour a lot of polish into WASM frameworks you may start to see wider adoption. Diversity is good, but it does need to be asked why WASM + DOM is objectively better than JS + DOM. It complicates the ecosystem a bit because you might fracture it for no good reason. Should there be Rust, Python, and JS DOM rendering frameworks? Is there a benefit?

If you have a more traditionally native app you want to port, that's different. That's a great fit for WASM. Personally I see it becoming more popular when it's a good replacement for desktop technology and the DOM isn't used at all (go straight to GPU). I'm a huge fan of WASM, but I also write a lot of web apps and don't see a super convincing reason to adopt WASM to effectively make the exact same thing. As-is, it's great for augmenting an app though.

Wait for garbage collection and sockets and you might see the paradigm start to shift.

Replacing costs expertise, time, and money. Nobody wants to invest that for (to them) insignificant or even pointless reasons.

If you're using tooling, a framework, a library - each of those makes a switch more risky, costly, or impossible.

JavaScript works with the DOM. Why would you want to implement a separate WASM component that you have to interface with? JavaScript is good enough. Interfacing only brings problems with it.

When you use JS you are doing it right - because there is no other way to interface with the DOM. Anything else is built on top. How would you interface with WASM? Manually? Library? Framework? What programming do you use to compile to WASM with? How do you analyze and debug WASM when it executes in a compiled WASM-binary format?

The use case for WASM is performance, efficiency on CPU-bound operations. If CPU-bound performance is not a concern for you, or JS is good enough, there's little reason to use WASM. Other reasons are even more niche.

I think the truth is that not only can't WASM manipulate the DOM, but javascript was build to manipulate the DOM and has been moulded around this purpose. Secondly, if you want to use WASM from another programming language, that is just another language you need to learn on top of javascript, because we are not at a stage where we can replace javascript (because of the DOM). Fo most it's more cost effective to just optimize their javascript code instead of adding another layer to the tech stack.

From my experience JS is primarily used to manipulate the DOM. I haven't looked into it, but if you're correct that WASM cannot manipulate the DOM then your question, to me, is tantamount to "Why aren't people using forks to eat soup?".

I would love a staticly-typed, compiled language to come along and replace JS. If anyone is aware of how I can write Rust in place of JS, please let me know. For now, I suffer/enjoy JS.

Unless it has improved since last time I used it then it's awful to debug in the browser. I hate JavaScript, but would probably still use it for a new web project now.

How will we be making WASM-based UI accessible for people using screen readers, screen zoom applications, text to speech and voice input users, etc.?

The Web is hostile enough to people with disabilities, despite its intent, and developers are already unfamiliar with how to make proper semantic and accessible websites which use JS. Throwing the baby out with the bathwater by replacing everything with WASM in its current form seems about as good an idea as Google's Web Environment Integrity proposal.

It's only smaller for large apps

WebAssembly was never intended to replace JavaScript. It was intended to coexist with it. You still need something to initialize and load the binary.

So I gotta have to break out the xkcd comic again? Cause I will

IIRC a startup tried to exactly that... It's wasn't any faster and is actually harder to develop.

EDIT:

Sorry ignore these videos. I don't remember which YouTube video it is. But more importantly Rust + WASM got really better than JS these days.

• https://www.youtube.com/watch?v=461735zrjzY

• https://github.com/leptos-rs/leptos

Javascript is just really great. WASM is also great and really opens up some cool possibilities, but there is something inexplicably simple and approachable about Javascript. I think it will be very hard to topple it from its throne, even if WASM overcame it's DOM issues.

From a historical standpoint, there is also the bad blood of ActiveX, Flash, Silverlight and early Java applets that still leaves a bad taste in people's mouths. It has a slightly steeper uphill battle to fight.

Faster than JavaScript

JS is usually fast enough.

Has a smaller file size

It really depends. If you aren't careful, your Wasm blob can end up ballooning in size. If you start pulling in libraries and doing things like parsing JSON, your binary can get big, quick.

Wasm adds an extra layer of complexity that needs to be justified. In most cases, it's just not worth it.

JavaScript is much more mature. It has a lot of established tools and frameworks aiding the developer. JavaScript frontend developers are also easier to recruit. You will just make everything harder for yourself by adopting WASM.

On the subject of dom manipulation from wasm I highly recommend this video https://youtu.be/4KtotxNAwME. It's from leptos author, one of the more popular wasm framework. The TLDR is that modifying the dom isn't the bottleneck for wasm.