JavaScript is often used in a way that was never intended: as a platform for the development of large Web applications that are hosted in the browser. If that had been its intended use -- rather than simply for adding simple dynamism to Web pages - it would almost certainly have been designed differently.
That's because there are two main problems with the language when creating large Web applications.
First, there's the performance problem: There's no getting around the fact that large applications written in JavaScript are relatively slow, and that impacts the end users of the applications.
Second, there's the problem of the structure of JavaScript itself: It's a language that's difficult for large teams to develop in. That's because it lacks structure and strong ties between modules, and because it's hard to communicate the intent of the code within the code itself. For a solo developer that's not necessarily a problem, but for a team of developers working on a large project, communicating the intent of the code is key -- especially over time as the original developers move on.
Large applications are usually also modular, and different people are responsible for developing different pieces. But JavaScript is dynamic, and the behavior of objects can change over time. That's very different to what's the case with C or C++, or even Java or C#, and it means you generally need to execute your code to verify that it works.
The Need for Web App Speed
JavaScript has certainly enjoyed some considerable speed improvements over time, and there was a great leap forward following the introduction of Google's V8 JavaScript engine about five years ago. But it's apparent that JavaScript developers are hitting the speed limits with the current generation of JavaScript engines. To make the next great leap forward in performance a new approach seems to be called for.
One possibility is asm.js, a highly restricted subset of JavaScript that doesn't have the dynamic characteristics of JavaScript that make it hard to optimize.
As the name suggests, this is intended to be thought of as a kind of assembly language for JavaScript engines. It's currently in beta, and it's being pushed forward by Mozilla.
As it is a subset of JavaScript it is fully backwards compatible with current JavaScript engines, and in an engine that is asm.js ready it runs faster than normal JavaScript, at up to about half the speed of native code.(The latest version of Firefox [Version 22] has support for asm.js optimization, and there's a demo of the technology on the Mozilla Developer Networks site.)
Just as C++ or C# developers may drop to a lower level language when they want to tackle a particularly performance-critical piece of code, asm.js could be used by JavaScript developers -- most likely games developers -- when they come to the most performance critical parts of the code. It's not something you would want to develop a whole application in, but it will allow a subset of the code to run very quickly.
In fact most developers will probably never use asm.js directly at all. More likely they would use C or C++ (or take existing C or C++ applications) and then compile the code into asm.js using the Emscripten transcompiler.
Large Scale Web App Development
It might provide a speed advantage, but when it comes to developing large scale Web applications in JavaScript, asm.js doesn't help. What may help, though, is an open source Microsoft initiative called TypeScript. Conceptually TypeScript is the exact opposite of asm.js: where asm.js is a subset of JavaScript, TypeScript is a superset.
What this superset does is bring some structure to JavaScript development, providing a command line compiler that emits regular JavaScript, type checking, and Visual Studio 2012 integration via a plugin. What it doesn't do is provide a performance advantage: TypeScript compiles to JavaScript that runs at a similar speed to handwritten JavaScript.
Web App Speed and Scale
So asm.js promises greater speed, and Typescript provides a JavaScript development environment that's suitable for large scale Web applications. But neither approach offers both.
That's where Google's Dart comes in. The goal of Dart is "ultimately to replace JavaScript as the lingua franca of Web development on the open Web platform," according to a Google internal email.
It's an ambitious goal, so what is Dart? It's an open source programming language that's been designed with the application of large scale applications and high performance in mind. In fact calling Dart a language may be a misnomer, because a validator and various other development tools are all bundled in Dart.
Applications written in Dart can run in a Dart virtual machine (VM) at about twice the speed of JavaScript on browsers that support it. At the moment there's only support for Dart in a custom version of Google's open source Chromium browser called Dartium, but support will almost certainly be added to Chrome as well.
Compiles to JavaScript
It can also be compiled into JavaScript for general browser compatibility using the dart2js compiler. While JavaScript derived from Dart won't run as fast as native Dart, it will run faster than handwritten JavaScript, according to Chris Buckett, a software developer and author of "Dart In Action."
"When code is converted from Dart to JavaScript the compiler does 'tree shaking'," Bucket says. In JavaScript you have to add an entire library even if you only need it for one function, but thanks to tree shaking the Dart-derived JavaScript only includes the individual functions that you need from a library, he says. Dart also analyzes your code and can optionally do a form of type checking, and can remove some manual checks that aren't necessary, Buckett says. With handwritten JavaScript, developers are forced to program very defensively, he adds.
Killer Dart Apps
As yet there are no plans for any other browsers beyond Google's to support Dart directly, so the chances of it becoming the lingua franca of the Web appear slim. But Buckett maintains that the twin advantages of performance and ease of large scale development -- plus the ecosystem of Dart tools that are available -- may mean it proliferates.
"In the short term its very unlikely that we will see the Dart VM in other browsers, but if there are killer apps in Dart that run really fast in Chrome -- something like the next Facebook -- then people will inevitably say 'let's include it in our browser'," says Buckett. "This is especially true in the mobile browser space, because JavaScript kills battery life."
The good news for JavaScript developers is that it is fairly easy to convert JavaScript skills to Dart, although developers are likely to find Dart more restrictive than JavaScript. But for anyone who is used to developing in server-side languages like Java or C#, these restrictions won't seem too onerous.
Paul Rubens is a technology journalist based in England. Contact him at paul@rubens.org.Follow everything from CIO.com on Twitter @CIOonline, on Facebook, and on Google +.
Read more about developer in CIO's Developer Drilldown.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.