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?
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.
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.
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).
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.
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.
What about maintainability of large code bases? JS even with TS tacked isn’t so great or at least not as good as Rust.
Yes, that is a good reason to use languages like rust overall. And one reason we are seeing quite a few web frontend frameworks being written in rust now. They are maturing quite fast and there is quite a bit of effort being put into them. But i believe most of this is coming from rust devs (that may have touched frontend tech before) wanting to use it in more places rather than JS devs wanting something more maintainable.
There is quite a lot you can do in languages like JS to help mitigate the maintainability issues as projects scale up in it. TS is one such thing that helps quite a lot and when employed well improves things quite a lot - enough of a difference that it makes the jump to a completely different language and tooling that moving to rust would involve become less attractive. There is still benefit of rust over TS, but also a much bigger cost than switching from JS to TS.
Some will see the switch as worth it, though more for newer/greenfield projects. Or those coming from backend already written in rust and thus already familiar with the language. Over time these types of projects and situations will grow - but that happens very slowly over time and not just because some line gets crossed by the technology. It also wont cause it to take over everything, but will just get a small market share of everything being written now.
This is also why we have so many different backend languages rather than one that everyone uses. If one language cannot take over that why would it work for the frontend? At best more websites will start suing other languages over time and slowly erode JSs market share in the web frontend space.
Interesting take!
Indeed. Who runs into the speed and size limitations of Js itself nowadays? Even freaking Office365, Google apps and observability dashboads run fairly smootly on Js. Not saying there are no legitimate use-cases out there, but I see plenty of reasons for not wanting to fight with the borrow checker if all I am doing is serving up a boring website with some forms and dynamic elements.
There are legitimate use cases out there. And it is not just about speed. Rust is the most loved language for good reason and people wanting to use it in the browser rather than JS because they like is more is as good a use case as any. And this is despite the borrow checker issues - which are really only a problem when you are first learning rust.
These days the rust web frameworks available are very close to the JS frameworks in terms of ergonomics as well as speed. There are even isomorphic web frameworks now that let you write rust code on the backend and frontend using a single rendering code for both. It can be very nice to have both the frontend and backend logic in the same language and even share the same code. And for anyone that does not enjoy JS as a language now has another option to do this with. That IMO is enough of a use case to warrant it.
Though the frameworks are still maturing and have a few rough edges. Plus it is often not worth the effort to port old projects. But new greenfield projects are another matter. But the bigger question for this side is then hiring talent - and ATM JS is easier to hire for, for frontend developers.
Over time this might change, but only very slowly.