11 ms·

What happened to WebAssembly

• benrutter 9mo ago
  I think one the big things with web assembly is it's shear potential is huge. In theory, WASM could be a single cross platform compile target, which is kind of a CS holy grail. It's easy to let your mind spin up a world where everything is web assembly, a desktop enivornment, a server, day to day software applications. After I've imagined all of that, being told web assembly helps some parts of Figma run faster feels like a big let down. Of course that isn't fair, almost nothing could live up to the expectations we have for WASM. Its development is also by committee, which is maybe the best option for our current landscape, but isn't famous for getting things going quickly.
  • vbezhenar 9mo ago
    You can use javascript as a single cross platform compile target. What's the difference?
    • merlindru 9mo ago
      WASM works with any language and can be much faster than javascript
      • vbezhenar 9mo ago
        You can compile any language to JavaScript. jslinux compiled x86 machine code to JavaScript. So basically wasm is some optimisation. That's fine but it's not something groundbreaking. And if we remove web from the platform list, there were many portables bytecodes. P-code from Pascal era, JVM bytecode from modern era and plenty of others.
        • IshKebab 9mo ago
          > some optimisation That's underselling it a bit IMO. There's a reason asm.js was abandoned.
          • gf000 9mo ago
            Both undersell and oversell. There are still cases where vanilla JS will be faster. And AFAIK asm.js is the precursor to WASM, like the early implementations just built on top of asm.js's primitives.
          • creata 9mo ago
            Wikipedia mentions that Wasm is faster to parse than asm.js, and I'm guessing Wasm might be smaller, but is there any other reason? I don't think there's any reason for asm.js to have resulted in slower execution than Wasm.
            • IshKebab 9mo ago
              > I don't think there's any reason for asm.js to have resulted in slower execution than Wasm The perfect article: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... Honestly the differences are less than I would have expected, but that article is also nearly a decade old so I would imagine WASM engines have improved a lot since then. Fundamentally I think asm.js was a fragile hack and WASM is a well-engineered solution.
              • gr4vityWall 9mo ago
                After reading the, I don't feel convinced abtout the runtime performance advantages of WASM over asm.js. he CPU features mentioned could be added to JS runtimes. Toolchain improvements could go both ways, and I expect asm.js would benefit from JIT improvements over the years. I agree 100% with the startup time arguments made by the article, though. No way around it if you're going through the typical JS pipeline in the browser. The argument for better load/store addressing on WASM is solid, and I expect this to have higher impact today than in 2017, due to the huge caches modern CPUs have. But it's hard to know without measuring it, and I don't know how hard it would be to isolate that in a benchmark. Thank you for linking it. It was a fun read. I hope my post didn't sound adversarial to any arguments you made. I wonder what asm.js could have been if it was formally specified, extended and optimized for, rather than abandoned in favor of WASM.
    • hnb2137 9mo ago
      WASM allows you to run some parts of the application a bit faster. ;)
    • lxgr 9mo ago
      Javascript comes with mandatory garbage collection. I suppose you could compile any language to an allocation-free semantic subset of Javascript, but it's probably going to be even less pretty than transpiling to Javascript already is.
      • creata 9mo ago
        > it's probably going to be even less pretty than transpiling to Javascript already is. I don't see how it'd be much different to compiling to JavaScript otherwise. Isn't it usually pretty clear where allocations are happening and how to avoid them?
        • lxgr 9mo ago
          “Pretty clear” is good, “guaranteed by language specifications” is better. Why reverse-engineer each JS implementation if you can just target a non-GC runtime instead?
    • yencabulator 9mo ago
      WASM, and asm.js before it, roughly exist because Javascript is such a bad compile target.
  • x3haloed 9mo ago
    There’s no reason we shouldn’t be replacing our containers with WASI. Containers are absolutely miserable things that should just be VMs (in the WASM sense, not in the “run Linux in a virtual X86” sense) The tooling is just not there yet. Everyone is just stuck on supporting Docker still.
    • IshKebab 9mo ago
      Yeah the real answer is that all of this stuff is still a work in progress. Last I checked WASI doesn't have a concept of "current directory" for example, so porting software is not trivial. Also WASI is a way of running a single process. If your app needs to run subprocesses you'll need to do more work.
    • torginus 9mo ago
      Imo stuff like Flatpak has the right idea - provide a rich but controllable set of features, API/ABI compatibility, while providing zero overhead isolation (same as docker since it relies on the same APIs). I also rather like the idea of deploying programs rather than virtual machines. Docker's cardinal sin imo is that it was designed as a monetizable SaaS product, and suffers from inner platform effect, reinventing stuff (package management, lifecycle management etc) that didn't need to be invented.
    • hosh 9mo ago
      You mean like this? https://docs.krustlet.dev/howto/wasm/ https://docs.krustlet.dev/howto/wasm/ Or this? https://podman-desktop.io/blog/wasm-workloads-on-macos-and-windows-with-podman https://podman-desktop.io/blog/wasm-workloads-on-macos-and-w...
    • creata 9mo ago
      But what's the benefit of replacing containers with WASI? The performance would be worse, and it would be harder to integrate with everything else. It might be more secure, I guess.
    • HendrikHensen 9mo ago
      It helps if you actually qualify statements such as "Containers are absolutely miserable things". I'm in a world where were using containers extensively, and I don't experience any issues whatsoever about which one might thing "WASI would be the solution to this".
  • shevy-java 9mo ago
    Well - the problem is... the "in theory" means that nobody will bet on WASM if it is not really going to be useful. People use HTML, CSS, JavaScript - that has been shown to be very useful. WASM is not useless but how can people relate to it? It is like an alien stack for most people.
    • frez1 9mo ago
      The way things usually gain traction is when a big tech company has success experimenting with it. it happened with node way back and happening with rust now. the fact we haven't heard much about was use is probably because it isnt as valuable as we think, or no one has played around with it yet to find out
      • matt_kantor 9mo ago
        > when a big tech company has success experimenting with it TFA has many examples of big tech companies using Wasm in production. It's not exhaustive either, e.g. the article doesn't mention: - Google using it as a backend for Flutter and to implement parts of Google Maps, Earth, Meet, Sheets, Keep, YouTube, etc - Microsoft using it in Copilot Studio - eBay using it in their mobile app - MongoDB using it for Compass - Amazon supporting it in EKS - 1Password using it in their browser extension - Unity having it as a build target (And this was just what I found with some quick web searches; I'm sure there are many other examples.) --- > the fact we haven't heard much about was use is probably because it isnt as valuable as we think One of the conclusions of the article is that it's mostly used in ways that aren't very visible.
    • azakai 9mo ago
      It is totally fine if most people don't relate to wasm - it's good for some things, but not most things. As another example, most web devs don't use the video or audio tag, I'd bet, and that's fine too. Media, and wasm, are really important when you need them, but usually you don't.
  • daef 9mo ago
    I recommend you watch [0] if you haven't seen it yet, it describes the history of javascript, iirc until 2035. [0] https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
    • afandian 9mo ago
      Thanks! There's a video I've been looking for, for years. It's about web technologies and recusion ("I put a VM in side a VM"), and it's satire / comedy. It might be this one I'm thinking of, as it closely fits the bill. But something is telling me it's not, and that it was published earlier. Any ideas?
  • torginus 9mo ago
    Like the gifted kid who lives with his mom at 30, at some point in time, we have to stop talking about potential and start talking about results. Theory and practice doesn't match in this case, and many people have remarked that companies that sit on the WhatWG board have vested interest in making sure their lucrative app stores are not threatened by a platform that can run any app just as well. I remember when Native Client came to the scene and allowed people to compile complex native apps to the web that run at like 95% of native speed. While it was in many ways an inelegant solution, it worked better than WebAssembly does today. Another one of WebAssembly's killer features was supposed to be native web integration. How JS engines work is that you have an IDL that describes the interface of JS classes which is then used to generate code to bind to underlying C++ implementations. You could probably bind those to Webassembly just as well. I don't think a cross-platform as in cross CPU arch matters that much, if you meant 'runs on everything' then I concur. Also the dirty secret of WebAssembly is that it's not really faster than JS.
    • PunchyHamster 9mo ago
      I start to think that's why there is still no DOM for the WASM and we have to pingping over JS > Also the dirty secret of WebAssembly is that it's not really faster than JS. That is near purely due to amount of work it took to make that shitty language run fast. Naive webassembly implementation will beat interpreted JS many times over but modern JIT implementations are wonder.
      • moralestapia 9mo ago
        I don't dislike JS but the reason why it's fast is because billions were poured into making that happen. V8 is a modern engineering marvel.
        • rob74 9mo ago
          Yeah, and like many engineering marvels, it was instantly misused for purposes its creators didn't intend and became a scourge on humanity (looking at you NodeJS & co).
        • 9mo ago
  • jiggawatts 9mo ago
    > WASM could be a single cross platform compile target, which is kind of a CS holy grail. The JVM says "Hello!" from 1995.
    • benrutter 9mo ago
      Hello back! The JVM is a great parallel example. Anyone listening to the hype in the early days based around what the JVM could be would surely be disappointed now. It isn't faster than C, it doesn't see use everywhere due to practical constraints, etc. But you'd be hard pushed to say the JVM is a total failure. It's used by lots all round the world, and solves real problems, just not the ones we were hoping it would solve. I suspect the future of WASM looks something like that.
      • DonHopkins 9mo ago
        Now JVM's sole purpose is to solve Larry Ellison's problems, so if you're not Larry Ellison and you don't have the same problems he does, then it's a total failure caging you, but a predatory trap serving him. None of the technical arguments for JVM matter any more. It's just bait to trick you into sticking your hand under the lawnmower and helping Larry Ellison solve his problems.
        • pjmlp 9mo ago
          Except JetBrains, Red-Hat, SAP, Azul, Oracle, Google, Microsoft, PTC, Aicas, Cisco, Ricoh, microEJ, Bluejay,... are also part of the Java party.
          • jiggawatts 9mo ago
            Microsoft largely cloned the Java Runtime to create the .NET Runtime and similarly cloned Java to create C#. The two are so similar that Java bytecode to .NET bytecode translators exist. With some, it is possible to take a class defined in Java, subclass it with C#, call it from Java, etc...
  • whywhywhywhy 9mo ago
    > being told web assembly helps some parts of Figma run faster feels like a big let down. Not really when tools like Figma were not really possible before it
    • creata 9mo ago
      What was preventing the development of Figma before Wasm? For developing brand new code, I don't think there's anything fundamentally impossible without Wasm, except SIMD.
      • azakai 9mo ago
        Performance. JS can be as fast as wasm, but generally isn't on huge, complex applications. Wasm was designed for things like Unity games, Adobe Photoshop, and Figma - that is why they all use it. Benchmarks on such applications usually show a 2x speedup for wasm, and much faster startup (by avoiding JS tiering). Also, the ability to recompile existing code to wasm is often important. Unity or Photoshop could, in theory, write a new codebase for the Web, but recompiling their existing applications is much more appealing, and it also reuses all their existing performance work there.
    • pjmlp 9mo ago
      Yet Figma like tools do exist without Wasm.
  • xnx 9mo ago
    *sheer shear potential = likely to break apart
    • benrutter 9mo ago
      Haha, shear potential seems like a great accidental pun. I'll have to find an excuse to use it deliberately over the next week.
  • deleted 9mo ago
    [deleted]
  • lionkor 9mo ago
    Java and JVM all over again
• doloop 9mo ago
  I was wondering if wasm was used to transpile jsx in browserland.
• Zedriv 9mo ago
  Love WASM! Still hoping for proper multithreading someday.
  • creata 9mo ago
    Emscripten has pthreads. You can multithread it yourself using web workers and shared memory. What's missing?
• fourside 9mo ago
  > On every WebAssembly discussion, there is inevitably one comment (often near the top) asking what happened The meat of the article is informative, but the headline and motivation is based on this statement. It’s doesn’t reflect my experience but maybe I just don’t hang out in the same internet spots as the OP. > We don’t yet see major websites entirely built with webassembly-based frameworks I don’t know why this entered into the zeitgeist. I don’t think this was ever a stated goal of the WebAssembly project. I get the sense that some people assumed it and then keep wondering why this non-goal hasn’t been realized.
• johnfn 9mo ago
  I'm actually using WASM (from Rust) on a image editor project. It's pretty good - I see around a 4x perf improvement over JS depending on the benchmark. But what happened? Why am I not using it for all of my other random side projects? I posit that the JS ecosystem got so incredibly good that it it's a no-brainer for a very large percentage of workflows. React + Vite + TypeScript is an incredibly productive stack. I can use it to build all but the most demanding apps productively. Additionally, JS is pretty fast these days, so the speed boost from WASM isn't actually that meaningful for most use cases. Only really heavy use cases like media editing or Figma-like apps really benefit from what WASM has to offer.
• charcircuit 9mo ago
  A big thing overlooked with speed is binary size. WebAssembly is incredibly inefficient at storage space. For people still on DSL they will have to wait seconds (or minutes in the case of Godot) for the blob to download before execution can start. Meanwhile javascript will be much faster to download since it is smaller and javascript can execute while it is downloading.
  • IshKebab 9mo ago
    It's more that JavaScript comes with a large standard library already available. You don't need to ship code to print integers or parse JSON or Unicode tables etc.
  • CryZe 9mo ago
    It depends. If you are compiling a high level GC language to WasmGC then there's really close to no reason why it would be larger than JS.
    • gf000 9mo ago
      That is, if the source language's GC model is compatible with Wasm's.
      • WorldMaker 9mo ago
        WASM's current GC model is mostly about sharing large byte buffers. It's on about the order of OS-level memory page management. Mostly it is getting used to share memory surfaces to JSON serialization/deserialization without copying that memory across the WASM to JS boundary anymore. It will be a while before WASM GC will look close to any language's GC.
  • s-macke 9mo ago
    WebAssembly itself is not that inefficient in storage. It is mostly the usual bloat that comes with binaries. For example, Go binaries have to provide a full runtime, including garbage collection. If size is your top priority, you can produce very small binaries, for example with C. Project [0] emulates an x86 architecture, including hardware, BIOS, and DOS compatibility, and ends up with a WebAssembly size of 78 kB uncompressed and a 24 kB transfer size. [0] https://github.com/s-macke/FSHistory https://github.com/s-macke/FSHistory
• apignotti 9mo ago
  We use WebAssembly aggressively at Leaning Technologies across our tools. WebAssembly makes it possible to: * Run x86 binaries in the browser via JIT-ting (https://webvm.io https://webvm.io) * Run Java applications in the browser, including Minecraft (https://browsercraft.cheerpj.com https://browsercraft.cheerpj.com) * Run node.js containers in the browser (https://browserpod.io https://browserpod.io) It's an incredibly powerful tool, but very much a power-user one. Expecting your average front-end logic to be compiled in WebAssembly does not make much sense.
  • sfn42 9mo ago
    > Expecting your average front-end logic to be compiled in WebAssembly does not make much sense. Why not? .NET Blazor and others already do that. In my eyes this was the whole hype of WASM. Replace JS. I don't give a crap about running node/java/whatever in the browser, why would i want that? I can run those outside the browser. I mean sure if you have some use case for it that's fine and I'm glad WASM lets you do it but I really don't see why most devs would care about that. We use the browser for browsing the web and displaying our websites. To me the browser is for displaying websites and I make websites but I loathe JS. So being able to make websites without JS is awesome.
    • gf000 9mo ago
      Because people don't want to load 300MB for a simple website (and this is blocking the first render, not just loading in the background). Not every language is a good source for targeting WASM, in the sense that you don't want to bring a whole standard library, custom runtime etc with you. High-level languages may fare better if their GC is compatible with Wasm's GC model, though, as in that case the resulting binaries could be quite small. I believe Java-to-wasm binaries can be quite lean for that reason. In c#'s case, it's probably mostly blazor's implementation, but it's not a good fit in this form for every kind of website (but very nice for e.g. an internal admin site and the like)
      • sfn42 9mo ago
        A modern blazor wasm app is nowhere near 300mb. There are techniques to reduce this size like tree shaking. There's no need to include lots of unused libraries. Modern Blazor can do server side rendering for SEO/crawlers and fast first load similar to next.js, and seamlessly transition to client side rendering or interactive server side rendering afterwards. Your info/opinion may be based on earlier iterations of Blazor.
• deleted 9mo ago
  [deleted]
• ceving 9mo ago
  The data exchange between host and guest is still unspecified. You can not access host objects from Wasm. Most do just string serialization, which is not fast. Or they write libraries for some particular languages, which damages the universal idea of Wasm. And WASI seems to be quite controversial: https://www.assemblyscript.org/standards-objections.html https://www.assemblyscript.org/standards-objections.html
  • saghm 9mo ago
    Reading though that link is very confusing as someone who hasn't been actively following all of the various standards and organizations in detail. Quite a lot of the technical claims seem a bit vague and hard to evaluate without being more of an expert (like the repeated complaints about WASI being bad for Java/JavaScript/"the Web"). Pretty much the only concrete technical concern I could glean is that whoever wrote that was extremely unhappy about the use of UTF-8 over UTF-16, which I can understand feeling strongly about, but I also feel like the situation where there's a choice between the way Java/JavaScript/Windows does it and the way a lot of other things do it isn't exactly an original problem to WebAssembly. There's merit in the idea of sticking with what a lot of web stuff already uses, but it's not really that crazy to consider that a new standard would be the place where you might try to design with an eye towards shaping the future rather than always following the past. Moreso than anything technical though, there sure seems to be a lot of bad blood between the group of people behind AssemblyScript and the people behind WASI. This feels like a classic case of small initial technical disagreements spiraling out of control and turning into a larger conflict fueled by personalities and organizational politics. I agree that overall this doesn't add confidence to the WebAssembly ecosystem as a whole, but it's not clear to me that the obvious conclusion is "WASI is controversial" as "WebAssembly seems like it might have a problem with infighting".
    • ceving 9mo ago
      Wasm has a fundamental problem: int64 is an insufficient data type for real use cases. If you want to create some kind of plugin system based on Wasm, you need to exchange structured data. But most languages disagree about the memory layout. Dynamic languages do tagging, compiled languages do not. And the UTF issue shows that even with strings, there's still no real agreement. Furthermore, there are now competing interest groups within the Wasm camp. Wasm originally launched as a web standard: an extension of the JavaScript environment. However, some now want to use Wasm as the basis for replacing containers: an extension of a POSIX environment.
• shevy-java 9mo ago
  I am kind of disappointed with regard to WebAssembly. There were several articles that promoted it heavily - aka the hype phase. And then ... nothing really materialized. If you look at, for instance, ruby WASM, https://github.com/ruby/ruby.wasm https://github.com/ruby/ruby.wasm - there is virtually zero real documentation. Granted, this is a specific problem of ruby, and japanese devs not understanding english; but when you search for webassembly, contrast it to the numerous tutorials we have with regards to HTML, CSS, JavaScript. I get it, it is younger, it is harder than the other three tech stacks, but virtually nothing really improves here. It is like a borne-dead technology that has only a tiny niche, e. g. Rust developers. That's about it. And I fear this is also not going to change anymore. After a while, if the hype fails to deliver, people will lose interest - and a technology will eventually subside. That also happened to e. g. XHTML and the heavy use of XML in general in, say, 2000. I also don't think WebAssembly can be brought back now that the hype stage went off.
• jillesvangurp 9mo ago
  Many of the build tools Javascript people use are written in Rust now. Some of them can be made to run in browsers, via WASM. React, the defacto UI framework for Javascript has a lot of web assembly components. A lot of the npm ecosystem has quietly brought in web assembly. And a lot of UI stuff gets packaged up as web components these days; some of that uses WASM as well. If you pulled the plug on WASM, a lot would stop working and it would heavily impact much of the JS frontend world. What hasn't caught on is modern UI frameworks that are native wasm. We have plenty of old ones that can be made to work via WASM but it's not the same thing. They are desktop UI toolkits running in a browser. The web is still stuck with CSS and DOM trees. And that's one of the areas where WASM is still a bit weak because it requires interfacing with the browser APIs via javascript. This is a fixable problem. But for now that's relatively slow and not very optimal. Solutions are coming. But that's not going to happen overnight. But web frontend teams being able to substitute Javascript for something else is going to require more work. Mobile frontend developers cross compiling to web is becoming a thing though. Jetbrain's compose multiplatform is has native Android/IOS supported now with a canvas rendered web frontend supported in Beta currently. You can actually drive the dom from WASM. There are some RUST frameworks. I've dabbled with using kotlin's wasm support to talk to browser dom APIs. It's not that hard. It's just that Rust is maybe not ideal (too low level/hard) for frontend work and a lot of languages lack frameworks that target low level browser APIs. That's going to take years to fix. But a lot compiles to wasm at this point. And you kind of have access to most of the browser APIs when you do. Even if there is a little performance penalty.
  • marisen 9mo ago
    > React, the defacto UI framework for Javascript has a lot of web assembly components. I'm pretty sure this is just plain false. Do you have an exemple?
    • gf000 9mo ago
      They might mean build dependencies? Or I'm sure there are ready-built components in wasm, but they are most definitely third-party ones.
  • 9mo ago
• rvz 9mo ago
  A solution in search of a very very very tiny problem to solve. Which almost no-one cares about.
• troad 9mo ago
  The folks behind WASM are wilfully blind to the big honking use case that everyone wants (a fully-featured JS replacement, targetable in any language), in favour of an abstract adventure in chasing some ideal Platonic ISA, except there's no obvious market or practical use case for such a thing. WASM will live and die in the browser. I wish the folks behind it would acknowledge that fact and give it sufficient browser interop to finally render JS unnecessary.
  • runarberg 9mo ago
    I see a lot of people declaring that, but I immediately disregard it. In my circles this is a fringe believe. Wasm’s most obvious use case is running x86 binaries in your browser. It is pretty good at that, and that is what most people are using it for. Personally I don‘t see why Wasm needs a different future then the one it is already on.
  • creata 9mo ago
    > a fully-featured JS replacement, targetable in any language Any language can target a combination of JS and Wasm, right now, to get a "fully-featured JS replacement". How would adding more features to Wasm improve that situation?
    • troad 9mo ago
      How does substituting JS for some other JS achieve a goal of replacing JS? If someone wanted to replace C, would you suggest C as a C replacement? That's nonsensical in context. Adding browser interop to Wasm that obviated the need for JS would, obviously, achieve that goal. Hence the improvement.
      • creata 9mo ago
        > If someone wanted to replace C, would you suggest C as a C replacement? If someone wanted to replace C, I would strongly suggest compiling something else to C, yes. That seems kind of obvious. It's how many programming languages that aim to replace C get their start. To put it another way: I can see how [replacing JS as the interface that the human deals with] can be valuable goal, but why is [replacing JS so completely that it doesn't even exist as generated code] so valuable to you?
• mirzap 9mo ago
  Feels like most of the disappointment comes from the wrong expectation. Wasm was never going to replace HTML/CSS/JS for normal frontend work, and JS got good enough that most apps don’t need it anyway. On the other hand, Wasm as a universal runtime (WASI replacing containers, etc.) is clearly still unfinished. Where it has worked is as infrastructure: fast, sandboxed, portable code for the parts that actually need it. A lot of people are already using it indirectly without realizing. So it’s less "what happened to Wasm?" and more "it didn’t become the silver bullet people imagined."
• michalsustr 9mo ago
  We love wasm! You can get pretty far with it. We’re building new machine learning experiment tracker using wasm on the front end. (If you know what Wandb or Neptune is, you should give us a try!) As far as I know, we are the fastest on the market. The multithreaded support is a pain though. https://minfx.ai https://minfx.ai
• Ameo 9mo ago
  It seems to me that Wasm largely succeeded and meets most/all of the goals for when it was created. The article backs this up by listing the many niches in which its found support, and I personally have deployed dozens of projects (both personal and professional) that use Wasm as a core component. I''m personally a big fan of Wasm; it has been one of my favorite technologies ever since the first time I called malloc from the JS console when experimenting with an early version of Emscripten. Modern JS engines can be almost miraculously fast, but Wasm still offers the best performance and much higher levels of control over what's actually running on the CPU. I've written about this in the past. The only way it really fell short is in the way that a lot of people were predicting that it would become a sort of total replacement for JS+HTML+CSS for building web apps. In this regard, I'd have to agree. It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental. I've tried out some of the Wasm-powered web frameworks like Yew and not found them to provide an improvement for me at all. It just feels like an awkwardly bolted-on layer on top of JS and CSS without adding any new patterns or capabilities. Like you still have to keep all of the underlying semantics of the way JS events work, you still have to keep the whole DOM and HTML element system, and you also have to deal with all the new stuff the framework introduces on top of that. Things may be different with other frameworks like Blazor which I've not tried, but I just find myself wanting to write JS instead. I openly admit that it might just be my deep experience and comfort building web apps using React or Svelte though. Anyway, I strongly feel that Wasm is a successful technology. It's probably in a lot more places than you think, silently doing its job behind the scenes. That, to me, is a hallmark of success for something like Wasm.
  • deleted 9mo ago
    [deleted]
  • gritzko 9mo ago
    That is like Linux on a laptop. When you buy a laptop, you pay for Windows anyway.
    • graemep 9mo ago
      Not necessarily. I bought a laptop with Linux preinstalled and its the best thing to do if you buy one with the intent of using Linux on it.
• cjs_ac 9mo ago
  The weakest point in any computer system is the bag of meat operating the thing; the second weakest point is the network. Most web apps that are slow are slow because of the endless chit-chat between client and server across the network, and because too much business logic runs on the client machine, which might be a ten-year-old smartphone. For these apps, improving performance is about minimising the number of HTTP request-response pairs and moving logic to the server, not making the frontend code run faster. > I figure most are under the impression that the advancement of this technology would have had a more visible impact on their work. That they would intentionally reach for and use Wasm tools. > Many seem to think there is a path to Wasm replacing JavaScript within the browser—that they might not need to include a .js file at all. This is very unlikely. This is because most of us are not writing fancy browser-based 3D game engines; we're writing boring enterprisey CRUD apps, and the only things we want from out frontend code are HTTP request-response handling and DOM manipulation. Consequently, the irrelevance of WASM evangelism is frankly boorish.
• forrestthewoods 9mo ago
  WASM works. Except for all the convoluted edge cases where it doesn’t. Also, wasm doesn’t solve enough real problems. JavaScript sucks but is plenty good enough for most things. Wasm unlocks a few things. But it makes no sense for, say, Steam games that are tens of gigabytes. If wasm didn’t exist the internet and world would be… fine? Use JavaScript in a browser or go actual native. The space inbetween for wasm exists but is extremely small. Especially for anything other than cool visualization widgets.
• weinzierl 9mo ago
  "We don’t yet see major websites entirely built with webassembly-based frameworks." The more telling question to me is: Do we see real world websites that are not just tech demos coming out of WASM aficionados circles. Sites that are actually useful to a significant number of people, even if we wouldn't necessarily call them major websites. https://cbva.com/ https://cbva.com/ comes to my mind, but there must be more.
  • okokwhatever 9mo ago
    The "Loading..." message makes it so 90's. I like it.
  • Jweb_Guru 9mo ago
    This website made me suddenly have a huge feeling of loss for what the web could be like. It is so snappy (in the way old static sites could be) but without the page transitions that made them fall out of fashion.
• WhereIsTheTruth 9mo ago
  The sandboxification of WASM is what happened Instead of building a true portable binary format with system access, we got a JavaScript VM from TEMU: - Reference Types - Exception Handling - GC Makes GC'd languages compile better, not system programming Meanwhile, the actually needed capabilities remain blocked forever: - Memory: Still can't mmap, still can't allocate outside linear memory - Networking: Still needs JS interop bullshit - Device: Still need JS interop bullshit and still sandboxed behind browser security model The Result: WASM isn't a serious systems target, it's a compilation artifact for managed languages that could've just targeted JS directly
  • pjmlp 9mo ago
    Correction, some GC languages, the GC doesn't support interior pointers for example.
• ubavic 9mo ago
  From my experience, WASM is great for easily porting existing codebases to the browser. It took me less than a day to download Emscripten, learn a little about WASM, make one toy project, and then port a 20-year-old, 40-KLOC C++ project to the browser [1]. The last part only took me half an hour, and I don't even write C++. [1] https://poincare.matf.bg.ac.rs/~janicic/gclc/ https://poincare.matf.bg.ac.rs/~janicic/gclc/
• stanac 9mo ago
  Anyone knows why docker is dropping wasm workloads? I never heard of anyone using it, I thought it was because wasi hasn't reached "1.0" yet, so ecosystem is still small. Wasm and wasi are very promising, as stated in the article, it's safe/isolated by default, it can target different hardware and almost any popular language (in theory) can be compiled to wasm. It sounds perfect on paper. It's quick to start (quicker than docker). Maybe it will be replacement/supplement for lambda-esque type of workloads. https://docs.docker.com/desktop/features/wasm/ https://docs.docker.com/desktop/features/wasm/
• psychoslave 9mo ago
  >It is almost 1:1 in that you can compile WAT to Wasm and then back to WAT with barely any loss in information (you may lose variable names and some metadata). I love it! It reads like, "you can put your snowman in a oven to obtain water and then the water to a snow machine to get to your initial material state with almost no information lost."
  • everfrustrated 9mo ago
    I was reading a research paper who benchmarked some wasm compilers and the fastest was converting wasm back to c and recompiling it again!
    • vitalnodo 9mo ago
      Can you recall the link?
      • everfrustrated 9mo ago
        see w2c2 in this paper https://www.opencloudification.com/wp-content/uploads/2025/07/comparative_study_WA_runtimes.pdf https://www.opencloudification.com/wp-content/uploads/2025/0... Tho I have mis-remembered it. They transpile wasm back to C and compile that to a native binary.
        • yencabulator 9mo ago
          w2c2 has only 2 mentions. wasm2c is not a clear winner, it's specifically losing several of their benchmarks. In general, using a preexisting compiler as a JIT backend is an old hack, there's nothing new there. It's just another JIT/AoT backend. For example, databases have done query compilation for probably decades by now.
• tdrz 9mo ago
  One thing that happened to WebAssembly is that it allowed for npm packages like PGlite to be created. With a simple `npm install` you now have a PostgreSQL instance in your web or node app, no (connection) strings attached (pun intended). Full disclosure: I am one of the maintainers.
• jkelleyrtp 9mo ago
  I work on Dioxus (Rust WASM framework). WASM for frontend, at least, has been held back by fundamental tools like bundle splitting, hot-reload, debugger symbols, asset integration, etc. We spent a lot of 2025 working on improving this. Vite and friends are really good! I've been working on a big Dioxus project recently and am pretty happy with where WASM is now. The AI tools make working with Rust code much faster. I'm hopeful people gravitate towards WASM frameworks more now that the tools are better.
• MORPHOICES 9mo ago
  [dead]
  • pjmlp 9mo ago
    People keep trying that holy grail since 1958. https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/UNCOL
• pdubroy 9mo ago
  Shameless plug: if you're interested in learning WebAssembly — like really learning the bytecode format and how it works — you might like our book, WebAssembly from the Ground Up: https://wasmgroundup.com https://wasmgroundup.com. It starts with handcrafted bytecode for a minimal Wasm module in JavaScript, and then guides you through the creation of a simple compiler for a toy language.
• currywurst 9mo ago
  WASM (and WebGL) seems to have powered Figma to a $20 billion aquisition offer by Adobe a while ago ; ) It's a fantastic item for the browser toolbox, and i agree with Amea that the "hallmark of success" has been achieved by this technology
