Whatever you may think of JavaScript, it’s undeniably one of the most important programming languages in modern computing. The only language that can run in every modern Web browser without the aid of plug-ins, regardless of platform, JavaScript is the lingua franca of the client-side Web.

That’s a heavy burden to place on one language. Naturally, not everyone is happy. As Web applications gain ever more prominence, the pressure on JavaScript to be all things to all developers is mounting

A lot of progress has already been made. Google, in particular, has been urging browser makers to improve the performance of their JavaScript engines, resulting in a miniature arms race among the top vendors. Mozilla has made distinct improvements in Firefox’s JavaScript engine in recent years, but perhaps the greatest gains have been achieved by Microsoft, after realizing that poor JavaScript performance threatened to render Internet Explorer irrelevant. Today, Microsoft is even working to integrate JavaScript into Windows and Office as a core scripting language.

But even these improvements don’t seem to be enough. As developers continue to ask more and more of JavaScript, its limitations are thrown into sharp relief. Now comes news that Google, long one of the most vocal supporters of browser-based applications over desktop software, has been quietly working on a new language called Dart, to be unveiled at the upcoming Goto Conference in Denmark, that’s designed to overcome JavaScript’s “fundamental flaws” by replacing it altogether.

So which is it? Will the Web development community continue to work to make JavaScript a first-class development platform, despite its failings? Or will it take the “nuclear option” and abandon it for greener pastures? The answer seems to be a little of both.

Google hedges its bets
Facts about Dart are scarce and will probably remain so until the Goto Conference. Most of what we know now comes from a leaked memo from November 2010 written by Google developer Mark S. Miller, titled “The Future of JavaScript.” Yet even that memo shows Google pursuing not one but two options for the future of the client-side Web.

In the memo, Miller described Dart as an “extremely high-risk” option, one that relies on convincing other browser vendors to make a “clean break” with JavaScript. The other option — Miller describes it as “relatively low-risk” — is to evolve JavaScript into a better language. What’s significant is that Miller’s memo advises Google not to choose between the two options, but to tackle both at the same time.

That’s exactly what Google has been doing. According to Alex Russell, a Google developer working on Chrome Frame, among other projects (in addition to being one of the founders of the Dojo Toolkit), “Google is absolutely committed to making JavaScript better, and we’re pushing hard to make it happen … And boy, does it need a push.”

The kinds of changes Russell advocates are not so much about raw application performance as improving developer productivity. JavaScript development patterns have evolved over the years, and as a result, its syntax is occasionally cumbersome in modern usage. For example, Russell would like to see a class keyword added to the language to make object-oriented code more explicit and legible. He also likes a proposed modules API that would create a standardized mechanism for creating JavaScript libraries.

JavaScript gets parallel
Evolving JavaScript isn’t as sexy an idea as starting from a clean slate, however, if for no other reason than it’s not something you can do in a vacuum. Russell contributes to the process as one of Google’s representatives on TC39, the ECMA technical committee responsible for standardizing the ECMAScript language, which forms the basis of JavaScript. Making improvements to an international standard isn’t easy, as some TC39 members learned when the committee abandoned plans for ECMAScript 4 in 2008.

Still, that collaborative process is important, because Google isn’t the only company with a stake in the future of client-side Web development. For example, Intel wants to allow Web applications to take better advantage of modern, multicore processor designs, which even Dart might not be able to do well.

This week, Intel gave developers a demo of what it has in mind. The chipmaker’s new JavaScript engine, code-named River Trail, introduces “parallel extensions for JavaScript,” which Intel engineer Stephan Herbut says will make JavaScript a high-performance option “even for more compute intensive applications like photo editing.” In addition to parallel processing, River Trail allows JavaScript to take advantage of vector-processing instructions found in modern chips. An experimental version of the engine is available now as a Firefox extension, downloadable from Github.

Google roots for the Web
With all this activity around JavaScript, it seems a little strange that Google would muddy the waters by throwing Dart into the mix. As Google’s Miller points out, “it will be a huge challenge to convince other browser vendors to rally around a new language.” New languages appear all the time, and few ever become successful. Google’s much-buzzed Go language, for example, hasn’t gained much traction outside the search giant’s offices since it was first unveiled in 2009.

Even if Dart has little chance of usurping JavaScript in the new term, however, it gives Google a tool to demonstrate what a “clean room” rewrite of JavaScript might look like. This in turn could give Google a louder voice in TC39 discussions, having developed a working prototype of some big ideas that might otherwise have been sidelined in committee.

But the most interesting part of Miller’s Dart memo is his rationale. As he sees it, the competition isn’t about Dart versus JavaScript or any other language, for that matter; it’s about nothing less than the Web versus “compelling alternative platforms” — platforms, he says, such as Apple’s iOS.

Increasingly, consumers have two ways to access the Internet and Web-based information services. Many still do it the traditional manner: through a Web browser. But a growing number of consumers are turning to smartphones as their primary means of accessing those services, and their window to the Web is not the mobile browser, but purpose-built smartphone apps.

The problem? Smartphone app platforms such as iOS tend to be closed, vertically integrated, and proprietary — precisely the opposite of the open, standards-based Web. If that’s a topic you care about, you should be paying very close attention to Dart, River Trail, and the ongoing evolution of JavaScript.

Source

Related Posts:

 

Comments are closed.