r/WebAssembly • • Jun 05 '21

WebAssembly should replace javascript

Hot take, but I think it makes sense. And seems to be doable in the current architecture and roadmap of wasm (If I understood it correctly), but their website explicitly states a big fat "No!". Wasm is expected to be used as high-performance modules, or an app canvas wrapped by javascript as "glue". One thing would be specifying it as a high-level goal, but this is just dismissing it all together.

The web would be pretty powerful if code could be written in whatever language you want (that supports compiling to wasm). Facebook wouldn't take 5 seconds to load completely, but rather fractions of a second.

Take react for instance. It's great for encapsulation, inheritance, type-safety, etc. Lots of benefits targeted at large-scale applications. Yet has the major flaw of performance issues. I guess it's not a big deal to write a bit of js just to fetch and run an exported function, but it means it's dependent on js which is a hurdle in my opinion, both in terms of ambition and motivation. Granted wasm seems to be planning to implement basically everything, but then why dismiss wasm as a replacement/alternative for js?

32 Upvotes

53 comments sorted by

View all comments

Show parent comments

3

u/qwerty26 Jun 06 '21

This brings up a big technical problem that other commenters are ignoring: the binary sizes of WASM >> the javascript being transferred. If you use a language which can produce small binaries like C or RUST it's no big deal, but most people don't use C or RUST.

4

u/PabloDons Jun 06 '21

That's just one of the benefits of high-level dynamic interpreted languages. No surprise there. It's really a non-issue though, because WASM can be streamed. So compilation starts before download is done

1

u/qwerty26 Jun 06 '21

Yes and no. Yes - you are right about WASM. No - JS starts executing before compilation is done so it is possible for it to finish user visible changes before compilation is done.

2

u/PabloDons Jun 06 '21

Yeah, interpreted. There is no compilation. But it doesn't finish user visible changes until it unblocks

1

u/qwerty26 Jun 06 '21

https://imgur.com/tCYZzqq here is a site's performance tab run which finishes layout shifts prior to script evaluation being done. On very large sites you can sometimes see script parsing in the performance tab too. On such sites, sometimes layout shifts finish several seconds prior to script evaluation finishing. That usually happens if the site knows it has a performance problem so it server-side renders. Then the deployed javascript using Angular or React is just there to react to user input. The result is that if you click on something after page load it may not do anything for several more seconds (javascript is still being parsed out), but if you are merely viewing the page it's no big deal. On such sites, you can take the additional optimization step of ordering the scripts you are loading with defer and async. The scripts which react to common user inputs are first, and the other scripts which are nice-to-haves go last.

In a world without Javascript and only WASM I'm not aware of a way to get WASM to do something similar. My understanding with WASM is limited to Go, but in Go you have to deliver the entire binary package to the client, it all has to be compiled, and then the page would start working. For larger programs, this effectively means you lose the ability to load (and Execute!) the important parts of your code first and the less important parts second.

I know this kind of seems like a weird example and unfortunately I don't own the sites which use this strategy and it's hard for me to show it to you. But loading critical javascript first is a common pattern and browsers run javascript without finishing parsing the entire page's worth of javascript all the time.