• austin-cheney 9mo ago
  Going back a decade I remember numerous comments, in here and Reddit, from developers (typically Java developers) completely desperate for WASM to be a JavaScript replacement. This was despite the design goals of WASM literally stating the opposite. Otherwise, WASM looks like a complete success.
  • pjmlp 9mo ago
    Java developers already had GWT as alternative, no one cares that much.
• rho4 9mo ago
  The author makes beautiful concise statements that make me feel like he has a deep, big-picture kind of understanding of computing. I think this person would be very satisfying to work with, because decisions would be based on a discussion of tradeoffs, and an awareness of similar technologies and approaches throughout computing history.
• BiteCode_dev 9mo ago
  The success of webassembly has not been the "universal language for the web clients" we all expected. But it has been "damn, that's a pretty good sandbox we all can compile to". And of course, it means we can now have safe Python execution services from user input thanks to stuff like pyodide now.
• nabla9 9mo ago
  Technical details only verify Wasm's potential. Wide adoption is not a technical matter. Just like with JVM and other better options before and after it, it's politics, interests and momentum. JVM in the browser was not killed by technology, it was killed by Microsoft. Similarly, we should look who gains and loses relative to other if Wasm becomes mainstream. Easy portability and less platform dependence. Who wants it, who does not? Apple, Microsoft, Google, ... Just like with JVM the Wasm can be killed with wrong embrace. Microsoft Java Virtual Machine (MSJVM) was named in the United States v. Microsoft Corp. antitrust civil actions, as an implementation of Microsoft's "Embrace, extend and extinguish" strategy. Adopt JVM, remove portability with extensions.
