Three technologies that want to improve on JavaScript

Three technologies that want to improve on JavaScript

Summary: The hunt is on for a technology to overcome the performance limitations of the technologies originally designed to serve static web pages.

SHARE:
TOPICS: Web development
11

World Wide Web creator Tim Berners Lee may dream of people running apps in web browsers that rival those running directly on computers, but myriad obstacles remain.

For web sites and apps, JavaScript is the defacto client-side scripting language used to add the dynamic content that turns a static page into an app or a game.

But JavaScript's performance is hobbled by both its architecture, its dynamic nature, and how it is run, as an interpreted language.

The performance of JavaScript has come on leaps and bounds in recent years, thanks to browser JavaScript engines using just-in-time compilers, which typically compile certain stretches of JavaScript into machine code just ahead of being run.

But as people turn to the browser to realise more demanding tasks, such as photo editing and gaming, the hunt is on for a better performing alternative to deliver dynamic content in the browser.

A number of new technologies and approaches, from asm.js to Google's Native Client, are being touted as a possible alternative to vanilla JavaScript. Each is designed to help the performance of code running in the browser get closer to that of native code: compiled machine code that is executed directly by a computer's CPU.

However with major companies like Google and The Mozilla Foundation backing different technologies for Chrome and Firefox browser - it remains unclear which of these, if any, will likely win out.

Asm.js

The Mozilla Foundation has thrown its weight behind asm.js, a subset of JavaScript capable of delivering performance near to that of native code.

Mozilla has demonstrated asm.js carrying out a number of computationally demanding tasks, such as running a modern 3D graphics engine in this demo of Unreal Engine 3 and handling complex physics calculations needed to simulate hundreds of falling boxes.

Asm.js is a subset of JavaScript that eschews several dynamic features of the language and in doing so allows JavaScript engines in the browser to make performance optimisations that JavaScript's dynamic nature would render impossible, and help it to deliver just over 85 percent the performance of native code in a Whetstone benchmark.

Developers don't write code in asm.js, but rather typically write in C or C++, and use the Emscripten compiler, another Mozilla project, to output asm.js.

However, support for asm.js is limited to Firefox for the time being, although Google has expressed interest in adding support for asm.js optimisations to Chrome, and there are other performance limitations asm.js doesn't address, such as JavaScript engines not really being able to handle multi-threaded code.

Native Client

Google's Native Client (NaCl) allows web browsers to execute compiled C and C++ code within a sandbox.

Google is aiming for the performance of apps running inside NaCl to be superior to that of asm.js, coming within a few percentage points of native code.

As well as the performance benefits NaCl brings over JavaScript, it allows developers to reuse existing C and C++ code libraries.

Google has used the technology to power its recently launched photo editing tools for Google+, based on the Snapseed photo app technology it acquired from Nik Software.

NaCl runs inside the Chrome browser on Windows, Mac, Linux, as well as on Chrome OS.

However, despite NaCl being publicly demoed in 2011, other browser vendors are not currently supporting the open source project, and prominent members of The Mozilla Foundation have distanced themselves from the notion of running native code inside a sandbox.

Google Dart

Google's goal with Dart is to "replace JavaScript as the lingua franca of web development".

Dart is a scripting language designed to address a range of shortcomings of JavaScript, with Google claiming it is both easier to program in and offers superior performance.

Dart outpaces JavaScript on two significant benchmarks – Richards and DeltaBlue, according to Google tests. Google has also demonstrated how Dart's support for SIMD (Single Instruction, Multiple Data) instructions, which allows the same operation to be carried out on multiple data points simultaneously, can deliver three times the frame rate of an animation rendered without it.

20130516_Dart_Google_IO_004_610x382[1]
Google's Dart benchmark. Image: Google

Dart – a class-based, single inheritance, object-orientated language with C-style syntax – is at a disadvantage in that supporting it would require browser makers to add support for another runtime – while every major browser supports JavaScript.

Neither Mozilla or Microsoft have shown any interest in implementing support for the scripting language directly and the only browser to run Dart directly is a special version of Chromium that embeds the Dart Virtual Machine.

Dart can also be compiled into JavaScript using the dart2js compiler, although JavaScript compiled from Dart won't run as fast as native Dart.

Speaking earlier this year Google programmer Lars Bak said Google's ultimate aim is to get Dart into Google Chrome.

JavaScript evolution?

Apart from these options, there is also the chance that the performance of JavaScript and other web technologies, bolstered by the growing power of the computers they run on, may reach a point where it is good enough for 90 per cent of apps out there, a view recently put forward by Jo Rabin of the web standards body W3C.

Further reading about web development

Topic: Web development

About

Nick Heath is chief reporter for TechRepublic UK. He writes about the technology that IT-decision makers need to know about, and the latest happenings in the European tech scene.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

