3 ms·

This is the part about the "wasm won't replace JavaScript" argument I see being slept on and why I am so disheartened about how practically no progress has been

This is the part about the "wasm won't replace JavaScript" argument I see being slept on and why I am so disheartened about how practically no progress has been made on it. Most trivial apps don't need to be optimized, and for them, JavaScript is fine. But for complex interactive web applications - it really fuggin matters. Think; - vscode - facebook - jira - linkedin - reddit There's no reason these applications should be slow, single threaded, and consume gigabytes of memory - but that's a limitation of the technology. I know first hand that Atlassian has spent millions of dollars building bundlers in different forms just to save a few milliseconds of load time. Just let me write the front end in Rust and if the browser detects that no JavaScript is running - don't start a JavaScript engine. While you're at it, improve the SharedWorker story so I can effectively share data between tabs (enables cross tab sync, great for chat apps and local caching). I recently tried to make an offline-only application with a wasm-based sqlite implementation in a SharedWorker and the API just doesn't work.

hollerith 7mo ago
I'm going to resist wasm as much as practical. At least that is my current intention based on what I have learned from being a web user for the last 33.5 years. First of all, wasm won't run in my browser (I determined that by evaluating `typeof WebAssembly` in the console tab of Developer Tools), a choice made not by me, but by the maintainer of my browser (Trivalent) -- probably for security reasons. I trust the maintainer of my browser about security-related decisions. Besides security, another reason I am going to resist wasm is that it gives the site owner more power at my expense. The way it is now, I can modify web sites using extensions. For example, for years, I ran an extension that deletes "fixed elements" from web page (which didn't work on 100% of sites with fixed elements, but was still a welcome assistance to me because it worked on about 70% of sites). Wasm would make it more difficult for an extension to modify a site in ways that users with various preferences and various disabilities might want -- because code is more difficult to modify than data is, and the way web pages are now, there is a lot of data in a web page stored in 'locations' that an extension can programmatically find and modify. In summary, site owners already have too much control over my experience (relative to me and authors of software such as a browser extension acting on my behalf), and wasm would give them even more control. It would be one thing if I used the web mainly to run sophisticated applications. I do not: I use it mainly to find simple data resources, mostly text and URLs, written by ordinary people such as yourself. When anyone anywhere wants to get some information out to the world and consider how best to do that, 99% percent of the time, the first thought that comes to mind is to put some text or maybe a video or some other kind of data on the web. I see sentiments like the one you expressed just now as interfering with the flow of this text or other kind of data to me -- by making the process more complicated, less customizable by the user and giving "middlemen" like advertiser more ways to profit from this flow. Again: I never wanted or asked for a platform for the delivery of sophisticated applications over the internet (using web protocols) to get all mixed up and combined with the world's most important and most convenient platform that ordinary users (i.e., not site owners or professional technologists for the most part) use to publish and consume simple data objects like text and URLs and such.
- MintPaw 7mo ago
  > The way it is now, I can modify web sites using extensions This isn't related too directly to WASM, what you want is DOM rendering only, you would theoretically reject canvas and WebGL rendering I imagine. But you could create DOM nodes with WASM. The only difference is that WASM is not as easy to decompile, but I can't imagine you're really unminifiying and patching Javascript are you?
  - hollerith 7mo ago
    Yes, I disabled WebGL many years ago (and Flash many years before that) when I was running Google Chrome. These months, I run Trivalent, which has it and WebGPU disabled by default. I'm not a web dev, so maybe directing my hatred and resentment at wasm like I did in my first comment is a mistake. I don't like the idea of a site that draws its whole UI to a canvas (for reasons you can probably understand) and I have been assuming that that is impractical in just Javascript and that in practice, wasm is needed for that. According to one of those services that gives fast answers to questions, Vanadium (the browser of the GrapheneOS project, which I also trust to give security recommendations) has wasm enabled, but that is a new development. Before late 2025, wasm worked only when JavaScript JIT was enabled, and the default was to have it disabled, which is how most users left it. It was possible for the user to enable it only on a few sites chosen by the user (per-site configurability). I did not mean to broadcast misinformation, and will be more careful in the future. I do know that when the web gets new capabilites to make it a better application-delivery platform, my experience of the web strongly tends to get worse. The introduction of HTML5 and other technologies circa 2006 for example was a very salient example of that.
- apatheticonion 7mo ago
  1) Wasm wouldn't prevent you from running those client scripts (e.g. remove fixed elements). That would still just be a script that modifies the DOM from an extension after the page is rendered/dom mutations occur. 2) wasm makes serving static content practical as server side rendering is economical. My previous employer, for instance, spends tens of millions of dollars every year running SSR servers - almost all of that would be eliminated if the backend could just run the client as wasm. 3) Scrapers (think puppeteer) would be faster and more resource efficient because they wouldn't need to start a JavaScript runtime to load a page. 4) You don't use Electron apps? 5) You may not, but everyone else uses rich interactive web applications. Think of the energy usage and cost savings there would be to the world.
djmips 7mo ago
Geez. if you need Wasm to solve this then I just don't know...
- apatheticonion 7mo ago
  1) Try to use multi-threading on the web 2) It's not just me, all of the apps listed have the same issues. I know that in addition to Atlassian, Meta and Canva have sunk millions of dollars into writing custom bundlers.
