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 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.
This is it.
WebAssembly AFAICT is all about making existing code runnable in a JavaScript environment. JavaScript isn’t great itself, but Chrome provides pretty amazing tooling, so it’s good enough.
Add to that: if you want to write WASM in a strongly typed language, you need support libraries that define all of the browser primitives. If you’re an accomplished web developer, it’s more effective to stay in js.
WebAssembly AFAICT is all about making existing code runnable in a JavaScript environment.
I would not say that. It is one aspect of web asm, but not the only or even main reason. There are far more frameworks and tooling out there designed for writing new stuff in it rather than getting existing stuff to run.
if you want to write WASM in a strongly typed language, you need support libraries that define all of the browser primitives.
These already exist for some languages - notably rust (but not exclusively). You can now write a web app fully in rust and have it preform on par with popular JS frameworks. There is JS involved in this - but it can all be generated so developers never need to actually touch it.
If you’re an accomplished web developer, it’s more effective to stay in js.
This is true, and the bigger reason why wasm is not as popular. If you already know a JS web framework there is little point in learning a whole new language as JS is good enough for most applications. And a whole new language and tooling is a large investment. But it does mean that people in other eco systems or that don’t really like JS are now able to write webapps in other languages (which by the very nature are going to be a fraction of web devs as these people will likely have avoided it where they can). Other eco systems are also a lot less mature than JSs eco system for web development.
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.
I think the truth is that not only can’t WASM manipulate the DOM
Not directly no. But it can via JS (without the developer needing to ever touch JS code themselves via auto generated bindings). And this is simply a limitation of the current WASM implementations/standards. I believe there is work on going to get WASM more direct access to the DOM. But really this will just be an efficiency improvement over what is currently possible (which is already possibly to be as fast as pure JS frameworks).
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).
This is not quite true. Yes we cannot replace JS currently. But you don’t need to learn JS to develop using WASM - there is already enough tooling that can auto generate any JS code needed for you so developers never actually need to learn or touch JS if they don’t want to.
But existing developers that already know JS don’t have a huge reason to learn another language that only have a vastly less mature ecosystem. So the door is currently open for those that don’t enjoy or want to touch JS, but those people will at this point in time be working on other things rather then web apps. So there is not going to be a huge push for moving to a different language with WASM support any time soon. Not to mention that there is only minor benefits to existing applications that make a full rewrite to another language not worth the effort. So people wont be flocking over toward it, but not for the reasons you mentioned.
Sure, you can autogenerated js bindings, but as soon as you need to start debugging or optimizing you need to understand the js that was generated for you.
I don’t think so. Having played around with wasm-bindgen in rust as well as other libraries the build on top of it I have never once needed to look at or understand the generated JS code. When you need to debug or optimise things the first thing to look at is the rust code. So as it stands today I do not think you need to know JS to write code for a web frontend - at least in isolation of anything else (ie teams, existing products etc).
You will likely need to learn JS at some point when writing stuff for the web - as the JS ecosystem is so vast for web development when compared to anything else. But WASMs JS bindings are not the point you will need to know it for.
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.
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.
How is WebAssembly a subset of JavaScript? Aren’t you confusing it with asm.js?
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
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.
