/
Navigation
Chronicles
Browse all articles
Explore
Semantic exploration
Research
Entity momentum
Nexus
Correlations & relationships
Story Arc
Topic evolution
Drift Map
Semantic trajectory animation
Posts
Analysis & commentary
Pulse API
Tech news intelligence API
Browse
Entities
Companies, people, products, technologies
Domains
Browse by publication source
Handles
Browse by social media handle
Detection
Concept Search
Semantic similarity search
High Impact Stories
Top coverage by position
Sentiment Analysis
Positive/negative coverage
Anomaly Detection
Unusual coverage patterns
Analysis
Rivalry Report
Compare two entities head-to-head
Semantic Pivots
Narrative discontinuities
Crisis Response
Event recovery patterns
Connected
Search: /
Command: ⌘K
Embeddings: large
TEXXR

Chronicles

The story behind the story

← → days · ↑ ↓ browse · Enter similar · o open

Mozilla's Asm.js Gets Another Step Closer To Native Performance

Mozilla's asm.js is a strict subset of JavaScript that Firefox can run significantly faster than regular JavaScript code.  Thanks to the so-called OdinMonkey module for Firefox's built-in JavaScript engine …

TechCrunch Frederic Lardinois

Context & Ripple Effects

Mozilla has been building toward this for two years: Firefox 9's JavaScript engine gains in late 2011 were an incremental tuning story, while asm.js — a strict, optimizable subset of JavaScript announced through Mozilla's fast-web-apps push — was the structural bet. By March 2013, Google had shown interest in asm.js, making it more than a one-browser experiment.

Today's news is that the OdinMonkey module in Firefox's SpiderMonkey engine takes asm.js another measurable step closer to native speed. The pickup across ZDNet, The Register, InfoWorld, and OStatic on the same day signals how closely the browser-performance crowd is tracking whether JavaScript can host compiled C/C++-class workloads.

First-order effects

  • Developers shipping asm.js-targeted applications — games and ported native code above all — get significantly faster execution in Firefox without touching their source, since OdinMonkey does the optimization inside the engine.
  • Firefox regains a headline performance differentiator over rival engines for a specific class of compute-heavy web apps, giving Mozilla a benchmark story it can market against Chrome and IE.

Second-order effects

  • Google's earlier interest in asm.js now faces a proof point: with Firefox demonstrating real gains, Chrome's V8 team is under visible pressure to either optimize the subset or argue its own JIT pipeline makes it unnecessary.
  • Toolchain authors compiling C and C++ to JavaScript gain a credible deployment target, shifting effort toward emitting asm.js-style code rather than hand-tuned generic JS.

Third-order effects

  • If other engines follow where OdinMonkey leads, the browser consolidates its role as an application platform competitive with native runtimes — with the open question being whether a single-vendor optimization like OdinMonkey converges into a cross-browser standard or fragments into engine-specific fast paths.
  • A validated fast-subset approach gives standards bodies a template for formalizing what today is a de facto convention, reshaping how the web platform absorbs low-level workloads.

The trend: Browser makers are closing the gap between JavaScript and native code by specializing engines around strict subsets of the language, turning JavaScript performance into the new front of the browser wars.