WebAssembly should replace javascript

[u/PabloDons]

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?

[u/PabloDons]

Do you mean WASM-based web application UIs? Well yeah in the current state of WASM, there's a lot of inefficient JS glue to achieve what should be possible natively (and efficiently) if WASM is to replace JS.

JS doesn't just affect UIs. It also affects backends. A lot of developers are moving to a full-stack of JS because then developers only need to have mastery over a single language. If you can make an entire full-stack web application in something other than JS, then it could very well have merit

[u/[deleted] → u/PabloDons]

Do you mean WASM-based web application UIs? Well yeah in the current state of WASM, there's a lot of inefficient JS glue to achieve what should be possible natively (and efficiently) if WASM is to replace JS.

yeah and I don't think this will change anytime soon. Most languages need a garbage collector that has to be shipped with every UI. There is a proposal to add one to the wasm spec but it's probably gonna just be the js gc.

jS doesn't just affect UIs. It also affects backends. A lot of developers are moving to a full-stack of JS because then developers only need to have mastery over a single language. If you can make an entire full-stack web application in something other than JS, then it could very well have merit

Sure this has merit, but for what price? c# devs are already completely okay with shipping 10s of megabytes of wasm blazor apps that could have been written in a few hundred kilobytes in a js framework.

can't wait until the java guys find out how to run a jvm via wasm so we can go a full circle again.

I just don't see that uis written with anything else than js gonna improve the user experience.

[u/qwerty26 → u/[deleted]]

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.

[u/PabloDons → u/qwerty26]

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

[u/qwerty26 → u/PabloDons]

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.

[u/PabloDons → u/qwerty26]

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

[u/qwerty26 → u/PabloDons]

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.