• coldtea 9mo ago
  >But I think this alone is not very convincing. We don’t yet see major websites entirely built with webassembly-based frameworks Unless it's something like Figma or a game, why the fuck would they be? So that you get the joy of writing your website in some language that ports to WebAssembly (and is much more difficult to find frameworks and developers for) and not the native Javascript?
• thecupisblue 9mo ago
  As someone who worked actively with webassembly for the last few years, and is about to drop a WASM based framework, here's what happened: - The ecosystem evolved fast, then slow. This caused adoption problems, especially for things such as WASI and Component model, as a lot of folks did it their own way/using 3rd party, which now meant they had to rewrite to this new thing that still isn't fully properly supported everywhere. - The way it's "developed" means a lot of things are distributed, unsynced and have different support levels based on the engine you're using. This causes confusion among developers, especially since you have to go from reading an article, to reading a spec, to reading a github issue, then you're 3 repositories deep reading random rust code at 2 AM trying to figure out if you can rely on this stranger's fork just to try something out that should have been dead simple. - Both of these combined can lead to even greater confusion for our LLM's, as they are trained on varied data which is by now stale, so they can often misunderstand things or look for things that aren't there anymore, just like us humans would. - And now let's focus on the biggest and most important one IMO: Javascript/Typescript support. That is the holy grail for any technology that wants to be a widely adopted intermediary. While it is possible, you are layering hacks on hacks and begging that the next user won't break it all. Until my users can bring whatever they're using with them, the transition isn't really worth it, and writing my own wiring for every possible combination/need is quite unnecessary. We got a step closer with Web Containers, but by that time a lot of folks already moved onto Bun.
  • deleted 9mo ago
    [deleted]
  • matt_kantor 9mo ago
    I don't think I understand your last point. Could you elaborate? What does "Javascript/Typescript support" mean to you (i.e. what specific features/capabilities are missing from the current engines)?
    • thecupisblue 9mo ago
      I mean compiling JS/TS to WASM or running a JS runtime like bun inside WASM
