HN

Comments (312)

• Menu

  jjcm
  I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.
• Menu

  j0e1
  > Garbage collection. In addition to expanding the capabilities of raw linear memories, Wasm also adds support for a new (and separate) form of storage that is automatically managed by the Wasm runtime via a garbage collector. Staying true to the spirit of Wasm as a low-level language, Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of struct and array types, plus unboxed tagged integers, whose allocation and lifetime is then handled by Wasm. But that’s it.Wow!
• Menu

  cedws
  When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?
• Menu

  re
  I haven't really been following WASM development in the last year and didn't realize that WASM had moved to a versioned release model. I've been aware of the various features in development[1] and had thought many of the newer features were going to remain optional but I guess now that implementations are expected to support all the features to be able to claim compatibility with e.g. "WASM 3.0"?It'll be interesting to see what the second non-browser-based WASM runtime to fully support 3.0 will be (I'm guessing wasmtime will be first; I'm not counting Deno since it builds on v8). Garbage collection seems like a pretty tricky feature in particular.Does anyone know how this 3.0 release fits into the previously announced "evergreen" release model?[2]> With the advent of 2.0, the Working Group is switching to a so-called “evergreen” model for future releases. That means that the Candidate Recommendation will be updated in place when we create new versions of the language, without ever technically moving it to the final Recommendation state. For all intents and purposes, the latest Candidate Recommendation Draft[3] is considered to be the current standard, representing the consensus of the Community Group and Working Group.[1] https://webassembly.org/features/[2] https://webassembly.org/news/2025-03-20-wasm-2.0/[3] https://www.w3.org/TR/wasm-core-2/
• Menu

  bborud
  I'm a simple man who has simple needs. I want a better and faster way to pass Go structs in and out of the runtime that doesn't mean I have to do a sword dance on a parquet floor wearing thick knit wool socks and use some fragile grafted on solution.If there can be a solution that works for more languages: great. I mostly want this for Go. If it means there will be some _reasonable_ limitations, that's also fine.
• Menu

  alabhyajindal
  The WebAssembly community should really focus more the developer experience of using it. I recently completed a project where I wrote a compiler¹ targeting it and found the experience to be rather frustrating.Given that Wasm is designed with formal semantics in mind, why is the DX of using it as a target so bad? I used binaryen.js to emit Wasm in my compiler and didn't get a feeling that I am targeting a well designed instruction set. Maybe this is a criticism of Binaryen and its poor documentation because I liked writing short snippets of Wasm text very much.1. https://git.sr.ht/~alabhyajindal/jasmine
• Menu

  phkahler
  Still looking forward to when they support OpenMP. We have an experimental Solvespace web build which could benefit quite a bit from that.https://cad.apps.dgramop.xyz/Open source CAD in the browser.
• pveierland
  The SpecTec mentioned in the announcement is really cool. They're using a single source of truth to derive LaTeX, Sphinx docs, Coq definitions for proofs, and an AST schema. Building the language spec in a way that its soundness can be proven and everything derived from one truth in this way seems super useful.https://webassembly.org/news/2025-03-27-spectec/
• Menu

  flohofwoe
  Since it hasn't been mentioned here yet: I wonder if the multiple-memories feature will somehow allow to avoid the extra copy that's currently needed when mapping a WebGPU resource. This mapping is available in a separate ArrayBuffer object which isn't accessible from WASM without calling into JS and then copying from the ArrayBuffer into the WASM heap and back.Multiple WASM memories and Clang's/LLVM's address space feature sound like they should be able to solve that problem, but I'm not sure if it is as trivial as it sounds...
• mistahchris
  I'm still hype about WASM. This looks like a cool release. I'm running some pretty high traffic WASM plugins on envoy, running some plugins for terminal apps (zellij), and for one of my toy side projects, I'm running a wasm web app (rust leptos).For 2 of those 3 use cases, i think it's not technically the optimal choice, but i think that future may actually come. Congratulations and nice work to everyone involved!
• Menu

  preommr
  On gc:> Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of struct and array types, plus unboxed tagged integers, whose allocation and lifetime is then handled by Wasm.There's already a lot misunderstandings about wasm, and I fear that people will just go "It supports GC, so we can just export python/java/c#/go etc."This is not a silver bullet. Cpp, or rust are probably still going to be the way to go.Relying on the GC features of WASM will require writing code centered around the abstractions for the compiler that generates WASM.
• Menu

  modeless
  Is there a technical reason for the web limit to be 16 GB specifically? Or is it just a round number picked so that the limit could be standardized? Also, has the limit on JS heap size (and ArrayBuffer size) also been relaxed to 16 GB or is it still lower?
• Menu

  boricj
  Does WASM still have 64 KiB pages? I get why for desktops, but there are use-cases for running WASM on microcontrollers where that's either inconvenient or outright impossible.The one in particular I have in mind would be to put WASM on graphical calculators, in order to have a more secure alternative to the ASM programs (it's possible nowadays to write in higher-level languages, but the term stuck) that could work across manufacturers. Mid-range has RAM on the order of 256 KiB, but a 32-bit core clocked at more than 200 MHz, so there's plenty of CPU throughput but not a lot of memory to work with.Sadly, the closest thing there is for that is MicroPython. It's good for what it does, but its performance and capabilities are nowhere near native.
