By ByteBot
You used WebAssembly today. Open Figma? WASM cut load times by 3x. Browse a Cloudflare-protected site? WASM enables sub-millisecond security checks. Play Godot web games? WASM made them possible. Yet a December 2025 blog post by EmNudge asking “What happened to WebAssembly?” sparked 163 heated Hacker News comments debating whether WASM is dead or thriving. Here’s the truth: WebAssembly succeeded so well it became invisible—and that invisibility feels like failure.
Invisible Infrastructure = Perceived Failure
WebAssembly succeeded by disappearing. Library authors at Figma, Cloudflare, Godot, and Ruffle use WASM behind the scenes, making it “opaque” to end users, as EmNudge notes. Developers expected to write WASM directly for applications. Instead, they got library-level adoption where the internals remain hidden. This creates a paradox: the better an abstraction works, the less visible the technology becomes, and the more it feels like failure to those measuring by developer awareness.
The evidence proves WASM works. Figma’s C++ rendering engine compiled to WASM cut load times by 3x. Cloudflare Workers achieves sub-millisecond startup times using WASM’s sandboxing model for untrusted code. Godot’s entire game engine runs in browsers. Ruffle preserves Flash content through WASM emulation after browsers dropped Flash in 2021. As one HN commenter puts it: WASM is “probably in a lot more places than you think, silently doing its job behind the scenes.”
The perception problem is structural. When libraries handle WASM complexity, users reap benefits without knowing the technology exists. Developers who don’t see WASM in their daily workflow assume it failed—even while using tools powered by it. Success metrics based on developer awareness fundamentally misalign with end-user benefit.
Related: Developer Skills Decay in 2.5 Years: Learning Crisis
The “JavaScript Killer” That Never Was
WASM was hyped as JavaScript replacement for frontend development. That was always “very unlikely,” EmNudge argues, because WASM lacks direct DOM access. Reality diverged from expectations. WASM succeeded as portable bytecode for compiled languages (C, C++, Rust, Zig), not as an application development platform replacing JavaScript.
The JavaScript ecosystem became too good to challenge. React, TypeScript, and Vite form “an incredibly productive stack,” as HN commenters note. Modern JavaScript engines received massive optimization investment. For most web apps, migration costs outweigh WASM’s performance benefits. Some HN users argue “WASM isn’t really faster than JS” for typical workloads—a testament to JavaScript engine advancement, not WASM weakness.
WASM’s technical limitations reinforced this outcome. No native DOM manipulation means JavaScript bridges remain mandatory for UI work. No native string type requires marshaling between languages. These aren’t bugs—they’re architectural decisions prioritizing security and portability over convenience. However, they guaranteed WASM wouldn’t replace JavaScript for application development.
The Self-Inflicted Wounds
EmNudge, a WASM advocate, admits the community sabotages itself: “purposely obfuscating teaching material around Wasm” is “a fight I lost a few times.” If supporters acknowledge documentation problems, imagine how newcomers struggle. The community made WASM harder to learn than necessary.
HN commenters pile on with tooling complaints. “Still not there after 10 years,” one notes. Debugging remains broken across browsers. No standard module import system exists. Emscripten workflows grow complex. Default Rust builds produce “a few megabytes” for hello world programs without optimization knowledge most developers lack. These problems stem from choices, not inevitability.
EmNudge created “watlings” (a rustlings-style WASM course) addressing the teaching gap. That’s treating symptoms, not causes. The broader community needs to decide: do they want WASM adoption, or do they prefer maintaining gatekeeping through complexity? Right now, self-inflicted wounds compound the perception problem invisible success already creates.
Pragmatists vs Visionaries
The HN thread (163 comments) exposes two camps. Pragmatists say WASM “succeeded as designed”—a portable, secure bytecode for compiled code in browsers. They cite concrete wins: audio processing at native speed, emulators within 5% of native performance, SQLite and DuckDB running in browsers, 4x image processing speedups over JavaScript.
Visionaries feel disappointed. WASM didn’t replace JavaScript. It hasn’t revolutionized web development. Adoption remains niche. Accessibility concerns loom—canvas-rendered WASM apps “would destroy screen reader support,” one commenter warns. The “universal runtime” fantasy died. As another puts it: WASM is “a language [bytecode] searching for problems beyond its original scope.”
Both perspectives hold validity. Pragmatists measure by utility and real-world adoption. WASM powers production systems at scale. Visionaries measure by transformative potential and developer awareness. WASM remains invisible to most developers. Success depends entirely on which metrics you choose. This isn’t binary success or failure—it’s successful engineering with failed ambitions.
What This Teaches Us About Tech Success
WebAssembly’s story reveals how we measure technology success. The community debates whether WASM succeeded or failed, but that binary framing misses the point. WASM achieved technical goals while disappointing broader expectations. That’s not failure—that’s misaligned expectations poisoning perception of legitimate achievement.
Invisible infrastructure is still successful infrastructure. End-user benefit matters more than developer awareness. If Figma loads 3x faster and developers don’t know why, that’s an abstraction working correctly, not technology failure. We need better frameworks for evaluating technologies that succeed behind the scenes.
Hype-driven expectations guarantee disappointment. WASM was positioned as “JavaScript killer” when its actual value proposition was “portable bytecode for compiled languages.” Technologies succeed or fail based on realistic expectation-setting, not just technical merit. The gap between hype and reality creates perception problems even when the technology delivers on actual design goals.
Key Takeaways
- WebAssembly succeeded by becoming invisible infrastructure powering Figma, Cloudflare, Godot, and Ruffle—absence from developer workflows doesn’t equal failure
- WASM never aimed to replace JavaScript for UI development; it succeeded as portable bytecode for compiled languages, not as application platform
- Community self-sabotage through poor tooling and “purposely obfuscating teaching material” compounds perception problems invisible success creates
- Pragmatists measuring by utility see success (concrete production wins); visionaries measuring by transformative impact see failure—both perspectives valid, metrics differ
- Lesson for evaluating hyped technologies: measure against actual design goals, not marketing promises; invisible utility beats visible disappointment
