From

Thank you

Sorry

Demand for increasingly complex Web apps is steadily growing, but JavaScript is too fundamentally flawed to keep up, at least to Google's taste. Rather than waiting for major overhauls to JavaScript (aka ECMAScript), the search and software giant has been working on an open JavaScript alternative dubbed Dart.

Google's plan is to continue contributing to the development of JavaScript while also pushing Dart, with the long-term goal of having its language usurp JavaScript's position as the lingua franca of open Web development.

Google has not officially said much about Dart, though two Googlers will give a keynote presentation titled "Dart, a New Programming Language for Structured Web Programming" at the GOTO Aarhaus 2011 conference next month. However, in a purportedly leaked internal memo dated Nov. 16, 2010, Google's Mark Miller went into some detail about Dart (apparently called Dash at the time).

In the memo, Miller describes JavaScript as having "fundamental flaws that cannot be fixed by merely evolving the language" and outlines a two-pronged approach for its JavaScript strategy. Prong one entails continuing to work in conjunction with the ECMAScript standards body to drive JavaScript's evolution. The second prong, which Miller deemed a "high-risk, high-reward" strategy, is to develop a new language "that aims to maintain the dynamic nature of JavaScript but have a better performance profile and be amenable to tooling for large projects."

Google envisions Dart "leapfrogging" JavaScript, becoming the open standard of choice for Web developers, and ideally enjoying support from the other browser makers. In his email, Miller did indicate part of Google's strategy would be to offer a cross compiler for browsers that don't natively support the language.

The problem with JavaScript, according to Miller, is that it cannot be tooled and has inherent performance problems, thus rendering it inadequate for complex browser-based apps. "The cyclone of innovation is increasingly moving off the Web onto iOS and other closed platforms," Miller wrote. "The Web development community has been backed into using large amounts of JavaScript largely to work around the deficiencies in the platform.... Even smaller-scale apps written by hobbyist developers have to navigate a confusing labyrinth of frameworks and incompatible design patterns."

Among Google's aspirations for Dart, Miller said, is that should be possible to create virtual machines that do not have the performance issues seen in JavaScript VMs. It's designed to mirror the "dynamic, easy-to-get-started, no compile nature of JavaScript." Further, it's designed "to be more easily tooled for large-scale projects that require code-comprehension features, such as refactoring and finding call-sites," but it also gives small-scale developers the option of using just a text editor for app building.

Google's undertaking is not without its challenges. From a technical standpoint, introducing a new language into the Web development mix requires converting developers to the cause, which not only means making Dart a compelling, viable language for creating apps, but also ensuring those apps will run in browsers that aren't Dart-friendly. "Developers focusing on all browsers will have to make use of the Dart cross compiler to target other browsers, and, depending on the success of the evangelizing effort, might have to wait years for other browsers to implement native support for Dart," Miller wrote.

The other related challenge: Getting the other browser vendors to embrace Dart. Google's strategy here, according to Miller, is to "make an absolutely fantastic VM/language and development environment and build great apps that fully leverage it," thus convincing other companies to follow suit.

Some companies -- along with the tech world at large -- may take issues with what might look like Google circumventing the standards process at the expense of JavaScript for its own personal gain. Miller defended Google's actions: "We fully intend to cooperate fully with standards processes -- the problem is that the current standard processes are limited to JavaScript, which is not viable in the long term. Any effort with the historic baggage that JavaScript has will be extremely limited. We need to make a clean break, make progress, and then engage the community."