ANAndrewDucker·Dec 16, 2019
For the reasoning behind this, see https://github.com/WebAssembly/design/blob/master/FAQ.md#why...
In WASM as a Platform for AbstractionWebAssembly
design
Web Development2015–2026
WebAssembly / design
design
WebAssembly Design Documents
196Distinct people
260Mentions
2Explicit recommenders
11.6KGitHub stars
What to know before exploring
What it is
WebAssembly Design Documents
GitHub
Where it is used
What people are saying
I love the fact that they chose s-expressions for the textual representation of WASM[0][1]. [0]: https://developer.mozilla.org/en-US/docs/WebAssembly/Underst... [1]:…
kuwze used a recommendation phrase. 2 indexed comments match. 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/spec · linked in 5 of the same discussions
- webassembly/interface-types · linked in 3 of the same discussions
- emscripten-core/emscripten · 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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:27:21 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 year260 dated mentions
Observed mentions: 2015-06-17 16:27:29 UTC to 2026-05-03 00: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 | 53 | 5 | 48 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 66 | 1 | 65 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 66 | 5 | 61 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 16 | 0 | 16 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 11 | 0 | 11 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 13 | 3 | 10 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
12 sources> In what sense can a wasm program "crash?"
I'm not an expert in wasm but memory allocation may fail depending on the host environment. Also, runtimes of higher languages may define their own crash cases. As it is a stack machine dumping a stacktrace in case of "crash" should be easy.
> Is there big-endian support?
Wasm still assumes little-endian byte ordering. Honestly who really cares about big-endian?
https://github.com/WebAssembly/design/blob/master/Portabilit...
In WASM as a Platform for Abstraction> single stand-alone HTML file for offline presentation.
TBH HTML isn't a really good format for stuff like this, as HTML is text-only. Same goes for HAR. The moment you want to embed large images/video you run into size problems.
It would be really nice if browsers supported some kind of archive that contains multiple resources like images, wasm files, etc, that would all be accessible by the browser if you open it. file protocol is basically being deprecated by chrome for stupid security reasons: https://github.com/WebAssembly/design/issues/1200
In Show HN: Browser-based PowerPoint alternativeIt's not having a runtime that's the problem, it's limitations in WASM's control flow constructs: https://github.com/WebAssembly/design/issues/796#issuecommen...
And WASM has this limitation as a consequence of limitations in the V8 and SpiderMonkey engines. See http://troubles.md/posts/why-do-we-need-the-relooper-algorit... and https://news.ycombinator.com/item?id=19997091 And those engines have those limitations because they're a reasonable design tradeoff in the context of executing JavaScript.
I think even if WASM gets a limited goto sufficient to resolve the most problematic performance issues, languages like Go that use more sophisticated control flow constructs (e.g. stackful coroutines) will always be at a disadvantage relative to C or Rust when it comes to WASM as absence of other various low-level constructs (e.g. ability to dir
Read the rest
ectly handle page faults) will incur higher relative penalties. The same thing could be said about Rust's new async/await--WASM will compound the costs of the additional indirect branching in async-compiled functions (not to mention the greater number of function invocations, which is at least 2x even if a function never defers).
That said, I don't think anybody uses Go for the insane performance, so as long as the performance impact isn't too severe (and limited goto support will help tremendously) it shouldn't be much of an issue. OTOH, these sorts of tradeoffs are why "native" code will always have a significant place. Especially as the wall we've hit in terms of single-threaded performance begins to be felt more widely.
WASM's (abandoned, because brotli is good enough) Binary Encoding proposal was essentially a binary AST compression system that worked for both JS trees (esprima) and wasm ASTs.
You get pretty good improvements by converting ASTs into SoA representation, interleaving them, and then compressing them. Fast to decode, too.
https://github.com/WebAssembly/design/issues/1180
In A New Bytecode Format for JavaScriptCoreI worked at Mozilla Research in the early days of Asm.js and sat next to that team. I would frequently tell them that they should support arbitrary control flow, and that there were better ways to achieve it with Emscripten than the Relooper. There wasn't much interest in improvements at the time, although it appears that the LLVM WebAssembly backend now uses a better approach.
While SpiderMonkey itself might support fancier things with control-flow, they were writing a separate compiler for Asm.js that relied on structured control flow for SSA construction, but I have no experience with how things evolved after that. Reading the thread at https://github.com/WebAssembly/design/issues/796, it seems that V8 and SpiderMonkey have roughly equivalent design constraints.
In BigInt Shipping in FirefoxWhen I proposed package management for web assembly in 2015 I suggested that it should be a fully distributed system. https://github.com/WebAssembly/design/issues/320
In Show HN: WAPM – Package Manager for WebAssemblyI brought up some similar ideas more than three years ago. https://github.com/WebAssembly/design/issues/320
In case anyone is interested in any of that discussion.
In Show HN: WAPM – Package Manager for WebAssemblyExcited to see webassembly moving forward.
I feel like the issue of feature detection [1] will be more and more relevant now that browsers start implementing parts of the specification at different rates.
[1] https://github.com/WebAssembly/design/issues?utf8=%E2%9C%93&...
In SIMD in WebAssembly – Tales from the Bleeding Edge> At it's heart it's just a compact, efficient representation of a subset of JavaScript
WASM is a well specified encoding for a stack based machine with the following 4 types, i32, i64, f32 and f64. It is very much not JavaScript.
https://github.com/WebAssembly/design/blob/master/Semantics....
In Universal Binaries Using WASMWasm is split between wasm32 and wasm64 they are separate https://github.com/WebAssembly/design/blob/master/FutureFeat...
So yes, we're at the lowest common denominator for addressing memory. You would need to explicitly build for wasm64 in the future.
Within wasmer wasm is compiled into a different IR through cranelift. That generally compiles for 64 bit systems but can compile to 32: https://github.com/CraneStation/wasmtime/pull/44
Not sure if this entirely answers your question. Seems like there are still a handful for decisions wasmer would need to make in terms of what exactly is supported.
In Universal Binaries Using WASMRelevant discussion on why this is needed: https://github.com/WebAssembly/design/issues/205
In CT-Wasm: Type-Driven Secure Cryptography for the Web Ecosystem