The Web is getting its bytecode: WebAssembly

In the quest for ever faster JavaScript, there has been a recurring refrain: why use JavaScript at all?

JavaScript engines have been a major focus of browser developers for some years, and the result has been substantial performance improvements from every vendor. JIT ("just-in-time") compilation that turns JavaScript code into instructions that can be directly executed on the processor brought huge speed gains. New data types have been added to the language to reduce the overhead when crunching numbers, and combined with asm.js, a high performance limited subset of JavaScript, applications running in the browser can achieve performance that's comparable with that of native code.

In spite of these improvements, the question of "why JavaScript?" remains. This is not without reason. The use of JavaScript incurs certain overheads: browsers have to read and interpret a text-based language that was designed for human authors, not for machines. The design of JavaScript itself has features that are suboptimal from a performance perspective; the way a single JavaScript variable may at different times represent a number, a string, or a fragment of HTML means that a JIT compiler may not be able to optimize as aggressively as it would like. The ability to modify the behavior of even built-in objects such as arrays can be similarly problematic.

JavaScript does have certain important advantages: it's a memory safe, sandboxed environment, meaning that (browser bugs excepted) JavaScript programs can't escape beyond the confines of the browser to access sensitive data or install persistent malware. JavaScript is also processor independent, so scripts will run just as well on an x86 PC as they will on an ARM smartphone.

However, there are well-known ways of providing the advantages of JavaScript without those perceived downsides: bytecode runtimes like Java and .NET. Unlike script files, the bytecode represents a low-level, fairly compact representation of a program. Bytecodes also tend to be much easier for computers to read and JIT compile. Bytecode systems tend to map cleanly to the underlying arithmetic capabilities of the processor, too; they tend to operate on simple integers and floating point numbers, thereby avoiding the complexity of JavaScript's object system.

As such, there has long been a degree of pressure to use a bytecode system for the browser. Both Microsoft and Sun (now Oracle) did this with .NET and Java, respectively, but these systems both depended on plugins, rather than being integrated into the browser's rendering engine the way JavaScript is. JavaScript programs could directly manipulate HTML objects; the plugins were instead off in their own world, separate from the HTML pages they resided in.

Google built a couple of systems to try to extend the browser to go beyond JavaScript. Native Client (NaCl) ran x86 (or ARM) programs in a secure sandbox, and Portable Native Client (PNaCl) did the same but using a kind of bytecode instead of x86 or ARM code. However, while Google championed these approaches other browser vendors largely rebuffed them. JavaScript was the lowest common denominator; it was the one thing that all browsers had to implement, so it was felt that it was better to make JavaScript better than to try to invent a whole new system.

As JavaScript became faster, the browser also became more capable. WebGL, for example, exposed hardware accelerated 3D graphics to the JavaScript developer. New APIs, to give access to, for example, games controllers, webcams, and microphones, have all been developed, extending the scope of what JavaScript in the browser can do. Simultaneously, a range of JavaScript-based-but-not-actually-JavaScript was devised. Microsoft's TypeScript, for example, offers various language features that Microsoft thinks are useful for the development of large programs by large teams. But browsers don't have to support TypeScript: the TypeScript compiler produces regular JavaScript that can run in any browser.

This kind of wide-ranging usage led Microsoft's Scott Hanselman to dub JavaScript the "assembly language for the Web," a sentiment largely shared by people such as Brendan Eich, who invented JavaScript, and Douglas Crockford, who invented JSON, widely used for JavaScript-based data interchange.