• exabrial
  My dream is we get pluggable execution runtimes (wasm, jvm, , LLVM IR?) with pluggable display tech (svg, html, opengl) and each tech JITs itself on your platform.While we do need a default “text mode” (html), js is not the answer to a common language and is holding everything back.
• spankalee
  I really hope this spurs AssemblyScript to just port to WASM GC: https://github.com/AssemblyScript/assemblyscript/issues/2808There's comments in there about waiting for a polyfill, but GC support is widespread enough that they should probably just drop support for non-GC runtimes in a major version.
• Menu

  hinkley
  Still no mention of DOM.<sets alarm for three years from now>See you all for WASM 4.0.
• Menu

  jasonthorsness
  I don't think the GC in this version has the features required to enable a C# runtime on top of it yet: https://github.com/WebAssembly/gc/issues/77I wonder what language this GC can actually be used for at this stage?
• jadenPete
  Support for garbage collection is really nice to see. Previously, it’s been very difficult to do garbage collection in WASM because you don’t have direct access to the stack, so traditional approaches like stack scanning haven’t been feasible.
• Menu

  pbiswal
  Is the component model work (https://component-model.bytecodealliance.org/) related to the 3.0 release in any way?
• Menu

  steveklabnik
  This looks like a great release! Lots of stuff people have wanted for a long time in here.
• Menu

  jsheard
  Has anyone benchmarked 64bit memory on the current implementations? There's the potential for performance regressions there because they could exploit the larger address space of 64bit hosts to completely elide bounds checks when running 32bit WASM code, but that doesn't work if the WASM address space is also 64bit.
• nirui
  > 64-bit address space. Memories and tables can now be declared to use i64 as their address type instead of just i32.Could be nitpicking but in the PDF (https://webassembly.github.io/spec/core/_download/WebAssembl...), there's a passage that says:> 32-bit integers also serve as Booleans and as memory addresses. (under 1.2.1 Concepts)While 64-bit is not mentioned. Could it be an oversight or I understood it wrong?
• endorphine
  Kinda off-topic but do you see any value in a (rust) library that does only the binary decoding part + validation?
• nairboon
  What cool new features could this enable in Pyodide?
• hinkley
  One bright point here is that the WASM changes may force v8 to improve its IPC by having a feature that Bun gets from JSC, which is passing strings across isolate boundaries.IPC overhead is so bad in NodeJS that most people don’t talk about it because the workarounds are just impossibly high maintenance. We reach straight for RPC instead, and downplay the stupidity of the entire situation. Kind of reminiscent of the Ruby community, which is perhaps not surprising given the pedigree of so many important node modules (written by ex Rails devs).
• DeathArrow
  Do WASM apps have now direct access to DOM?
• denis_dolya
  Wasm 3.0 looks like a significant step forward. The addition of 64-bit address space and improved reference typing really expands the platform’s capabilities. Integration with WASI makes access to system resources more predictable, but asynchronous operations and JS interop remain key pain points. Overall, this release makes Wasm more viable not just in the browser, but also for server-side and embedded use cases.
• roschdal
  What do we need it for?
• Menu

  endorphine
  Oh no, right after I started writing a binary decoder for 2.0. Does anybody know how much this changes things as far as a decoder is concerned?
• oaiey
  This looks like a huge release for C# and Java I guess. Half of the features are useful elements they no longer have to polyfill.
• __grob
  This is so exciting! Been waiting for this for years, very interested to see what people can do with this
• unaut
  64-bit addr space and deterministic profiles ftw!Really nice new set of features.
• anon
  undefined
• Menu

  aag
  Does anyone know whether the exception handling implementation supports restartable exceptions like Common Lisp's and Scheme's?
• jamesu
  Having wasm 3.0 and a project named wasm3 which doesn't seem to support wasm 3.0 is sure going to get confusing!
• k__
  Can QuickJS run in WASM3.0 with deterministic profile?That would be pretty rad!
• alphazard
  Doesn't look like they took anything out.
• Menu

  mattlondon
  But looks like you still cannot open a raw TCP or UDP socket? Who needs this internet network thing huh?I appreciate it is a potential security hole, but at least make it behind a flag or something so it can be turned on.
• moralestapia
  Great work. WASM will eat the world :D.
• anon
  undefined
• Dabbling_Dion
  [dead]
• unit149
  [dead]
• Menu

  WhereIsTheTruth
  > GC and Exception handlingThis was not necessary.. what a mistake, specially EH..
• Menu

  diego_moita
  There's a joke in Brazil saying "Brazil is the country of the future and will always be that. It will never be the country of the present".WASM is and will always be the greatest technology of the future. It will never be the greatest technology of the present.
• Menu

  quix0t3
  steve job's ghost will prevent wasm adoption.