• pjmlp 9mo ago
  Tooling is holding back WebAssembly. It is very hard to debug WebAssembly applications, depending on the source language, we are still on printf debugging kind of experience. Even the DWARF plugin for Chrome (only, nowhere else), hasn't been updated since 2023. Then there is the whole experience, again depending on the language, to produce a .wasm file, alongside the set of imports/exports for the functions, instead of a plain "-arch=wasm". GC support is now available, however it is a "yes but", because it doesn't support all kinds of GC requirements, thus some ecosystems like .NET, still need to ship their own. Finally we have WIT trying to be yet another go at COM/CORBA/gRPC.
  • embedding-shape 9mo ago
    > Then there is the whole experience, again depending on the language, to produce a .wasm file, alongside the set of imports/exports for the functions, instead of a plain "-arch=wasm". Doesn't the "WASM Components Model" kind of solve this? I've been hacking on a WASM-app runner (in Rust) which basically loads tiny apps that are compiled into "Components", and seems simple enough to me to use and produce those.
    • pjmlp 9mo ago
      Not really, you have a blessed experience by using the language most people on WebAssembly ecosystem are using nowadays.
  • valadaptive 9mo ago
    I second this; the tooling is somehow still not there after 10 years. - The main toolchain for compiling existing C codebases to WebAssembly is Emscripten. It still hasn't escaped its tech-demo origins, and it's a rats' nest of compiler flags and janky polyfills. There are at least 3 half-finished implementations of everything. It doesn't follow semver, so every point release tends to have some breaking changes. - The "modern" toolchain, wasi-sdk, is much more barebones. It's getting to the point of being usable, but I can't use it myself because it ships a precompiled libc and libc++ that use `-O3`, whereas Emscripten recompiles and caches the sysroot and uses `-Oz` if I tell it to. This increases the code size, which is already quite large. - LLVM is still not very good at emitting optimized WebAssembly bytecode. - Engines are still not very good at compiling WebAssembly bytecode to optimized machine code. - Debug info, as you mentioned, is a total mess. - Rust's WebAssembly tooling is on life support. The rustwasm GitHub organization was "sunset" in mid-2025 after years of inactivity. - There is still no official way to import WebAssembly modules from JavaScript in a cross-platform manner, in the year of our lord 2026. If you're deploying to the browser and using Vite or raw ES modules, you can use `WebAssembly.instantiateStreaming(fetch(new URL('./foo.wasm', import.meta.url)))` and eat the top-level await. Vite recognizes the `new URL('...', import.meta.url)` pattern and will include the asset in the build output, but most other bundlers (e.g. Rollup and esbuild) do not. If you're on Node, you can't do this, because `fetch` does not work for local files. Most people just give up and embed the WebAssembly binary as a huge Base64 string, which increases the filesize by 33% and greatly reduces the compression ratio. - If you want multithreaded WebAssembly, you need to set the COOP/COEP headers in order to gain access to `SharedArrayBuffer`. GitHub Pages still doesn't let you do this, although it's the third-most-upvoted feature request. There's a janky workaround that installs a service worker. All bets are off on how that workaround interacts with PWAs. If the tooling situation had advanced past "tech demo" in the past 8 years since WebAssembly first shipped, a lot more people would be using it.
