March 11, 2026
Who gets custody of the browser?
Making WebAssembly a first-class language on the Web
Script tags, plugins, and a JS turf war — devs are divided
TLDR: A new push would let websites load WebAssembly like normal scripts and define simple interfaces, aiming to make non-JavaScript code first-class on the web. The community is split between excitement over safer plugins and simpler loading, anger at years lost to process fights, and warnings that JavaScript still rules for browser safety.
WebAssembly (WASM) wants to sit at the big kids’ table on the web, and the dev world is having feelings. The latest push: let sites load WASM like normal scripts and define clean “interfaces” so code from other languages plugs in easily. Firefox is shipping support, and “components” promise fewer hoops to jump through. In plain English: faster apps, less glue code, and a chance for more languages to run on the web without begging JavaScript for permission.
But the comments? Spicy. One camp is hyped: “interfaces for WASM modules” means safer, sandboxed plugins and new app ideas, says swiftcoder. Another camp slams the brakes: “JavaScript is the right abstraction… WASM is the wrong one”, argues pizlonator, saying the browser’s wild, ever-changing world needs JS’s flexible style. Then there’s the blame game: mananaysiempre grumbles this “could have happened half a decade ago” if the standards folks had stuck to WebIDL (the web’s way of describing APIs) instead of inventing a new one. And everyday devs chime in with relatable pain: “the WASM cliff is real,” says steve_adams_86, describing a toolchain that feels like a boss fight. Meme of the day: “Who gets custody of the DOM?” The HN thread is a popcorn-worthy read.
Key Points
- •WebAssembly has gained significant features since 2017, including shared memories, SIMD, exception handling, tail calls, 64‑bit memories, and GC support, plus smaller improvements like bulk memory instructions and multiple returns.
- •Despite technical progress, WebAssembly remains a second‑class language on the web due to weaker integration with the web platform compared to JavaScript.
- •Two main gaps are highlighted: code loading and access to Web APIs, both of which are simpler and more direct in JavaScript.
- •Current WebAssembly loading requires the WebAssembly JavaScript API and a complex instantiation process, creating developer friction.
- •The esm‑integration proposal (supported in bundlers and being implemented in Firefox) enables module imports and script‑tag loading for WebAssembly, streamlining common loading patterns.