Skip navigation
Help

JavaScript engines

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
Peter Bright

Aurich Lawson / Thinkstock

In a bid to make JavaScript run ever faster, Mozilla has developed asm.js. It's a limited, stripped down subset of JavaScript that the company claims will offer performance that's within a factor of two of native—good enough to use the browser for almost any application. Can JavaScript really start to rival native code performance? We've been taking a closer look.

The quest for faster JavaScript

JavaScript performance became a big deal in 2008. Prior to this, the JavaScript engines found in common Web browsers tended to be pretty slow. These were good enough for the basic scripting that the Web used at the time, but it was largely inadequate for those wanting to use the Web as a rich application platform.

In 2008, however, Google released Chrome with its V8 JavaScript engine. Around the same time, Apple brought out Safari 4 with its Nitro (née Squirrelfish Extreme) engine. These engines brought something new to the world of JavaScript: high performance achieved through just-in-time (JIT) compilation. V8 and Nitro would convert JavaScript into pieces of executable code that the CPU could run directly, improving performance by a factor of three or more.

Read 94 remaining paragraphs | Comments

0
Your rating: None

I'm Not There (1956) writes "Last week the news came in that Google is supposed to unveil 'Dart,' a new programming language for browser-based apps. Now an internal email from late last year describes this project as the 'high risk/high reward' path [of Google's browser development strategy]. Apps in this new language will run in a VM on browsers that support it, and can be translated to JS for other browsers. 'Performance, developer usability, and ability to be tooled' are the main characteristics of the language."

The email notes that Google will be working on ECMAScript Harmony in the near term, but they describe the project as ultimately doomed by "fundamental problems" with ECMAScript. It's interesting that Google took part in abandoning ECMAScript 4, which would have been almost fully backward compatible with current implementations while solving most of the "fundamental problems" Google claims require a brand new language to fix.

Read more of this story at Slashdot.

0
Your rating: None