Yeah. You can use a base64 data uri, but that's not great either. There is a proposal for <script type="module">, but it looks untouched for several years: https://github.com/WebAssembly/proposals/issues/12
In Introduction to WebAssembly ComponentsWebAssembly
proposals
Python2018–2025
WebAssembly / proposals
proposals
Tracking WebAssembly proposals
39Distinct people
49Mentions
0Explicit recommenders
1.1KGitHub stars
What to know before exploring
What it is
Tracking WebAssembly proposals
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- webassembly/gc · linked in 4 of the same discussions
- webassembly/meetings · linked in 4 of the same discussions
- webassembly/interface-types · linked in 3 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, 11:19:25 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 year49 dated mentions
Observed mentions: 2018-10-22 17:05:09 UTC to 2025-05-10 00:07:26 UTC.
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 |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 11 | 1 | 10 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
WebAssembly proposals
Finished Proposals
Inactive Proposals
Active proposals
Proposals follow this process document.
Phase 5 - The Feature is Standardized (WG)
These proposals have not yet been merged to the spec. Merged proposals are listed in Finished Proposals.
Proposal
Champion
JS Promise Integration
Francis McCabe
Web Content Security Policy
Francis McCabe
Phase 4 - Standardize the Feature (WG)
Proposal
Champion
Threads
Conrad Watt
Compact Import Section
Ryan Hunt
Wide Arithmetic
Alex Crichton and Jamey Sharp
Phase 3 - Implementation Phase (CG + WG)
Proposal
Champion
ESM Integration
Asumu Takikawa, Ms2ger, and Guy Bedford
Stack Switching
Francis McCabe and Sam Lindley
Custom Page Sizes
Nick Fitzgerald
Custom Descriptors and JS Interop
Thomas Lively
Phase 2 - Proposed Spec Text Available (CG + WG)
Proposal
Champion
Relaxed dead code validation
Conrad Watt and Ross Tate
Numeric Values in WAT Data Segments
Ezzat Chamudi
Extended Name Section
Ben Visness
Rounding Variants
Kloud Koder
Compilation Hints
Emanuel Ziegler
JS Primitive Builtins
Sébastien Doeraene
Acquire-Release Atomics
Conrad Watt and Rezvan Mahdavi Hezaveh
Multibyte Array Access
Brendan Dahl
FP16
Brendan Dahl
Phase 1 - Feature Proposal (CG)
Proposal
Champion
Type Imports
Andreas Rossberg
Component Model
Luke Wagner
WebAssembly C and C++ API
Andreas Rossberg
Flexible Vectors
Petr Penzin and Tal Garfinkel
Memory control
Deepti Gandluri and Ben Visness
Reference-Typed Strings
Andy Wingo
Profiles
Andreas Rossberg
Shared-Everything Threads
Andrew Brown, Conrad Watt, and Thomas Lively
Frozen Values
Léo Andrès and Pierre Chambart
More Array Constructors
Nick Fitzgerald
JIT Interface
Ben Titzer
Type Reflection for WebAssembly JavaScript API
Ilya Rezvov
JS Text Encoding Builtins
Daxpedda
Phase 0 - Pre-Proposal (CG)
Phase 0 proposals are tracked in the design repository issue tracker.
Implementation status
Implementation status of most proposals in various wasm engines is available on https://webassembly.org/features/
Contributing new proposals
Please see Contributing to WebAssembly for the most up-to-date information on contributing proposals to standard.
Read the full README on GitHubWhat Hacker News says
6 sourcesThat's via emscripten. I suspect by "directly" they meant something like Python bytecode -> WASM. Which I think might be possible later, when some of the proposals[1] like GC, exceptions, etc, are done. That sort of fuzzy line where WASM is somewhat like ASM, and somewhat like a language VM.
[1] https://github.com/WebAssembly/proposals
In Show HN: Run Python, Ruby, Node.js, C++, Lua in the Browser via x86 to WASM JIT>aren't going to see major performance improvements by dropping into WASM
I think that might also change as they add proposal and roadmap items like "direct access to the DOM"[1] to WASM.
Proposals: https://github.com/WebAssembly/proposals
Roadmap: https://webassembly.org/roadmap/
[1] https://github.com/WebAssembly/interface-types/blob/master/p...
Edit: Overall, the proposals seem to be pushing WASM closer to being a general purpose VM (VM as in JVM, not KVM).
In Maybe you don't need Rust and WASM to speed up your JS (2018)Part of the reason it's bare bones is because they started with an MVP, and are continuing to add features through a community/standards process. Garbage Collection, reference types, and Interface Types are popular proposals being worked on that I think would address some of your issues. More here: https://github.com/WebAssembly/proposals
In Is WebAssembly magic performance pixie dust?Because before it can access the DOM, it needs to support:
* reference types
* interface types
* exception handling
* typed function references
* garbage collection
I.e. most WASM proposals must be accepted before we can use the DOM from WASM... by the pace it's been moving forward, I guess this will take at least several years (3-4+).
https://github.com/WebAssembly/proposals
In Is WebAssembly magic performance pixie dust?> It is production ready in all (vital) aspects concerning execution in a browser
As in (emphasis mine): "This means that there are important features we know we want and need, but are post-MVP" [1]
As in: "a Minimum Viable Product (MVP) for the standard with roughly the same functionality as asm.js, primarily aimed at C/C++;"
It's good that you specified "vital" when talking about "all" aspects. Where vital is basically "let's run MVP in an isolated sandbox with little-to-no interoperability with the rest of the browser". Because the rest of the vital things like "basically everything" [3] [4] are still MIA.
But yeah, I mean, the modern web was built on a language designed in 10 days, so I shouldn't complain, should I.
[1] https://github.com/WebAssembly/design/blob/master/MVP.md
[2] https://github.com/WebAssembly/design/blob/master/HighL