• dfabulich 9mo ago
  > Many seem to think there is a path to Wasm replacing JavaScript within the browser—that they might not need to include a .js file at all. This is very unlikely. This article didn't even seriously entertain replacing JavaScript as an idea, saying nothing about why it's "very unlikely." But it's the #1 thing most devs are excited about in WASM: maybe they could ditch JS and use another language instead for browser UI, at least Rust, but maybe Go or even Python. The reason that's unlikely is that browser UI is defined in standards as a JavaScript API; restandardizing an ABI for low-level languages would take years (perhaps decades). https://danfabulich.medium.com/webassembly-wont-get-direct-dom-support-any-time-soon-a3e0ea04c688 https://danfabulich.medium.com/webassembly-wont-get-direct-d...
• syrusakbary 9mo ago
  Great analysis. I'm Syrus, from Wasmer, and I've been working on WebAssembly professionally for the last 7 years (we are, in fact, the first Wasm-first company!)... hopefully my point of view would be useful to read! Why things are not as heated? Simply, because many of the big players are no longer doing the big bets on the technology, nor they are spending any marketing on making it successful. Mainly because most of their bets have been unsuccessful: WASI, Component Model. Many of the small players that raised money on the space either died or ended being acqui-hired by bigger players. The only ones that survive is the ones that truly understand is that tech doesn't matter a thing, is the product (what are you enabling with WebAssembly). In my view, this happens because there's a great mismatch between technical capabilities and the go-to-market skills that bringing the tech to the masses requires. The developers that tend to be technically great and understand the value of WebAssembly, are usually not as good on Go To Market to make it successful. For example, WASI proponents wanted to completely break the POSIX model (because in their view, is completely wrong... and they are partially right!). But they don't only want Wasm to succeed... they also want their mental model of new Operating System calls to go along with it (thus, you tie the success of one, to the success of another). AI only amplifies the Go To Market skills even further, by accelerating tech even more. When your MOAT is fully built around the tech but there's nothing that sustains it (a product), then you have an issue. The market is what sustains it, nothing else. People in the ecosystem cared way more about politics (creating a working group to control other companies), than they cared about creating something that many people could use tomorrow. At Wasmer, it took us a bit of time to understand this, but overtime we have been able to improve our skills to continuing capturing value from it. So, it's possible to create something successful with WebAssembly. You just need to make something people want (tl;dr: is not the tech!)
  • adrian17 9mo ago
    > Mainly because most of their bets have been unsuccessful: WASI, Component Model. Can you expand on that? I've only been using wasm for web (and the current status quo of JS bindings to the DOM is working just fine for me) so I haven't been following that strongly, but for the last couple months I was under impression that people are still trying to push WASI.