AlOwain 7mo ago
I realize this is not an orthodox view, but WASM won't make the typical user have a better experience. I think it could improve Photopea, the various office suite programs, and perhaps unknown unknowns. But, much more important than the uncertain is the current Web which will become less accessible and closed. The ease in reverse engineering JavaScript has more than once shown negligence and malice by Website developers (one example is the recent Google scandal, where they were diminishing the user experience on competing browsers). If I wanted to run trusted programs, I would have used native binaries.
- apatheticonion 7mo ago
  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 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.

hollerith 7mo ago

I'm going to resist wasm as much as practical. At least that is my current intention based on what I have learned from being a web user for the last 33.5 years. First of all, wasm won't run in my browser (I determined that by evaluating `typeof WebAssembly` in the console tab of Developer Tools), a choice made not by me, but by the maintainer of my browser (Trivalent) -- probably for security reasons. I trust the maintainer of my browser about security-related decisions. Besides security, another reason I am going to resist wasm is that it gives the site owner more power at my expense. The way it is now, I can modify web sites using extensions. For example, for years, I ran an extension that deletes "fixed elements" from web page (which didn't work on 100% of sites with fixed elements, but was still a welcome assistance to me because it worked on about 70% of sites). Wasm would make it more difficult for an extension to modify a site in ways that users with various preferences and various disabilities might want -- because code is more difficult to modify than data is, and the way web pages are now, there is a lot of data in a web page stored in 'locations' that an extension can programmatically find and modify. In summary, site owners already have too much control over my experience (relative to me and authors of software such as a browser extension acting on my behalf), and wasm would give them even more control. It would be one thing if I used the web mainly to run sophisticated applications. I do not: I use it mainly to find simple data resources, mostly text and URLs, written by ordinary people such as yourself. When anyone anywhere wants to get some information out to the world and consider how best to do that, 99% percent of the time, the first thought that comes to mind is to put some text or maybe a video or some other kind of data on the web. I see sentiments like the one you expressed just now as interfering with the flow of this text or other kind of data to me -- by making the process more complicated, less customizable by the user and giving "middlemen" like advertiser more ways to profit from this flow. Again: I never wanted or asked for a platform for the delivery of sophisticated applications over the internet (using web protocols) to get all mixed up and combined with the world's most important and most convenient platform that ordinary users (i.e., not site owners or professional technologists for the most part) use to publish and consume simple data objects like text and URLs and such.

MintPaw 7mo ago
> The way it is now, I can modify web sites using extensions This isn't related too directly to WASM, what you want is DOM rendering only, you would theoretically reject canvas and WebGL rendering I imagine. But you could create DOM nodes with WASM. The only difference is that WASM is not as easy to decompile, but I can't imagine you're really unminifiying and patching Javascript are you?
- hollerith 7mo ago
  Yes, I disabled WebGL many years ago (and Flash many years before that) when I was running Google Chrome. These months, I run Trivalent, which has it and WebGPU disabled by default. I'm not a web dev, so maybe directing my hatred and resentment at wasm like I did in my first comment is a mistake. I don't like the idea of a site that draws its whole UI to a canvas (for reasons you can probably understand) and I have been assuming that that is impractical in just Javascript and that in practice, wasm is needed for that. According to one of those services that gives fast answers to questions, Vanadium (the browser of the GrapheneOS project, which I also trust to give security recommendations) has wasm enabled, but that is a new development. Before late 2025, wasm worked only when JavaScript JIT was enabled, and the default was to have it disabled, which is how most users left it. It was possible for the user to enable it only on a few sites chosen by the user (per-site configurability). I did not mean to broadcast misinformation, and will be more careful in the future. I do know that when the web gets new capabilites to make it a better application-delivery platform, my experience of the web strongly tends to get worse. The introduction of HTML5 and other technologies circa 2006 for example was a very salient example of that.
apatheticonion 7mo ago
1) Wasm wouldn't prevent you from running those client scripts (e.g. remove fixed elements). That would still just be a script that modifies the DOM from an extension after the page is rendered/dom mutations occur. 2) wasm makes serving static content practical as server side rendering is economical. My previous employer, for instance, spends tens of millions of dollars every year running SSR servers - almost all of that would be eliminated if the backend could just run the client as wasm. 3) Scrapers (think puppeteer) would be faster and more resource efficient because they wouldn't need to start a JavaScript runtime to load a page. 4) You don't use Electron apps? 5) You may not, but everyone else uses rich interactive web applications. Think of the energy usage and cost savings there would be to the world.

djmips 7mo ago

Geez. if you need Wasm to solve this then I just don't know...

apatheticonion 7mo ago
1) Try to use multi-threading on the web 2) It's not just me, all of the apps listed have the same issues. I know that in addition to Atlassian, Meta and Canva have sunk millions of dollars into writing custom bundlers.

AlOwain 7mo ago

I realize this is not an orthodox view, but WASM won't make the typical user have a better experience. I think it could improve Photopea, the various office suite programs, and perhaps unknown unknowns. But, much more important than the uncertain is the current Web which will become less accessible and closed. The ease in reverse engineering JavaScript has more than once shown negligence and malice by Website developers (one example is the recent Google scandal, where they were diminishing the user experience on competing browsers). If I wanted to run trusted programs, I would have used native binaries.

apatheticonion 7mo ago
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 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.