|
Regarding threads, I am in complete agreement with you; JavaScript is a terrible language. More important than multi-threading is how JavaScript deals with memory; which is more important for a typical websites performance, and many programming languages deliver on both; Go, Rust, C. Electron programs differ. I would like WASM on Electron, moreso, I do not want JavaScript in Electron programs. I only run programs without the browser's sandbox because I trust it will not be hostile. Electron makes it harder to install extensions and investigate its behavior, which removes the entire purpose of an interpreted neutered language. I hate programming for the web, I rarely do it, because it is such a terrible experience. I don't doubt that browser-native WASM integration will improve it. For a typical user, having a browser-equivalent experience for extensions on native binaries is practically impossible (game mods are rarely a good experience, even with developer support). More important than all that, which you are missing, is that all these websites, are not slow because of JavaScript; I am willing to bet (I really am) that the performance of these websites will not improve with WASM. To clarify, I do not doubt that WASM is faster than JavaScript, rather, I doubt that those that made those websites, would have made a faster website using WASM. I support my claim with the following: - The plethora of terrible native programs that are regularly made by those same organizations (Visual Studio; a native program, which should be faster than any WASM program, is much slower than VS Code. VS Code has less features, but how many features would you need to remove from Visual Studio to achieve VS Code's performance; or for a long shot, Zed's performance).
- Computers have gotten thousands of times faster, and, yet those programs have gotten slower, in absolute terms. See my argument about functionality in the previous point (all AWS does is render text, how could they have made it to be that slow).
- Other, more complex tasks are done in JavaScript with good performance, no doubt they would be faster executed on WASM, but it takes from their excuse when you have a demonstrative example to the alternative.
- I find that it is rare if ever that performance is addressed in those organizations, only when a program is unbearably slow, does someone then try and improve it, still, a thousand cuts kill. Please remember that through all that, I am not arguing against WASM for no reason, but for very severe usability concerns. 10 years ago, rarely did a website offer a dark mode, but, it is my belief that extensions such as dark reader allowed for mass adoption. It would deprive those many with particular accessibility needs their ability to control the execution of these programs. Websites are nowadays the primary interface with government and banking services. My banking app requires location access to function, it is a pain for end users to spoof it (although it does not deter any bad actors who were dedicated enough to get access to your credentials), yet the same bank (and the regulators that mandate it) do not bother to require that for the web, because spoofing it there is trivial. Unfortunately, we can't fix the whole world's problems, but we can prevent them from ruining the web. Finally, I am sorry for writing such a lengthy reply, and thank you for your time. :/ |