• fxj 9mo ago
  WebAssembly in the browser does feel great when you look at things like Pyodide/Pyolite, JupyterLite, xeus, webR and even small tools like texlyre – you get a full language/runtime locally with zero server, just WASM and some JS glue. The sad part is that VS Code for the Web never really became that kind of self-contained WASM IDE: the WASI story is focused on extensions and special cases, and running real toolchains (Emscripten, full Python, etc.) keeps breaking or depending on opaque backend magic. So right now the best “pure browser” experiences are these focused notebook/tool stacks, not the general-purpose web IDE people were hoping vscode.dev would become.
• liampulles 9mo ago
  At the last few places I've worked, we've seen most users engaging with our mobile app, and so it has made sense to develop a mobile app with flutter or kotlin multiplatform (or similar) for our broad userbase and then to use good ol' backed templated HTML for administrative sites rather than an SPA. Doing backend templating with good ol forms and what not is still a pretty good way to develop normal, boring websites.
• winternewt 9mo ago
  The use case I always envisioned from the sidelines was that I could ditch a poorly designed, garbage-collected mess of a language (JavaScript) for something typesafe, with predictable performance, cache locality by default (as in not making everything a reference), no GC, generics, etc. But WASM won't be there until it has first-class access to the DOM, in my opinion.
• koito17 9mo ago
  To add to the author's list of examples, the regex test site Regex 101 (http://regex101.com/ http://regex101.com/) relies on WebAssembly. To verify this in Firefox, you can set javascript.options.wasm to false, and you will be instructed to use a browser supporting WebAssembly. If you're willing to risk some safety guarantees, then you can embed SQLite in Go without cgo by using WASM builds of SQLite. In particular, this package: https://github.com/ncruces/go-sqlite3 https://github.com/ncruces/go-sqlite3 Note: the risk here is that it's unclear how well-tested SQLite WASM builds are compared to native builds for things like data integrity. With that said, in most of my personal projects using Go, I frequently reach for the WASM builds because it keeps builds fast and easy. Also, I want to mention that I have seen web apps that are C# / Blazor programs compiled into WebAssembly. The accessibility is predictably terrible, but I have seen at least one such web app in the wild. I assume this is largely why one doesn't encounter WASM web frameworks often. In any case, WASM is surprisingly useful in many niches, and that's kind of the problem for WASM's visibility: the niches where I find WASM useful are almost completely disjoint from each other. But it's a solid technology nowadays. The only real gripe I have is the fact that only wasmtime seems to fully support wasm32-wasip2. You can actually compile quite a lot of Rust backend stuff into WASM and run that instead of a container. Not that this is particularly useful, but I've found it interesting as an exercise.
