>It's not vague. Despite 28 years of effort optimizing JavaScript, WebAssembly outperforms it:
That's great that WebAssembly outperforms Javascript. But only in processing power - and not all programming tasks require the most bleeding-edge performance. User interfaces do not require the speed of WASM. They require being easy to develop, and Javascript is almost always the right solution for UI. None of the WASM frameworks you mentioned are used very much, there's simply not the ecosystem for them that there is for Javascript for user interfaces.
And this is what they mean when they say "use the right tool for the job". I'm not going to use ffmpeg ported to Javascript, because that would be slow - of course I'm going to use ffmpeg in WASM to transcode video in the browser. And I'm not going to replace React with something in WebAssembly no matter what language, because it's just far easier to write the UI in React. Or even jQuery, or even just plain old vanilla Javascript.
Javascript is a very easy language to work with, in spite of what the people that don't really understand Javascript think about it. The only reason to do UI in WASM is that you don't understand Javascript or you have an irrational hate for it, or "because reasons". But sure, do whatever you want to do, I'm in no way saying you can't. Just don't expect that WASM will be replacing Javascript in any real way, anytime soon.
So you mean JavaScript is less efficient than WebAssembly, which means every time a piece of JavaScript runs on the billions of systems running its suboptimal runtime there is higher power usage, which means there is a greater demand on energy supply, which means there are greater carbon emissions, which means more global warming, which means we're closer to a climate change catastrophe than ever before.
So not only is JavaScript slow it's also an ecological disaster.
You've convinced me. Brendan Eich has a lot to answer for.
If you're a large hosting provider like a Google or a Microsoft or an Amazon or a CloudFlare, you want to be eco. You want to be eco for PR reasons, for financial reasons, and for practical engineering reasons.
Yes, let's save the electrons so we can mine bitcoin with them. /s
oh, oh, wait - I have an idea! Let's just write everything in 8-bit assembly language, that will let us really optimize and save all the electrons for bitcoin mining! /s
You really are barking up the wrong tree. Going after Javascript as if it's the reason the planet is doomed, or even makes any difference at all in the grand scheme of things, is just looney tunes crazy. Sorry, it just is.
I stopped using semicolons in my code to support your cause. Think of all the power it will save by not switching on a few pixels! We'll save the world! /s
You can access the DOM through JavaScript glue. These Rust WASM frameworks do that:
- Leptos: https://www.leptos.dev/
- Sycamore: https://sycamore.dev/
- Yew: https://yew.rs/
- Dioxus: https://dioxuslabs.com/
Eventually you won't need the glue.
> Okay, so use canvas instead and do all UI inside WASM?
You can do that too. That's what this VB6 clone written in C# and compiled to WebAssembly does:
- https://bandysc.github.io/AvaloniaVisualBasic6/
- https://github.com/BAndysc/AvaloniaVisualBasic6
> vague "JavaScript limitations"
It's not vague. Despite 28 years of effort optimizing JavaScript, WebAssembly outperforms it:
- https://nuenki.app/blog/bloom_filters_optimisation
- https://jordaneldredge.com/blog/speeding-up-winamps-music-vi...
- https://www.amazon.science/blog/how-prime-video-updates-its-...
- https://web.dev/case-studies/google-sheets-wasmgc
That's a kick to the groin that's tough to walk off.