Google declined to provide further details about Dart in advance of the official announcement, scheduled to be delivered at the GOTO conference in October. But a document describing Google's position was published last November. The post, from Mark S. Miller, a Google engineer and designer of the E and Caja programming languages, who also serves as a representative to the ECMAScript committee, was sent to an internal Google developer mailing list. It was co-authored by Miller and over a dozen other Google engineers, including Lars Bak, who is scheduled to introduce Dart next month.
The executive summary notes that JavaScript "has fundamental flaws that cannot be fixed merely by evolving the language" and describes a two-pronged strategy to address the situation.
Leading organizations are embracing business analytics to identify their most profitable customers and trump rivals.
Review 8 business analytics essentials and learn how to get started.
Google plans to continue to participate in the development of Harmony, a future version of ECMAScript that's being spearheaded by the ECMA T39 standards group.
At the same time, Google plans to release and promote Dart, formerly called Dash. "The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of Web development on the open Web platform," Miller's post states.
The first Web application written using Dart that we're likely to see from Google is a cloud IDE known by the codename "Brightly," according to Miller's summary. Presumably, Brightly is based on the code for Writely, the online document creation app that Google acquired in 2006 and later turned into Google Docs.
IDEs, or integrated development environments, are tricked-out text editors for writing code, with tools for compiling, debugging, and the like. Mozilla has offered a Web-based IDE called Bespin since 2009, but Google, for all its promotion of Web-based apps, has yet to release one.
Dart has been designed with three main goals: performance, developer usability, and support for tooling. Performance is obviously necessary: No one would want to use a programming language that produces slow, inefficient apps. Developer usability is necessary to match the usability of JavaScript, which is popular with programmers of varying abilities. If Google creates a language that's too complicated, it will remain a niche tool and have only marginal influence on Web development. Support for tooling is necessary because large projects, such as Google Apps, often require special extensions that support code refactoring or locating subroutine calls.
Miller's summary also notes that security is important, though less so than the three main goals: "Dash is also designed to be securable, where that ability does not seriously conflict with the three main goals," the document says.
Brendan Eich, creator of JavaScript and Mozilla CTO, said in a blog post last month that while Google would put "a death mark" on JavaScript, the existing approach driven by standards committees is sufficient to direct the language's evolution. He argues that the inherent slowness of community-driven standards is a necessary price to avoid fragmentation and to maintain interoperability.
"[M]any Googlers, especially V8 principals, do not like JavaScript and don't believe it can evolve 'in time' (whatever that might mean--and Google of course influences JavaScript evolution directly, so they can put a finger on the scale here)," Eich wrote. "They're wrong, and I'm glad that at least some of the folks at Google working in TC39 actually believe in JavaScript--specifically its ability to evolve soon enough and well enough to enable both more predictable performance and programming in the large."
Among the JavaScript supporters cited by Eich is Google Chrome Frame developer Alex Russell, who published a blog post to address concerns that Google has it in for JavaScript. "Google is big, can do many things at once, and often isn't of one mind," wrote Russell. "What we do agree on is that we're trying to make things better the best we know how. Anyone who watches Google long enough should anticipate that we often have different ideas about what that means. For my part, then, consider me and my team to be committed JavaScript partisans for as long as we think we can make a difference."
To those disinterested in technical plumbing, it may seem unimportant whether or not JavaScript remains central to Web apps and Web development. But to Google, it's a critical issue. Google has staked its future on the Web, but the Dart summary suggests that Google's major Web applications "are struggling against the platform" and could be eclipsed by native mobile applications, in particular those controlled by Apple.
"The emergence of compelling alternative platforms like iOS has meant that the Web platform must compete on its merits, not just its reach," the document states. "Javascript as it exists today will likely not be a viable solution long-term. Something must change."
While Russell as a confessed JavaScript enthusiast sees things differently, he too recognizes some of the issues facing the Web. "[T]he language isn't the problem, the platform is," he wrote. "The only thing that's going to replace the Web as universal platform is the next version of the Web."
The question facing Google is whether it can get to the next version of the Web, with or without the open Web community, before enough people decide that building on other platforms represents a more appealing way to create online services.
Attend Enterprise 2.0 Santa Clara, Nov. 14-17, 2011, and learn how to drive business value with collaboration, with an emphasis on how real customers are using social software to enable more productive workforces and to be more responsive and engaged with customers and business partners. Register today and save 30% off conference passes, or get a free expo pass with priority code CPHCES02. Find out more and register.
