What's stopping WebAssembly from effectively replacing JavaScript?

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?

jeffhykin,

Nothing is stopping them. Have you seen Leptos? github.com/leptos-rs/leptos

arthur,

JS have momentum, a lot of it.

Mandy,

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

lambda,
@lambda@programming.dev avatar

Do it do it do it! 🤣

icesentry,

On the subject of dom manipulation from wasm I highly recommend this video 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.

jim_stark, (edited )

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.

icesentry,

The video is essentially saying the exact opposite of what you are saying. It’s showing leptos to be much faster than react and I know primeagen doesn’t think rust is harder develop.

jim_stark,

My bad. I can’t find the actually video but there exits a startup that shutdown because Rust/WASM performance wasn’t any better on top of that it’s was harder to develop with Rust. But as my edit to my previous comment shows things got better for Rust. It’s no longer the case.

livingcoder,

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.

Blamemeta,

There’s Typescript, it’s as close as you can get.

icesentry,

You can absolutely modify the dom, you just need to go through a thin js glue layer between the dom and wasm

dneaves,

For transpiled-to-JS languages: Elm, Purescript, Typescript

I personally use Elm. Really helps remove all the JS funny business, without really having to type it (mostly)

nous,

There are quite a few web frontend frameworks for rust now that are reasonably mature. Though you might still find a few rough edges they are usable for projects now.

All of these can work without you needing to write any JS code. Though there is JS glue code involved, it is generated and you don’t need to worry about it.

But the JS eco system is still quite large and hard to completely avoid.

Nighed,
@Nighed@sffa.community avatar

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.

AnarchoYeasty,

If you use rust and structure your program correctly you can avoid debugging directly by building unit tests in language the verify behavior. Debugging tools are great and I look forward to better dx stories there (you can use chrome + DWARF to debug your native code) but strictly speaking it isn’t necessary most of the time.

livingcoder,

Can you please elaborate on how, when using Rust, we can avoid needing to debug our JS code? I am very interested and hope that I didn’t misunderstand you.

pelya,

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.

fiat_lux,

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.

AnarchoYeasty,

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.

Mubelotix,
@Mubelotix@jlai.lu avatar

It’s only smaller for large apps

Kissaki,

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.

AnarchoYeasty,

The language best suited for wasm is easily rust. And you can still interface with the Dom using frameworks like yew sycamore or leptos.

Debugging is still a little tricky but you can debug wasm in chrome and DWARF allows you to have source maps that map to your rust code. This is s problem the community is working to improve. Until then you have the full power of console log which is how a large portion of developers already debug their applications.

nous,

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.

kicksystem,

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.

nous,

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.

kicksystem,

Language preference, ergonomics and isomorphic code have not been good enough use-cases to get people off of Js. There was a big hype around compiling to Js a decade ago, but that hype past us and nowadays this is usually only done for some small piece of pure logic that really needs to be isomorphic, which is kind of what we have wasm for nowadays. People who hate Js should really get off their high horse. Writing frontend code in Rust really isn’t going to make a material improvement over writing the same thing in TypeScript, unless you need raw performance which is less than a percent of all webapps.

This is a good thing, because the frontend community is really not going to benefit from having the same thing written in a dozen languages. We’ve already got a bazillion datepickers, we don’t need a gazillion. People are dumb enough to want to rewrite a bunch of stuff in Rust just because they like the language. And Rust absolutely isn’t the best language to write a datepicker in. Having a single language, however crappy, did create some much needed stability in the frontend space. It is also quite handy that frontend engineers can focus on their job, not on learning language X with toolchain Y and libraries Z.

Don’t get me wrong. I am not a Js fan. I’ve been coding since the 90s and am familiar with most languages and pretty much every paradigm. I can be quite picky when it comes to languages, but I’d rather have a single okay language that gets the job done with a good ecosystem then a dozen competing ecosystems some of which may be better in some respects. The current status quo with the advent of TypeScript isn’t terrible either. What is shitty though, is React and the complete lack of use of web standards, but that’s another tangental discussion.

nous,

Language preference, ergonomics and isomorphic code have not been good enough use-cases to get people off of Js

But they are good enough reasons for people to want to use it over JS when coming experience with rust backends.

There was a big hype around compiling to Js a decade ago, but that hype past us and nowadays

What do you mean? This hype never passed - this is exactly what typescript is, a compile to JS language. And TS has taken off as a language and adopted by a large amount of people working in the web frontend world and with JS in general.