• herobird 9mo ago
  > There is a lot of desire for advancement, but standardization means decisions are hard to reverse. For many, things are moving too quickly and in the wrong direction. Most Wasm proposals are very elegantly designed and effective - meaning they provide lots of value for relatively minor specification bloat. Examples are tail-calls, multi-value, custom-page-sizes, memory64 and even gc. However, the simd and flexible-simd increased spec bloat by a lot, are not future-proof and caused more fragmentation due to non-determinism. In my opinion work should have focused on flexible-vector (SVE-like) which was more aligned to Wasm's original goals of near-native performance. The reason for this development was that simd was simpler to implement and thus users could reap benefits earlier. Unfortunately, it seems the existence of simd completely stalled development of the superior flexible-vectors proposal. If flexible-vectors (or similar) will ever be stabilized eventually, we will end up in one of two (bad) scenarios: 1) People will have to decide between simd and flexible-vectors for their compilation, depending on their target hardware which is totally against Wasm's original goals. 2) The simd proposal will be mostly unused and deprecated. Dead weight.
  • whizzter 9mo ago
    From what viewpoint do you view them? simd128 fills a common need(most games using vector operations) and was a viable option with _broad hardware support_, yes, it adds a ton of instructions and impacts a ton of places with regards to memory ops but vec4 operations commonly use much of those instructions. Better useful than something that will never have a chance of standardization. On the other spectrum, things like custom-page-sizes seems like a simple flexible solution but smells like an implementation nightmare if you already have a runtime since that really impacts things on a far deeper level (64k pages was probably a mistake, but reading up on the issues of emulating x86 with 4k vs 16k pages on Mac's kinda hints at how devious "small" things like that is), i'm not surprised if it never comes about as an offical part (only 3 runtimes supporting it so far). I can understand the need for tail-calls but at the same time it's also an annoying can of worms to implement into compilers that wasn't prepared (could have been a large part of why it took so long for Safari to support). wasm-gc really hit a real-world need (bindings did really suck.. they're better but not perfect now) but also comes in a bit half-assed in some respects (languages like C# needing workarounds to use it), same with memory64 being a real-world need. I can see different camps (popular/functional languages for gc,m-val and tail-calls), games (simd128, multithreading, memory64), embedded(flexible pages),etc all competing and having focus on what they want but all camps also need to understand that pushing _everything_ will be pushing the risks of the web (security) and in the end that's what wasm was for, providing a runtime to run non-JS code on the web.
• TN1ck 9mo ago
  > Figma runs untrusted user plugins in your browser by running them in a QuickJS engine that is compiled to Wasm. According to the linked blog article, this is not what they are doing, but rather an option they explored. They use JavaScript Realm shims to isolate the execution.
  • qouteall 9mo ago
    They originally used JS realm polyfill, which is not real JS realm. The polyfill has some security holes. Now they switched to Js interpreter in Wasm. https://www.figma.com/blog/an-update-on-plugin-security/ https://www.figma.com/blog/an-update-on-plugin-security/
    • TN1ck 9mo ago
      Thanks!
• qouteall 9mo ago
  I've written about limitations of WebAssembly https://qouteall.fun/qouteall-blog/2025/WebAsembly%20Limitations https://qouteall.fun/qouteall-blog/2025/WebAsembly%20Limitat... WebAssembly still doesn't provide a way to release memory back to browser (unless using Wasm GC). The linear memory can only grow. The Wasm GC limits memory layout and doesn't yet support multi-threading. Wasm multithreading has many limitations. Such as cannot block on main thread, cannot share function table, etc. And web worker has "impedance mismatch" between native threads. And tooling is also immature (debugging requires print debugging)
  • turnsout 9mo ago
    Honestly lack of true multithreading (without the Web Worker hack) is the biggest downside for me. Every major project I work on needs the concept of a main thread for UI and a separate thread for processing.
• neomantra 9mo ago
  November 2025 was when AntiGravity and Gemini 3 came out and everything changed for me. Six months earlier, I had tried to vibe-code the 21+ verification page to AgentDank (an OSS cannabis MCP server connecting LLMs to open data via DuckDB SQL). After hours, I couldn't get a page fully working. I tried it with AG+G3, I prompted both the age 21+ screen AND the chat interface. It one-shotted a working version of both in less than a minute. I was immediately free to start exploring my idea! Adding multiple personality Budtenders, a Stash box for frequent item; it would create mocks and tests. So liberating. Then I had this other idea in my head for a while, that since DuckDB is broadly portable and can target WASM, I could play with the datasets in the browser and much of the app doesn't need an MCP-connected LLM or any backend services. next up, there is another mode where we will browse and visualize the cannabinoid contents. the dataset will be the data here https://github.com/AgentDank/dank-data we will use apache echarts for visualizations. we can probably embed duckdb in the browser and do it all the queries there. we can have some simple UI for exploring, as well as raw SQL query And it one-shotted an entire DBA application interface with a custom UI and visualization to explore the data. Then I asked for some 3D WebGL charts with echarts and we got that working too. So WASM is gonna be as important as ever because we have tons of software which can be compiled to WASM, Web is the UX meeting point, and LLMs can help bring it all together.
• childintime 9mo ago
  There is an intriguing alternative to WASM for many use cases: a RISC-V VM.
• Ono-Sendai 9mo ago
  I use webassembly for Substrata (https://substrata.info/ https://substrata.info/). It works pretty well, allows building a c++ app using OpenGL for the web.
• deleted 9mo ago
  [deleted]
• jokethrowaway 9mo ago
  As someone who's going to write frontend in Leptos in the next 2 weeks, what stops me from recommending wasm for every frontend application is the bundle size. I don't want to ship compiled megabytes to the user to render UI. If there was a rust frontend framework that compiles to JS, I'd use it for all my frontend code.
• gaanbal 9mo ago
  happened? past tense? it's still being worked on. expect massive things in the near future.
• subset 9mo ago
  I recently wrote an eigenvalue solver for an interactive component on my blog with Rust compiled to WebAssembly. Being able to write-once and compile for the web and desktop felt like the future. But then, I'm no fan of JavaScript and wouldn't have attempted it if WASM didn't exist.
  • Avamander 9mo ago
    I've just recently done the same, turned Rust into WASM and it does feel great. Being able to compile mature and well-tested libraries into WASM instead of trying to find a JS equivalent is incredible value.
• Yizahi 9mo ago
  This article misses one important point. Maybe even the most important. WebAssembly didn't get traction because of theft. Making a game or professional software in it essentially equals to publishing full source and assets online, ripe for taking by any unscrupulous party. SAAS may endure that, but games will not. And that's why we can't have nice things.
  • bigfishrunning 9mo ago
    > Making a game or professional software in it essentially equals to publishing full source and assets online, ripe for taking by any unscrupulous party. How is this true? seems to me that webassembly looks kind of equivalent to the output you'd get from an x86 disassembler for an x86 native program -- sure it's editable, but it's certainly not equivalent to the original source used to produce it. To put it another way -- Webassembly encourages theft exactly as much as any other kind of DRM-free publishing; and you can add anti-piracy measures to it in the same way you can with other software.
• zcw100 9mo ago
  I'm usually pretty good at explaining new technologies to people but WebAssembly has got to be the most difficult to try and explain. The sheer number of misunderstandings about it is amazing. Luckily the misunderstandings serve my purpose for right now so I'm glad to see all the noise.
• classified 9mo ago
  AI has eaten so much attention that actually good ideas are being forgotten or overlooked.
• singularity2001 9mo ago
  The biggest blunder was not adding UTF-8 strings as a first class citizen The second blunder was not allowing for any direct memory mapping I know it's against the security system but if you have to copy every pixel one by one to the host then that won't be effective The third blunder was when they finally added GC objects to not make any of the objects properties readable from the host
• misiek08 9mo ago
  For me the biggest issue is all the articles and videos showing how people run entire companies in WASM and then sample code with fn(i32, i32) i32. The interoperability between languages and pre-defined APIs like WASI are just not there yet and its just rough to use. Of course crazy things can be (were already!) done with WASM, but it's more like Rust in the beginning and is still advertised as Go ;)
• mickael-kerjean 9mo ago
  I use WASM extensively in my OSS work with Filestash (https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/filestash ) in 3 main areas: 1. to create web versions of applications that are traditionally desktop only to render things like Parquet, PSD, TIFF, SQLite, EPS, ZIP, TGZ, and many more, where C libraries are often the reference implementations. There are almost a hundred supported file formats, most of which are supported through WASM: https://github.com/mickael-kerjean/filestash?tab=readme-ov-file#roadmap https://github.com/mickael-kerjean/filestash?tab=readme-ov-f... 2. to create plugins that extend the core application. As of today, you can add your own endpoint or middleware in Filestash, package it with its own manifest, and run server-side code in a constrained environment. For example, there is a libreoffice wasm edition that can run from your browser but requires a couple HTTP headers to be sent by the server to work so the plugin has this bit that run server side to add those HTTP headers: https://github.com/mickael-kerjean/filestash/blob/master/server/plugin/plg_application_office/middleware.c https://github.com/mickael-kerjean/filestash/blob/master/ser... 3. in the workflow engine to enable people to run their own code in actions while ensuring they can't fuck everything up
• radarsat1 9mo ago
  Something I wonder is, what happened to asm.js? It got killed by WASM. In a way this is good, WASM is a "better" solution, being a formal bytecode machine description, but on the other hand, asm.js would not have the same limitations e.g. with respect to DOM interaction, or debates on how to integrate garbage collection, since you stay squarely in the JS VM you get these things for free. Basically in some ways it was a superior idea: benefit from the optimizations we are already doing for JS, but define a subset that is a good compilation target and for which we know the JS VM already performs pretty optimally. So apart from defining the subset there is no extra work to do. On the other hand I'm sure there are JS limitations that you inherit. And probably your "binaries" are a bit larger than WASM. (But, I would guess, highly compressible.) I guess the good news is that you can still use this approach. Just that no one does, because WASM stole the thunder. Again, not sure if this is a good or bad thing, but interesting to think about... for instance, whether we could have gotten to the current state much faster by just fully adopting asm.js instead of diverting resources into a new runtime.
  • pjmlp 9mo ago
    Which only existed because Mozzilla was against adopting PNaCL.
• zb3 9mo ago
  WebAssembly sucks with regard to emulation speed, it doesn't even support native JIT. If you disagree, go and make a QEMU port where TempleOS doesn't take 5+ minutes to load. WebKVM is what we need..
  • butterisgood 9mo ago
    Was that not basically in the same vein as Google's NaCL? Was that not largely abandoned due to the success of WASM. lol?
• adamdecaf 9mo ago
  Compilation target support from Go and other languages makes it really easy to provide your library to websites - which we use for demos. It's quick to compile Go code into WASM and show folks quickly what your library offers. Plus the demo's computation happens client side so no data is sent to a server. We can offer our full payment parsing libraries to the web as developer tools without any code changes. I don't have to care about the details of WASM because it "just works". https://moov-io.github.io/ach/webui/ https://moov-io.github.io/ach/webui/
• hollowturtle 9mo ago
  I just wish wasm had some kind of api for drawing on a canvas, managing pointer/touch events and provide some accessibility apis. That's all I wanted and I believe also need for ditching altogether dom and other horrendous apis and start making real native like apps in the browser
• guluarte 9mo ago
  Most managers don't care about performance
• dboreham 9mo ago
  I think it's more productive to analyze the adoption (or not) of a technology from the perspective of it being a cult, rather than with strict technical factors. A cult grows as an emergent phenomenon where the conditions on the ground create incentives for new members to join faster than old ones leave. Through this lens there are actually two cults with two cult rallying cries: 1. The browser is, arguably, a terrible program execution environment. You have to use a stupid language and there's a ton of pretty standard things you can't do (e.g. have proper concurrency). Let's fix that by baking a proper program execution environment into the browser. 2. There are lots of places where someone builds an application (a real application that runs as a process on an OS) that then needs to support some sort of embedded programmability. Historically there have been many ways to do this: embed Lua, embed a Python interpreter, embed a JS interpreter, write the application in a language that inherently supports runtime dynamic binding (Java, Lisp, ...). Let's make a better version of that thing such that it supports all common languages. My take is that while WASM was developed by people in the #1 cult, it has actually been adopted by people in the #2 cult. I see WASM used all over the place as a way to host user-provided code inside things. Blockchain nodes are a common use case, for example. Then there's a third use case that I think motivates many of the comments here which is: back in the day we could make an application and distribute it to users who would run it on their computers. That pretty much isn't possible now for various reasons, but primarily because computers are locked down (particularly mobile). If only we could be allowed to run regular code inside the one execution environment that's not locked down (the browser), imagine what we could do then. Problem is that WASM doesn't have all the features necessary for this use case. Experience in the past with similar things (ActiveX, Java, ...) suggests that if it did, it would also become locked down.
• guntis_dev 9mo ago
  I've worked with WebAssembly on several real world use cases Codec support: Built video and audio decoding in Wasm to bring codec support to browsers that didn't have it natively. Also helped with a custom video player to work around HLS latency issues on Safari. Code sharing: We had business logic written in C that needed to run both frontend and backend. Compiled it to Wasm for the frontend, which guaranteed identical behaviour across environments. Obfuscation: Currently exploring Wasm for "hiding" some JavaScript logic by rewriting critical parts in Rust and compiling to Wasm. We tried JS obfuscators (including paid ones), but they killed performance. Wasm gives us both obfuscation and better performance.
  • austin-cheney 9mo ago
    To hide parts of JavaScript my best recommendation is to just not send the undesirable JavaScript to the browser in the first place. There are performance and security improvements to that which would be lost when trying to remove this same code after it does arrive to the browser. That modification could be as simple as opening the concerned code file in your back end application as a large string and slicing out the parts you don't want. This will likely require some refactoring of the JavaScript code first to ensure the parts you wish to remove are islands whose absence won't break other things.
    • guntis_dev 9mo ago
      Without revealing too much, the business logic must remain client side for this use case, and it's a common problem across our industry. I've explained the security reality to the business many times - any JavaScript sent to the client can be read, executed, proxied, or tampered with. That's just how browsers work. The current directive is - make it as difficult to understand as reasonably possible. We're not trying to stop determined adversaries (that's impossible), but we can raise the bar high enough to deter script kiddies and casual attackers from easily abusing it.
  • socalgal2 9mo ago
    are any of those codecs open source? A idea for a side project is browser based VLC (play any format). More ideally, a library that lets you play any old format in the browser.
• perryizgr8 9mo ago
  > Separately, I think the community is not helped by the philosophy of purposely obfuscating teaching material around Wasm What does the author mean by this?
  • azakai 9mo ago
    Yes, that puzzles me too. Not only do I not know what the author means, I'm not sure what it could mean: teaching material for wasm is generated by many independent people, each for their own tools and purposes. There is no organization behind all that, much less a philosophy.
• Tepix 9mo ago
  Here is a minimal example for inline webassembly: A function a that adds two numbers. Can someone make the entire example shorter? (added linebreaks for readability) <!DOCTYPE html> <p id=r> <script> WebAssembly.instantiateStreaming(fetch( 'data:application/wasm;base64,AGFzbQEAAAABBwFgAn9/AX8DAgEABwUBAWEAAAoJAQcAIAAgAWoL')) .then(x=>r.append(x.instance.exports.a(51,4))) </script> And here is the wat code that we can turn into wasm with wat2wasm and then into base64 for a data URL: (module (func (export "a") (param i32 i32) (result i32) local.get 0 local.get 1 i32.add))
  • Tepix 9mo ago
    Found a shorter version, again with linebreaks for readability: <p id=r> <script>WebAssembly.instantiate(Uint8Array.fromBase64( 'AGFzbQEAAAABBwFgAn9/AX8DAgEABwUBAWEAAAoJAQcAIAAgAWoL')) .then(x=>r.append(x.instance.exports.a(51,4))) </script>
• socalgal2 9mo ago
  To more examples of web assembly Photoshop Online: https://www.adobe.com/products/photoshop/online.html https://www.adobe.com/products/photoshop/online.html And just announced Unity Online: https://youtu.be/xJONoHr1N6A?t=1717 https://youtu.be/xJONoHr1N6A?t=1717
• hexo 9mo ago
  Nothing, it is still disabled on all my devices as it always was and will be.
• leros 9mo ago
  I've used WebAssembly for complex cross platform SDKs. I write the core SDK once in WebAssembly and then wrap it with an API layer for each SDK. It sure beats updating and testing complex logic for 30 different SDKs.