While web development is fine enough - spending a bit of time doing native development makes it feel like web technologies are very limiting in what experiences are possible. It's also very obvious how limiting they are in the quality of user experience, both for end users AND developers.

The first thing to highlight is that multithreading is possible but extremely impractical on the web, and even if you succeed, it's slow. Check out Surma's video on it: https://www.youtube.com/watch?v=7Rrv9qFMWNM

Using threads unlocks so much performance, from everything to time-to-first-paint, time-to-interactive all the way to the general feel of the application.

That sort of optimization is trivial in languages designed for it (like Rust or Go).

Developer experience on the web is unbelievably poor. TypeScript is, semantically, fantastic, but then you have to build it - do you use swc or tsc, do you use webpack, rollup, rspack, vercel's stack, etc? Once you build it, what are your transpilation targets - did you even configure them or are you building bundles that are 40% larger for no reason? The runtime overhead of bundles is also non trivial.

Languages like Rust are maybe 20% more complicated than TypeScript - but they have TSX (also Vue templates, Angular templates, whatever) baked into the _core_ language - requiring no external transpilers or LSPs.

That doesn't mean every application is a good candidate for native/wasm - but the applications that would benefit would benefit end users and developers immensely.

The push back really makes no sense to me. Everyone complains about Electron (and OP about Linkedin, and everyone about Jira) being slow or eating up half their ram - yet with the same breath say that wasm would have no benefit.

> The ease in reverse engineering JavaScript

It's not as easy to reverse engineer native binaries - but you can do it pretty easily and produce the equivalent of minified source code from it. This is how emulators and custom firmware is created. It wouldn't prevent security researchers from identifying negligence.

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. :/