Google shows interest in ASM.js, Mozilla's plan for fast Web apps
A Chrome programmer seeks support for a new Mozilla technology to bridge the C and JavaScript languages — even though Google has competing ideas. — At least some at Google want to embrace a Mozilla-backed project …
Context & Ripple Effects
Mozilla's fast-web-apps push lands an unlikely validator: a Chrome programmer is publicly seeking support for ASM.js, Mozilla's technique for bridging C code into JavaScript, even though Google has its own competing ideas for speeding up web applications. That a V8-side engineer would champion a Mozilla-backed project says something about how far ahead of Google's in-house approach the idea currently looks.
The relationship between the two companies is already combative elsewhere: Mozilla launched Boot to Gecko in 2011 explicitly as a mobile rival to ChromeOS, while Google has been extending Chrome with its own platform features like Web Intents. Interest in ASM.js cuts against that pattern — it suggests the performance layer of the web is one arena where cross-vendor alignment may be easier than platform politics.
First-order effects
- ASM.js gains immediate credibility beyond Firefox: if Chrome engineers engage with it, Mozilla's bid to make the browser a viable target for C-class applications gets tested against the most widely used engine rather than staying a single-vendor experiment.
- Google faces an internal fork — back a rival-originated standard that could speed up apps on Chrome, or hold the line on its own competing approach and risk looking obstructive on open web technology.
Second-order effects
- Other engine vendors watching this exchange — Microsoft most obviously — get a signal that near-native JavaScript compilation is where browser performance competition is heading, pressuring them to pick a side or ship their own answer.
- Developers porting C/C++ codebases to the web gain a potential write-once path: if both major engines optimize for the same subset, toolchain investment consolidates around ASM.js-style output instead of per-browser targets.
Third-order effects
- If the pattern holds, the browser becomes a compilation target for native-language software, eroding the distinction between 'web app' and 'installed app' — with the standards process, not any single vendor, deciding how fast that happens.
- Cross-company adoption of a rival's proposal, as with this Chrome engineer's outreach, points toward a web platform where performance standards are negotiated among competing engines rather than dictated by whoever ships first.
The trend: Browser makers are converging on near-native execution inside JavaScript as the next performance battleground, with vendor-originated proposals like ASM.js testing whether cooperation can outrun platform rivalry.