{"slug": "webassembly", "name": "WebAssembly", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "", "recommenders": 16, "commenters": 25, "warners": 6, "score": 8.23, "rising": -5.24, "first": "2025-11-11", "latest": "2026-09-12", "why": "Wasm's guarantees are incredibly strong and formally proved", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 16, "neutral": 1, "compare": 4, "warn": 6}, "spark": [0, 0, 8, 0, 5, 1, 2, 0, 0, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "Wasm's guarantees are incredibly strong and formally proved", "kind": "", "icon": true, "domain": null, "github_repo": null, "official_url": "https://webassembly.org", "pricing": "", "aliases": ["WebAssembly"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 773237537, "item_id": 48327346, "url": "https://news.ycombinator.com/item?id=48327346", "by": "sitkack", "date": "2026-05-29", "version": null, "stance": "recommend", "quote": "I'd love to see CHERI (for the room) and Wasm take off", "excerpt": "I'd love to see CHERI (for the room) and Wasm take off, no time like the present. https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_RISC_Instructions https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/", "context": "", "use_case": "", "switched_from": "", "story": "CVE-2026-28952: Apple macOS 26.5 Kernel Vuln found by Claude"}, {"id": 761773842, "item_id": 47610865, "url": "https://news.ycombinator.com/item?id=47610865", "by": "InkCanon", "date": "2026-04-01", "version": null, "stance": "recommend", "quote": "Wasm's guarantees are incredibly strong and formally proved", "excerpt": "Yes, and it's a very interesting use case for Wasm. Firefox has a sandbox called RLbox built on this, and has been published in a few papers. Performance is one benefit, but the real killer feature is Wasm's guarantees are incredibly strong and formally proved. So by definition, you won't get out of bounds memory reads, memory corruption etc, assuming the implementation is correct. And because of the thorough specifi", "context": "", "use_case": "sandboxing native code", "switched_from": "", "story": "Ask HN: Can WASM be used as a means of sanitizing native code?"}, {"id": 758094784, "item_id": 47380924, "url": "https://news.ycombinator.com/item?id=47380924", "by": "lioeters", "date": "2026-03-14", "version": null, "stance": "recommend", "quote": "Its technical design is a solid foundation, a lot of good thought went into it", "excerpt": "I've been learning to use WebAssembly directly, by hand-writing the Lisp-like assembly text, and also compiling C to Wasm without Emscripten or LLVM. It's given me a deeper appreciation for the original specification, version 1. Its technical design is a solid foundation, a lot of good thought went into it: Briging the Web Up to Speed With WebAssembly - https://github.com/WebAssembly/spec/raw/refs/tags/wg-1.0/papers/", "context": "", "use_case": "Learning hand-written wasm modules", "switched_from": "", "story": "Nominal Types in WebAssembly"}, {"id": 758053072, "item_id": 47378317, "url": "https://news.ycombinator.com/item?id=47378317", "by": "flohofwoe", "date": "2026-03-14", "version": null, "stance": "recommend", "quote": "WASM code pretty much runs at native speed these days", "excerpt": "> It's not fast. My emulators here have roughly the same performance as the same code compiled as native executable (e.g. within around 5%) - this is mostly integer bit twiddling code. Unless you hand-optimize your code beyond what portable C provides (like manually tuned SIMD intrinsics), WASM code pretty much runs at native speed these days: https://floooh.github.io/tiny8bit/", "context": "", "use_case": "", "switched_from": "", "story": "Nominal Types in WebAssembly"}, {"id": 758052384, "item_id": 47378274, "url": "https://news.ycombinator.com/item?id=47378274", "by": "zffr", "date": "2026-03-14", "version": null, "stance": "recommend", "quote": "using WASM can minimize cold startup time for serverless functions", "excerpt": "> It's not fast. Not disagreeing with you, but here\u2019s an article from Akamai about how using WASM can minimize cold startup time for serverless functions. https://www.akamai.com/blog/developers/build-serverless-functions-zero-cold-starts-webassembly-spin", "context": "", "use_case": "serverless cold-start reduction", "switched_from": "", "story": "Nominal Types in WebAssembly"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 794771200, "item_id": 49673200, "url": "https://news.ycombinator.com/item?id=49673200", "by": "rvz", "date": "2026-09-12", "version": null, "stance": "warn", "quote": "It is mostly a solution looking for a problem", "excerpt": "I agree. It is mostly a solution looking for a problem and has close to the same functional downsides as Flash or Applets other than \"transparency\". Its 'sandbox' is also escapeable at both the engine level in V8, Gecko and JavaScriptCore (All in C/C++) and at the implementation level; especially if the software was converted from C to WASM. So it is not the silver bullet people think it is. [0] https://nvd.nist.gov/", "context": "", "use_case": "", "switched_from": "", "story": "Performance of WebAssembly Runtimes in 2026"}, {"id": 787803888, "item_id": 49237743, "url": "https://news.ycombinator.com/item?id=49237743", "by": "wasmperson", "date": "2026-08-09", "version": null, "stance": "warn", "quote": "The WASM GC standards team was warned in advance that the proposal wouldn't work for .NET, and they moved forward with it anyway", "excerpt": "> Then C# came and said It's worse than that. The WASM GC standards team was warned in advance that the proposal wouldn't work for .NET, and they moved forward with it anyway: https://github.com/WebAssembly/gc/issues/77 They were also warned about Go (though I'm not sure if they ever actually consulted with golang devs): https://github.com/WebAssembly/gc/issues/36 More links: https://github.com/dotnet/runtime/issues/", "context": "", "use_case": "", "switched_from": "", "story": "Windows 11's built-in Weather app wastes more than 1 GB of RAM"}, {"id": 772521249, "item_id": 48282578, "url": "https://news.ycombinator.com/item?id=48282578", "by": "danudey", "date": "2026-05-26", "version": null, "stance": "warn", "quote": "WASM programs could theoretically just run forever in entirely reasonable cases", "excerpt": "eBPF has a lot more checks in the verifier, which you could read about here if you're interested in learning more: https://docs.kernel.org/bpf/verifier.html Since you don't want to handle any kind of crash, out of bounds exception, etc., the eBPF verifier does a ton of impressively paranoid stuff. It ensures that the program doesn't loop (or if it loops that the loop is provably bounded and cannot be infinite), it gu", "context": "", "use_case": "General-purpose runtime", "switched_from": "", "story": "Show HN: Write your BPF programs in Go, not C"}, {"id": 758552576, "item_id": 47409536, "url": "https://news.ycombinator.com/item?id=47409536", "by": "shevy-java", "date": "2026-03-17", "version": null, "stance": "warn", "quote": "nobody is really using it", "excerpt": "Everyone runs out of steam when it comes to WebAssembly. I used to wonder in the past why we hear so little about it, until I realised that nobody is really using it. Granted, there are those who use WebAssembly, but if we compare it to HTML, CSS, JavaScript, then WebAssembly is simply not existing anywhere near that level. After soon-to-be 10 years, that is very disappointing.", "context": "", "use_case": "", "switched_from": "", "story": "Pyodide: a Python distribution based on WebAssembly"}]}], "who": [], "tags": [], "use_cases": ["general-purpose runtime", "sandboxing native code", "learning hand-written wasm modules", "serverless cold-start reduction", "ml models in browser", "running c/c++ code in browsers"], "compared": [{"slug": "v8", "name": "V8", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "emscripten", "name": "Emscripten", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 757938768, "item_id": 47371173, "url": "https://news.ycombinator.com/item?id=47371173", "by": "bvisness", "date": "2026-03-13", "version": null, "stance": "neutral", "quote": "I am co-champion of a proposal to fix this", "excerpt": "The \u201csingle array of memory\u201d is not the problem; that\u2019s what all these languages already expect. The problem is the lack of meaningful memory APIs, e.g. virtual memory capabilities. I am co-champion of a proposal to fix this but have not been able to prioritize it for a while, unfortunately: https://github.com/WebAssembly/memory-control/blob/main/proposals/memory-control/Overview.md", "context": "", "use_case": "", "switched_from": "", "story": "Making WebAssembly a first-class language on the Web"}], "threads": [{"url": "https://news.ycombinator.com/item?id=46551044", "title": "What Happened to WebAssembly", "mentions": 4}, {"url": "https://news.ycombinator.com/item?id=48206340", "title": "Saying Goodbye to Asm.js", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=47320482", "title": "Nominal Types in WebAssembly", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=46629399", "title": "Increasing the performance of WebAssembly Text Format parser by 350%", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=47331811", "title": "Making WebAssembly a first-class language on the Web", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=47295837", "title": "Notes on Writing WASM", "mentions": 2}], "sentiment_by_month": {"2025-11": {"warn": 1}, "2025-12": {"compare": 1}, "2026-01": {"compare": 1, "recommend": 8}, "2026-02": {"neutral": 1, "warn": 1}, "2026-03": {"recommend": 5, "warn": 1}, "2026-04": {"recommend": 1}, "2026-05": {"compare": 2, "recommend": 2, "warn": 1}, "2026-06": {}, "2026-07": {}, "2026-08": {"warn": 1}, "2026-09": {"warn": 1}, "2026-10": {}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 794771200, "item_id": 49673200, "url": "https://news.ycombinator.com/item?id=49673200", "by": "rvz", "date": "2026-09-12", "version": null, "stance": "warn", "quote": "It is mostly a solution looking for a problem", "excerpt": "I agree. It is mostly a solution looking for a problem and has close to the same functional downsides as Flash or Applets other than \"transparency\". Its 'sandbox' is also escapeable at both the engine level in V8, Gecko and JavaScriptCore (All in C/C++) and at the implementation level; especially if the software was converted from C to WASM. So it is not the silver bullet people think it is. [0] https://nvd.nist.gov/", "context": "", "use_case": "", "switched_from": "", "story": "Performance of WebAssembly Runtimes in 2026"}, {"id": 787803888, "item_id": 49237743, "url": "https://news.ycombinator.com/item?id=49237743", "by": "wasmperson", "date": "2026-08-09", "version": null, "stance": "warn", "quote": "The WASM GC standards team was warned in advance that the proposal wouldn't work for .NET, and they moved forward with it anyway", "excerpt": "> Then C# came and said It's worse than that. The WASM GC standards team was warned in advance that the proposal wouldn't work for .NET, and they moved forward with it anyway: https://github.com/WebAssembly/gc/issues/77 They were also warned about Go (though I'm not sure if they ever actually consulted with golang devs): https://github.com/WebAssembly/gc/issues/36 More links: https://github.com/dotnet/runtime/issues/", "context": "", "use_case": "", "switched_from": "", "story": "Windows 11's built-in Weather app wastes more than 1 GB of RAM"}, {"id": 773237537, "item_id": 48327346, "url": "https://news.ycombinator.com/item?id=48327346", "by": "sitkack", "date": "2026-05-29", "version": null, "stance": "recommend", "quote": "I'd love to see CHERI (for the room) and Wasm take off", "excerpt": "I'd love to see CHERI (for the room) and Wasm take off, no time like the present. https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_RISC_Instructions https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/", "context": "", "use_case": "", "switched_from": "", "story": "CVE-2026-28952: Apple macOS 26.5 Kernel Vuln found by Claude"}, {"id": 772521249, "item_id": 48282578, "url": "https://news.ycombinator.com/item?id=48282578", "by": "danudey", "date": "2026-05-26", "version": null, "stance": "warn", "quote": "WASM programs could theoretically just run forever in entirely reasonable cases", "excerpt": "eBPF has a lot more checks in the verifier, which you could read about here if you're interested in learning more: https://docs.kernel.org/bpf/verifier.html Since you don't want to handle any kind of crash, out of bounds exception, etc., the eBPF verifier does a ton of impressively paranoid stuff. It ensures that the program doesn't loop (or if it loops that the loop is provably bounded and cannot be infinite), it gu", "context": "", "use_case": "General-purpose runtime", "switched_from": "", "story": "Show HN: Write your BPF programs in Go, not C"}, {"id": 771448275, "item_id": 48215517, "url": "https://news.ycombinator.com/item?id=48215517", "by": "ramses0", "date": "2026-05-20", "version": null, "stance": "recommend", "quote": "", "excerpt": "https://ssheasy.com/ https://www.google.com/search?q=wasm+ssh+client ...the future is here!", "context": "", "use_case": "", "switched_from": "", "story": "Saying Goodbye to Asm.js"}, {"id": 771348032, "item_id": 48209252, "url": "https://news.ycombinator.com/item?id=48209252", "by": "flohofwoe", "date": "2026-05-20", "version": null, "stance": "compare", "quote": "WASM was designed from the ground up as CPU agnostic bytecode", "excerpt": "There were 3 systems, all with interesting differences. The original NaCl was a 'validated subset' of native CPU machine code (e.g. actual x86 machine code with some instructions and instruction sequences disallowed which would allow to escape the sandbox). The next iteration was P(ortable)-NaCl which replaced the native machine code with a subset of LLVM bitcode, which was then compiled at load time. Unfortunately w", "context": "", "use_case": "", "switched_from": "", "story": "Saying Goodbye to Asm.js"}, {"id": 771336464, "item_id": 48208529, "url": "https://news.ycombinator.com/item?id=48208529", "by": "eqrion", "date": "2026-05-20", "version": null, "stance": "compare", "quote": "asmjs is going to be strictly more limited in interacting with JS than wasm", "excerpt": "> But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead asmjs is going to be strictly more limited in interacting with JS than wasm. You're basically limited to simple number values and array buffers. Whereas wasm now a days has GC types and can hold onto JS value using externref. > But more important for what i was trying to do, you can't zero copy ", "context": "", "use_case": "", "switched_from": "", "story": "Saying Goodbye to Asm.js"}, {"id": 761773842, "item_id": 47610865, "url": "https://news.ycombinator.com/item?id=47610865", "by": "InkCanon", "date": "2026-04-01", "version": null, "stance": "recommend", "quote": "Wasm's guarantees are incredibly strong and formally proved", "excerpt": "Yes, and it's a very interesting use case for Wasm. Firefox has a sandbox called RLbox built on this, and has been published in a few papers. Performance is one benefit, but the real killer feature is Wasm's guarantees are incredibly strong and formally proved. So by definition, you won't get out of bounds memory reads, memory corruption etc, assuming the implementation is correct. And because of the thorough specifi", "context": "", "use_case": "sandboxing native code", "switched_from": "", "story": "Ask HN: Can WASM be used as a means of sanitizing native code?"}, {"id": 758552576, "item_id": 47409536, "url": "https://news.ycombinator.com/item?id=47409536", "by": "shevy-java", "date": "2026-03-17", "version": null, "stance": "warn", "quote": "nobody is really using it", "excerpt": "Everyone runs out of steam when it comes to WebAssembly. I used to wonder in the past why we hear so little about it, until I realised that nobody is really using it. Granted, there are those who use WebAssembly, but if we compare it to HTML, CSS, JavaScript, then WebAssembly is simply not existing anywhere near that level. After soon-to-be 10 years, that is very disappointing.", "context": "", "use_case": "", "switched_from": "", "story": "Pyodide: a Python distribution based on WebAssembly"}, {"id": 758094784, "item_id": 47380924, "url": "https://news.ycombinator.com/item?id=47380924", "by": "lioeters", "date": "2026-03-14", "version": null, "stance": "recommend", "quote": "Its technical design is a solid foundation, a lot of good thought went into it", "excerpt": "I've been learning to use WebAssembly directly, by hand-writing the Lisp-like assembly text, and also compiling C to Wasm without Emscripten or LLVM. It's given me a deeper appreciation for the original specification, version 1. Its technical design is a solid foundation, a lot of good thought went into it: Briging the Web Up to Speed With WebAssembly - https://github.com/WebAssembly/spec/raw/refs/tags/wg-1.0/papers/", "context": "", "use_case": "Learning hand-written wasm modules", "switched_from": "", "story": "Nominal Types in WebAssembly"}, {"id": 758053072, "item_id": 47378317, "url": "https://news.ycombinator.com/item?id=47378317", "by": "flohofwoe", "date": "2026-03-14", "version": null, "stance": "recommend", "quote": "WASM code pretty much runs at native speed these days", "excerpt": "> It's not fast. My emulators here have roughly the same performance as the same code compiled as native executable (e.g. within around 5%) - this is mostly integer bit twiddling code. Unless you hand-optimize your code beyond what portable C provides (like manually tuned SIMD intrinsics), WASM code pretty much runs at native speed these days: https://floooh.github.io/tiny8bit/", "context": "", "use_case": "", "switched_from": "", "story": "Nominal Types in WebAssembly"}, {"id": 758052384, "item_id": 47378274, "url": "https://news.ycombinator.com/item?id=47378274", "by": "zffr", "date": "2026-03-14", "version": null, "stance": "recommend", "quote": "using WASM can minimize cold startup time for serverless functions", "excerpt": "> It's not fast. Not disagreeing with you, but here\u2019s an article from Akamai about how using WASM can minimize cold startup time for serverless functions. https://www.akamai.com/blog/developers/build-serverless-functions-zero-cold-starts-webassembly-spin", "context": "", "use_case": "serverless cold-start reduction", "switched_from": "", "story": "Nominal Types in WebAssembly"}, {"id": 757498112, "item_id": 47343632, "url": "https://news.ycombinator.com/item?id=47343632", "by": "titzer", "date": "2026-03-11", "version": null, "stance": "recommend", "quote": "I think the Wasm network effect is happening, it is just very slow", "excerpt": "> Language portability is a big feature. There's a lot of code that's not JS out there. And JS isn't a great compilation target for a lot of languages. Google switched to compiling Java to Wasm-GC instead of JS and got a lot of memory/speed improvements. It's also worth noting that Wasm wasn't born into a vacuum like JS was (and Java for that matter), so it is competing[1] in a crowded space. Wasm is making inroads i", "context": "", "use_case": "", "switched_from": "", "story": "Making WebAssembly a first-class language on the Web"}, {"id": 756748704, "item_id": 47296794, "url": "https://news.ycombinator.com/item?id=47296794", "by": "antonvs", "date": "2026-03-08", "version": null, "stance": "recommend", "quote": "We use WASM to deploy machine learning models in the browser", "excerpt": "> It's like the tiniest ever fraction of javascript-knowing folks. \u201cJavascript-knowing folks\u201d aren\u2019t likely to have much overlap with people who have a need for WASM. It\u2019s a bit confusing because of the history of WASM, but the two are pretty separate at this point. We use WASM to deploy machine learning models in the browser, for example. That\u2019s not something we would have ever considered doing with Javascript.", "context": "", "use_case": "ML models in browser", "switched_from": "", "story": "Notes on Writing WASM"}, {"id": 756745616, "item_id": 47296601, "url": "https://news.ycombinator.com/item?id=47296601", "by": "flohofwoe", "date": "2026-03-08", "version": null, "stance": "recommend", "quote": "then WASM can be incredibly useful", "excerpt": "I mean... don't believe the hype? WASM is \"just\" another virtual ISA, everything else is just marketing. If you manage expections (in the sense of \"it's just another ISA / bytecode VM\") then WASM can be incredibly useful, e.g. all my C/C++ projects are running automatically in browsers thanks to wasm (for instance these home computer emulators: https://floooh.github.io/tiny8bit/).", "context": "", "use_case": "running C/C++ code in browsers", "switched_from": "", "story": "Notes on Writing WASM"}, {"id": 754855714, "item_id": 47178482, "url": "https://news.ycombinator.com/item?id=47178482", "by": "miroljub", "date": "2026-02-27", "version": null, "stance": "warn", "quote": "I just don't see that as a viable alternative to the web mess that we already have.", "excerpt": "> Isn't it time to throw the browser away, stop abusing HTML to make applications, and design something fit for purpose? We had Flash for exactly that purpose. For all its flaws, it was our best hope. A shame Apple and later Adobe decided to kill it in favor of HTML5. The second best bet was Java Applets, but the technology came too early and was dead before it could fly off. Some may mention WebAssembly, but I just ", "context": "", "use_case": "", "switched_from": "", "story": "Smartphone Mkt to Decline 13% in '26, Largest Drop Ever Due to Memory Shortage"}, {"id": 750082112, "item_id": 46880132, "url": "https://news.ycombinator.com/item?id=46880132", "by": "csense", "date": "2026-02-03", "version": null, "stance": "neutral", "quote": "WASM components [1] is a spec that tries to improve on this with an IDL called WIT", "excerpt": "I had to do some research to figure out what this is actually doing. When you try to pass e.g. strings through WASM functions you end up writing the data to memory and passing offset / length, which is obviously inconvenient and potentially has security implications. WASM components [1] is a spec that tries to improve on this with an IDL called WIT that lets you define functions that pass complex types with a proper ", "context": "", "use_case": "sandboxing untrusted code", "switched_from": "", "story": "Show HN: Sandboxing untrusted code using WebAssembly"}, {"id": 747498608, "item_id": 46718663, "url": "https://news.ycombinator.com/item?id=46718663", "by": "soegaard", "date": "2026-01-22", "version": null, "stance": "recommend", "quote": "I am happy you and the team added GC to WebAssembly.", "excerpt": "Yes. I am following the Scheme tradition of representing immediate values as tagged pointers. And (ref i31) is the obvious choice when using WebAssembly. I am happy you and the team added GC to WebAssembly. Details on the representation. https://github.com/soegaard/webracket/blob/main/compiler.rkt#L3763 I am more or less only using the linear memory for the JavaScript FFI. FASL-encoded values are passed back and fort", "context": "", "use_case": "", "switched_from": "", "story": "The WebRacket language is a subset of Racket that compiles to WebAssembly"}, {"id": 747126944, "item_id": 46695434, "url": "https://news.ycombinator.com/item?id=46695434", "by": "ChadNauseam", "date": "2026-01-20", "version": null, "stance": "recommend", "quote": "It also simply lets you use rust on the web. That's why I use wasm.", "excerpt": "It also simply lets you use rust on the web. That's why I use wasm. It's actually an extremely nice experience. I write all my business logic in rust, and all my UI logic in javascript. There is rust tooling that automatically generates typescript types and APIs for you that make interoperating the two languages basically effortless. And by using rust/wasm, I can reach a level of performance that would be hilariously", "context": "", "use_case": "Browser plugins and performance", "switched_from": "", "story": "Increasing the performance of WebAssembly Text Format parser by 350%"}, {"id": 747058736, "item_id": 46691171, "url": "https://news.ycombinator.com/item?id=46691171", "by": "TkTech", "date": "2026-01-20", "version": null, "stance": "recommend", "quote": "is much, much faster at 16k renders then Javascript", "excerpt": "Sure, here's a Rust/WASM procedural skybox generator I threw together the other day, and is much, much faster at 16k renders then Javascript. https://tkte.ch/night-sky/", "context": "", "use_case": "Procedural skybox rendering", "switched_from": "", "story": "Increasing the performance of WebAssembly Text Format parser by 350%"}, {"id": 747050336, "item_id": 46690646, "url": "https://news.ycombinator.com/item?id=46690646", "by": "adzm", "date": "2026-01-20", "version": null, "stance": "recommend", "quote": "I use a wasm xxhash implementation that is 40x faster than the fastest JavaScript version", "excerpt": "I use a wasm xxhash implementation that is 40x faster than the fastest JavaScript version I can find. Drop in replacement. Call overhead is minimal, could be better with stringref if that ever gets available. Also some other audio analysis stuff in wasm I've been using is 400x faster than the JavaScript implementation but admittedly I just went straight to wasm rather than try to optimize the js in that case.", "context": "", "use_case": "", "switched_from": "", "story": "Increasing the performance of WebAssembly Text Format parser by 350%"}, {"id": 744874736, "item_id": 46554671, "url": "https://news.ycombinator.com/item?id=46554671", "by": "EGreg", "date": "2026-01-09", "version": null, "stance": "recommend", "quote": "No, WASM is deterministic, JS is fundamentally not.", "excerpt": "They tried their best: https://deterministic.js.org/ No, WASM is deterministic, JS is fundamentally not. Your dislike of all things blockchain makes you say silly things.", "context": "", "use_case": "", "switched_from": "", "story": "What Happened to WebAssembly"}, {"id": 744848576, "item_id": 46553036, "url": "https://news.ycombinator.com/item?id=46553036", "by": "IshKebab", "date": "2026-01-09", "version": null, "stance": "recommend", "quote": "Fundamentally I think asm.js was a fragile hack and WASM is a well-engineered solution.", "excerpt": "> 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/ 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 ", "context": "", "use_case": "", "switched_from": "", "story": "What Happened to WebAssembly"}, {"id": 744831696, "item_id": 46551981, "url": "https://news.ycombinator.com/item?id=46551981", "by": "xipix", "date": "2026-01-09", "version": null, "stance": "recommend", "quote": "it has been a huge success despite not yet reaching bare-metal levels of performance and energy efficiency", "excerpt": "The article seems to evaluate Wasm as it were a framework upon which apps are built. It's not that, it's an orthogonal technology allowing CPU optimisations and reuse of native code in the browser. Against that expectation, it has been a huge success despite not yet reaching bare-metal levels of performance and energy efficiency. https://bungee.parabolaresearch.com/change-audio-speed-pitch One such example: audio tim", "context": "", "use_case": "Running native code in browser", "switched_from": "", "story": "What Happened to WebAssembly"}, {"id": 744824864, "item_id": 46551554, "url": "https://news.ycombinator.com/item?id=46551554", "by": "s-macke", "date": "2026-01-09", "version": null, "stance": "recommend", "quote": "WebAssembly itself is not that inefficient in storage.", "excerpt": "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 ", "context": "", "use_case": "", "switched_from": "", "story": "What Happened to WebAssembly"}, {"id": 743311184, "item_id": 46456949, "url": "https://news.ycombinator.com/item?id=46456949", "by": "m11a", "date": "2026-01-01", "version": null, "stance": "compare", "quote": "", "excerpt": "Is WASM\u2019s story for side effects solved yet? eg network calls seems too complicated (https://github.com/vasilev/HTTP-request-from-inside-WASM etc)", "context": "", "use_case": "", "switched_from": "", "story": "OpenWorkers: Self-Hosted Cloudflare Workers in Rust"}, {"id": 740009984, "item_id": 46250624, "url": "https://news.ycombinator.com/item?id=46250624", "by": "IshKebab", "date": "2025-12-12", "version": null, "stance": "compare", "quote": "can be configured to be a lot simpler than WASM", "excerpt": "See https://opensource.googleblog.com/2025/11/secure-by-design-firmware-development-with-wasefire.html This looks like it has a smaller code footprint at least. I'm not sure RISC-V is a very good target for this sort of thing. E.g. decoding the immediates in software is going to be very slow, whereas in hardware it's fast. But on the other hand it is a stable target and can be configured to be a lot simpler than WASM", "context": "", "use_case": "", "switched_from": "", "story": "Show HN: Tiny VM sandbox in C with apps in Rust, C and Zig"}, {"id": 734210691, "item_id": 45888168, "url": "https://news.ycombinator.com/item?id=45888168", "by": "a-kgeorge", "date": "2025-11-11", "version": null, "stance": "warn", "quote": "WASM lacks native threading", "excerpt": "I built dspx after hitting a wall with real-time EMG processing in Node.js. Problem: 2 kHz \u00d7 8 channels \u2192 filters \u2192 decimation \u2192 FFT. JS is too slow; the Python sidecar is complex; WASM lacks native threading. Solution: Native C++ DSP with Redis-persisted state. Workers process a chunk, save state in ~1\u20132ms, die, and resume elsewhere. Serverless DSP without losing filter history. Repo: https://github.com/a-kgeorge/ds", "context": "", "use_case": "", "switched_from": "", "story": "Show HN: dspx \u2014 Serverless-friendly DSP for Node.js (native C++ + Redis state)"}]}