Writing frontend code in Rust really isn’t going to make a material improvement over writing the same thing in TypeScript, unless you need raw performance which is less than a percent of all webapps.

Developer satisfaction is a good enough reason to pick a language for something (assuming it outweighs other tradeoffs). And if you have picked something like rust for your backend then there is a good reason to also use it for your frontend - assuming your devs are more experience in rust than JS and you have no existing JS code you need to interact with. Performance is not the only, or even main reason you would want to pick rust over JS. There are a lot of other reasons it can be beneficial.

Having a single language, however crappy, did create some much needed stability in the frontend space

Stability in the frontend space? What are you talking about? There is a new framework or library or even compile to js language every week. The web platform is just a fast moving target now you are constantly needing to learn new things to keep up with it. And adding more optional things like other languages does not make this any worst or better - but does mean those that are not already familiar with JS, but are with other languages can use the language they are familiar with instead of the whole fast moving JS ecosystem.

It is also quite handy that frontend engineers can focus on their job, not on learning language X with toolchain Y and libraries Z.

And if you have people familiar with JS already then there is not as much point in getting them to learn the rust eco system. Just like it is nice that if you already know the rust eco system you don’t need to learn a JS just to do frontend development. And JS developers are already constantly learning new frameworks and libraries as the churn in the JS eco system is quite high.

but I’d rather have a single okay language that gets the job done with a good ecosystem then a dozen competing ecosystems some of which may be better in some respects

I disagree. Having more languages available on the web is better IMO. It gives more people more options to get into it and you are not stuck on some language that was created in 10 days 28 years ago and only recent years had any improvements done to it at all. Yea, most people will still use it and there is little to no point in converting existing projects to it. But that does not mean we should not be exploring different languages in the web space at all. Or being forced to only use compile to JS languages. It is all optional, you are not forced to use it. But it lets those that want to use it do so.

kicksystem,

I am not getting into a discussion with you. Have a nice day though.

jim_stark,

What about maintainability of large code bases? JS even with TS tacked isn’t so great or at least not as good as Rust.

nous,

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.

jim_stark,

Interesting take!

tokyo, (edited )

I’m genuinely confused by these responses. It’s as if most didn’t actually look into what WASM was besides a cursory glance and then answered right away.

First off WASM is (relatively) new. It’s at 1.0 which iirc is basically an MVP product. It will take years for all browsers to integrate it appropriately.

Why choose WASM over JS? You probably wouldn’t right now unless you wanted to help pioneer the technology. Again it’s fairly new and probably not expected to be used in professional environments yet.

As for the benefits, it’s mostly the speed of code execution. Yes JavaScript is fast and robust enough for current web apps. No it is nowhere near as fast as native code.

Think about PC games. When people need performance, JS is definitely not the first option or even one of them in most cases. You want a language closer to the metal which is why compiled languages like C++ are often used.

All that said, if it was in a mature phase and did run faster than JS, why would you care? Well with native compiled code, you could run some hefty programs from a browser with the speed of native code.

That potentially means running more intensive applications like games and photo editors completely on a website. You could bypass the need to download software. You would visit the website, the WASM code would be sent over and used in the browser to run the application.

You can also interact directly with JavaScript via a WASM and call WASM functions within JavaScript so it’s pretty connected.

Overall it’s a fairly new technology that when matured could mean a major change for how the web works. It will likely be a long time until we see it capable of being used professionally and even longer before we see widespread use.

whatsarefoogee,

Most games, image processing libraries and other compute demanding libraries already use WASM in the browser. Have been for quite some time. It’s already widely used in every case where it provides a substantial benefit.

But writing for GUI, which is what 99% of JS is used for, WASM provides little benefit. The speed bottleneck is mostly in DOM manipulation. And every web GUI framework uses 200 npm packages with something like webpack. Getting that to somehow work with your WASM code would be a nightmare if it’s even feasible.

magic_lobster_party,

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.

companero,

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.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • programming@programming.dev
  • Durango
  • DreamBathrooms
  • InstantRegret
  • magazineikmin
  • osvaldo12
  • everett
  • Youngstown
  • khanakhh
  • slotface
  • rosin
  • thenastyranch
  • ngwrru68w68
  • kavyap
  • normalnudes
  • megavids
  • ethstaker
  • GTA5RPClips
  • modclub
  • cisconetworking
  • mdbf
  • tacticalgear
  • cubers
  • provamag3
  • tester
  • anitta
  • Leos
  • JUstTest
  • lostlight
  • All magazines
    •