11 comments
Log in or register to join the discussion
  • Lipstick on a pig

    The history of web development is one where, time and again, otherwise smart people have tried to trick it into being something it was never intended to be: a rich application development environment. These efforts are always undone by the twin technical debts of HTML and JavaScript. Microsoft tried to overcome this with Silverlight, but all around stupidity prevented what should have been its overwhelming success.
    Sir Name
    • No Silver Bullets

      From my vantage point, Silverlight looked like a second pass at Flash and felt like the continuation of a trend that included .net : jvm, Draw : Photoshop, XPS : PDF. It also looked like an entire development platform, rather than an improvement on client-side processing invocation.

      As a complex nexus between the wild world and the user's processor, I would have expected that widespread adoption would mean, like Flash and java, it was something that would become a malware vector, but, perhaps by starting from scratch, it would have had a better base and fewer issues. The os has the best resources for security — it's quite nice today in this Pre-Snowden dimension I write from — and we would trust Microsoft to have Silverlight work most securely and patched quickest with Windows as the os. If I remember correctly, the few who did not use Windows had to look to Ximian's endorsed but remote tag along called Moonlight.

      I hope I may be forgiven for misunderstanding Silverlight as a land grab for business purposes rather than a boon for all personkind. Besides, I didn't care to do Flash programming in the first place. If it wasn't for Netflix, back when I thought I would be watching from my computer (I don't), I wouldn't have installed it.

      I'm not crazy about javascript, but I've used it in making web sites, and the barrier of entry is fairly low. Do not underestimate the value of that, the value of good enough.

      We may turn our nose up on the language, but, frankly, the job to be done was to put in a reasonably fast runtime that was dealing with data that came into the runtime as text and text only. No browser maker could get too far ahead of the standard definition, otherwise web pages would break. Now that the runtime has stabilized, folks are interested in treating it as a vm and writing higher level language compilers to introduce type (and thread) safety and to help new to the domain developers with their incorrect mental model of a javascript object and their unfamiliarity with working with lexical scope (with no declarations) and functions as first class objects.

      I sort of expect developers to try and squeeze out every bit of performance from a technology, and the richness of the application was a client expectation and to simulate this simplifies user training, an impossibility when bringing an application to millions of users. That's the goal, and many times, many people fall short of their goals. It doesn't mean they didn't advance. It doesn't mean they didn't get somewhere that was a better or perfectly fine place to be.

      Today, we can do better, and people are trying. I extend sympathy that the world didn't love the platform you did. I recommend letting that go, though.
      DannyO_0x98
      • re:

        I'm not holding on to Silverlight. I started doing development in the DOS command line days, moved to Windows in its pre-2.0 days, moved to .Net, first with WinForms, then WebForms, now MVC. doing Web development, I've used HTML and JavaScript extensively. My distaste for them is because they are so primitive compared to what is available for native development - and what Silverlight offered. We're stuck with HTML and JavaScript essentially as they are today because of the nature of standards. It seems to me that the move to Web standards development from native development has been a devolution and stagnation of development technology.
        Sir Name
        • Yes, it is fustrating

          I agree, after having used xaml and c#, it is a step backwards to go to html and js.
          About js, mozilla is also developing rust, it would be nice if that language could be the next standard for the web
          aviamquepasa
        • "Primitive"

          Machine language is "primitive", but who codes in ML these days?

          JavaScript is the raw language, but there are so many toolkits out there that you don't have to do things from scratch.
          davidr69
    • No need. 99% of web apps don't need to be faster

      And for those that do 85% of native speed is good enough that one hw refresh cycle puts your 85% at faster than native code on your previous hw.
      Johnny Vegas
  • No mention of TypeScript?

    Probably the most "cake and eat it" post-Javascript paradigm I've seen. Surprised the author didn't consider it.
    Mac_PC_FenceSitter
    • Powerful, but..

      It originates from Microsoft, so you won't hear many ZDNet authors talking about it.
      BruinB88
    • re:

      While TypeScript does mitigate some of the deficiencies of JavaScript and it has the Anders Hejlsberg pedigree, it's still a BandAid on an incurable illness just like the others.
      Sir Name
    • Typescript has good intentions

      But it doesn't really solve the problem. In the end it compiles into javascript, which still has it's limitations. In addition, when you develop in type script you expect or hope that the interpreter conveys your intentions correctly in javascript...and it doesn't always do that.

      Silverlight was fine for line-of-business applications, but anyone who ever expected it to be the hub by which all client-side development would revolve is misguided. I don't think client-side internet development should ever revolve around a proprietary technology. Javascript with HTML5 is the best we have right now for rich internet application development. Regardless of how difficult and cludgey it is, it is sooo much better than it used to be.
      bmonsterman
  • Would be great

    To see the web move forward in one fashion. webASM looks cool and NaCL does also but its unfortunate that only one browser supports each...
    Jimster480