WebAssembly 128-bit packed SIMD Extension
7 points · Open discussionWebAssembly
spec
WebAssembly2015–2026
WebAssembly / spec
spec
WebAssembly specification, reference interpreter, and test suite.
41Distinct people
53Mentions
1Explicit recommenders
3.5KGitHub stars
What to know before exploring
What it is
WebAssembly specification, reference interpreter, and test suite.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
They often forget to mention, that WebAssembly is just a low-level programming language (much lower than C), it has extremely simple syntax (it has just four data types, no…
IvanK_net used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- webassembly/design · linked in 5 of the same discussions
- webassembly/wabt · linked in 4 of the same discussions
- webassembly/binaryen · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year53 dated mentions
Observed mentions: 2015-09-03 02:59:47 UTC to 2026-05-25 19:07:52 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 17 | 4 | 13 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 5 | 1 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
spec
This repository holds the sources for the WebAssembly specification,
a reference implementation, and the official test suite.
A formatted version of the spec is available here:
webassembly.github.io/spec,
Participation is welcome. Discussions about new features, significant semantic
changes, or any specification change likely to generate substantial discussion
should take place in
the WebAssembly design repository
first, so that this spec repository can remain focused. And please follow the
guidelines for contributing.
citing
For citing WebAssembly in LaTeX, use this bibtex file.
Read the full README on GitHubWhat Hacker News says
53 sourcesI followed the same testing approach when writing a Wasm binary parser (technically, a decoder)[0].
It was pretty helpful having the official spec suite available and a major boost of confidence that your parser is compliant.
Nevertheless, it was my own tests that found a regression in the latest published version of the spec[1], which shows how important it is to have a variety of implementations.
[0] https://github.com/agis/wadec
[1] https://github.com/WebAssembly/spec/issues/2066
In Watgo – A WebAssembly Toolkit for GoI'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/pap...
In a way it's a complete instruction set and bytecode format, that could have been frozen in time and still be a useful addition to x86, ARM, RISC-V. It's great that the Wasm v1 specs is small enough for various implementations to arise. There are Wasm interpreters written in C, Zig, Go, Rust, as well as Wasm to C compiler, disassembler, little languages that compile to Wasm.. I see great value in that simplicity and smallness
Read the rest
, it contributes to easier cross-platform and cross-language compatibility.
That's why newer features in the specs after v1, like garbage collection, components, interfaces, feel like they're higher-level abstractions that are not so relevant for my use case. Some feel like they could be developed outside of Wasm specs, like you said, dissolved at compile time to existing primitives. I'm guessing much of the benefit is for integrating with Rust ecosystem, and perhaps other languages gradually.
Tangential: I decided to write a Wasm parser (more precisely, a decoder the the Wasm binary format) from scratch, as a means to learn both Wasm and Rust[0].
It was the first time I was writing this sort of thing, but I found the spec very clear and well-written.
Fun fact: I was surprised when the test from a toy parser surfaced a real regression in version 3 of the spec[1], released roughly 4 months before.
[0] https://github.com/agis/wadec
[1] https://github.com/WebAssembly/spec/issues/2066
In Notes on writing Rust-based WasmThat's why I built the WebAssembly one - the JavaScript one started with MQJS, but for the WebAssembly one I started with just a copy of the https://github.com/webassembly/spec repo.
I haven't quite got the WASM one into a share-able shape yet though - the performance is pretty bad which makes the demos not very interesting.
In Opus 4.5 is not the normal AI agent experience that I have had thus farThe answer was kind of known before hand. It was to enable the use of GCed languages like Python on Ruby to create WASM applications. Meanwhile, non-GCed languages like Rust, C and C++ were supposed to continue to work as before on WASM without breaking compatibility. This is what they seem to have finally achieved. But I needed to make sure of it. So, here are the relevant points from the WASM GC proposal [1]:
* Motivation
- Efficient support for high-level languages
- faster execution
- smaller modules
- the vast majority of modern languages need it
* Approach
- Pay as you go; in particular, no effect on code not using GC, no runtime type information unless requested
- Don't introduce dependencies on GC for other features (e.g., using resources through tables)
[1] https://github.com/WebAssembly/spec/blob/wa
Read the rest
Found a draft here:
WebAssembly Specification - Release 3.0 (Draft 2024-11-07) https://webassembly.github.io/spec/versions/core/WebAssembly... (PDF)
Source: https://github.com/WebAssembly/spec
In WASM 2.0There's a change history in the spec at https://webassembly.github.io/spec/core/appendix/changes.htm... and I see a 3.0 branch with updates for 3 https://github.com/WebAssembly/spec/blob/1e8f1dad8ca35ef3941...
In WASM 2.0The WebAssembly reference interpreter [0] has a JS library that lets you do this.
let wast = require("./wast.js");
let binary = wast.WebAssemblyText.encode("(module)");
[0] https://github.com/WebAssembly/spec/tree/main/interpreter#ja...
In Is WebAssembly Memory64 worth using?You can parse many things from this file, what are you trying to extract?
https://github.com/WebAssembly/spec/blob/main/document/core/...
In WASM InstructionsStill strikes me as super sad JS never got SIMD support. It seemed like there were some strong candidate specs. On Node there are some add-on npm libraries that implement.
My understanding was the main protest was that we would get wasm & some certain implementers said they wanted to focus their energy on wasm.
That was well over half a decade ago & wasm is still in incredible infancy, with basically only statically linked capabilities in the spec.
Wasm SIMD proposal itself only merged into wasm in November 2021. https://github.com/WebAssembly/spec/pull/1391
It seems really unfortunate to have decided to keep JS the slow inferior language.
In The fastest word counter in JavaScriptBig fan of this author's work.
They have a Gameboy emulator written in C, which can be compiled to WASM and run in the browser.
https://github.com/binji/binjgb
I learned a lot from the code.
Also I love this project with a bunch of demos in hand-written WebAssembly Text (WAT) format, which is like low-level Lisp that works only with raw memory, numbers, and minimal syntax.
https://github.com/binji/raw-wasm
Then I discovered the same author is quite active in the WebAssembly ecosystem, including specs and tooling. Fascinating stuff!
https://github.com/WebAssembly/spec
https://github.com/WebAssembly/wabt
In Smolnes: A NES emulator in less than 5000 significant bytes of C++Heya,
(1) Thank you for implementing this in JSC!! I hope they take it, it makes it into Safari, and the tail-call proposal advances.
(2) I don't think you are exactly right about the call stack being observable via thrown exceptions. There's no formal spec for the v3 exceptions proposal yet, but in the documents and tests, there's nothing that would change in WebAssembly core to make the call stack observable. (There's no ".stack property" that would be added to Wasm itself.) It's true that the proposal amends the JS API (but only the JS API) to describe a traceStack=true option; from Wasm's perspective I understand that's just an ordinary exception that happens to include an externref value (just like any other value) to which Wasm attaches no special significance. The Web-based engines can attach an informative stack trace if they want
Read the rest
, but there's no requirement preventing frames from having been optimized out. The non-Web engines won't have to think about this.
(3) I think the real reason that a Wasm engine can't implicitly make tail calls proper is that the spec tests forbid it, basically because they didn't want the implementation base to fragment by having some engines perform an optimization that changes the space complexity of a program, which some programs would have started to depend on. (The spec tests say: "Implementations are required to have every call consume some abstract resource towards exhausting some abstract finite limit, such that infinitely recursive test cases reliably trap in finite time. This is because otherwise applications could come to depend on it on those implementations and be incompatible with implementations that don't do it (or don't do it under the same circumstances.)")
But the issue is much weaker than "call stack is observable" -- it's more like "infinite recursion must trap eventually, but it can be nondeterministic when."
More discussion here: https://github.com/WebAssembly/spec/issues/150
Well, backwards compatibility is really a spectrum and the interpretation of the concept can fall at either end of the spectrum depending on what a person is working on. As far as wasm is concerned, there are at least two known discrepancies that made into this draft as documented here https://github.com/WebAssembly/spec/issues/1439.
Especially the last comment by Alex here seems interesting to me – on one hand the observable result of the execution changes for the same program. On another, who is going to bother writing such programs? Should WebAssembly specification be allowed to assume nobody does and make changes such as these?
In WebAssembly 2.0 First Working DraftShowing the 15 most recent of 53 sources. Enable JavaScript to search and browse every indexed mention.