I’ve been wondering about this for a while and haven’t really found a great answer for it. From what I understand, WASM is:
-
Faster than JavaScript
-
Has a smaller file size
-
Can be compiled to from pretty much any programming language
-
Can be used outside of the browser easier thanks to WASI
So why aren’t most websites starting to try replacing (most) JS with WASM now that it’s supported by every major browser? 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, is there something I’m missing?
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.
I’d imagine one of those killer features is using a language with a solid standard library. Npm dependencies are notoriously complex because js as a language is missing basic functionality that is standard in other languages. Just a few years ago the Internet broke because “pad left” was pulled by it’s maintainer, that simply doesn’t happen in other languages
From a maintenance perspective npm is a nightmare. From a security perspective it is worse. Being able to build your entire website using a language that eliminates most dependencies, and the ones you take on don’t pull in a zillion dependencies either, is absolutely a killer feature
Of course that isn’t the full story and using js still has it’s advantages as people have already pointed out. If wasm closes the gap in those areas then it would absolutely be worth the switch
But other than that, Mrs. Lincoln, how was the play?
I’m amazed at how much you described in a single sentence there
Even if WASM gets some amazing feature, like super-fast DOM manipulation, it would still be used via API from JavaScript. WASM is a subset of JavaScript that mainly consists of low level operations. It’s not exactly nice for writing code. It’s like assembler in this respect — very fast, very efficient, but we still tend to prefer a higher level language.
Ok but no one is talking about hand writing wasm. You write wasm with a language, such as rust, which already has great web frameworks such as yew (which replaces react) as well as leptos (which replaces solid.js). Leptos is already faster than react vue and svelte
Nothing is stopping them. Have you seen Leptos? https://github.com/leptos-rs/leptos
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.
JS has little to do with accessibility. Most web accessibility comes from the Dom and aria attributes as well as semantic tags. You can do all of that with wasm too.
Are you asking about how it will work with wgpu based applications? This will work the same as it does on desktop applications. The program calls out to libraries that support talking to screen readers. I know rust the language with the best support for and ecosystem around wasm libraries like this already exist and ui frameworks like egui already have some support built in.
