Programmer and project leader Lars Bak detailed the project in a talk today at the Goto conference conference today in Denmark and in a blog post. Dart is geared for everything from small, unstructured projects to large, complicated efforts--Gmail and Google Docs, for example.
"If we want to focus on making the Web better over time, we have to innovate," including with new programming languages, Bak said in an interview today.
Google also unveiled a Dart language site including open-source tools for writing Dart programs, code samples and tutorials, supporting libraries of supporting software, the Dart language specification, and forums for discussion.
A month ago, details about Dart raised some hackles about Google's Web technology tactics when an 2010 internal memo about it, then called Dash, surfaced on a mailing list. One tidbit from that memo is that Dart's goal is "to replace JavaScript as the lingua franca of Web development."
Google is a big company, though, and others within the company remain strong JavaScript adherents. And Bak, while not denying Google has big ambitions, was quick to proclaim JavaScript alive and well.
"It's not going to replace JavaScript," Bak said. "JavaScript is is a cornerstone of the Web today, and it will continue to be for a long, long time."
Bak bristled at some of complaints about Google's approach to creating Dart in-house and not through a more collaborative approach.
"I don't buy the argument that before writing any line of code or designing any features, you put it in a standards committee, because that would just be a lot of screaming," Bak said. "You have to have coherent design before you start adopting Dart as a standard."
Making a standard is a goal, though. "It will be fairly lonely to create a standards committee when here's only us in it. We first have to get the backing of other partners before we can make a standard that's useful," he said.
Google is releasing Dart now for the next step in its maturation: outside feedback and participation. "We hope the other browser vendors will be excited," Bak said, adding that today is the first that Google has shared details about Dart with them or others.
Google is evaluating the best way to integrate Dart directly into its Chrome browser, something Bak is keen on. One reason: it will enable a "snapshotting" technology that dramatically improves a Web app's start-up time. Snapshotting involves taking an application and "serializing" it into a single block of data.
Dart's design goals are:
Create a structured yet flexible language for Web programming.
Make Dart feel familiar and natural to programmers and thus easy to learn.
Ensure that Dart delivers high performance on all modern Web browsers and environments ranging from small handheld devices to server-side execution.
Dart targets a wide range of development scenarios: from a one-person project without much structure to a large-scale project needing formal types in the code to state programmer intent. To support this wide range of projects, Dart has optional types; this means you can start coding without types and add them later as needed. We believe Dart will be great for writing large web applications.
Dart programs will be able to run within a Dart virtual machine--essentially a layer of software that acts as a computer to execute programs. They'll also be able to run using a compiler that translates Dart code into JavaScript code for browsers that don't support Dart, Bak said.
Google's Chrome browser has served as a vehicle to get the company's technology such as WebM and SPDY useful for at least a portion of Web users. Though the 2010 Dart/Dash memo said Google planned build Dart support into Chrome, Bak was cautious about making any definite statements beyond saying browser integration brings benefits. It's notable, though, that Bak led development of Chrome's V8 JavaScript engine, so he's hardly a stranger to the Chrome team or to the challenges of improving Web-app speed.
Building Dart into Chrome could let Google build Dart versions of its advanced Web apps that--if the language lives up to its billing--could be better than those Web apps today.
"Google has a lot fairly big Web applications. That includes Gmail and Docs. I hope many of these apps will be converted into Dart," Bak said--but cautioned that was his personal option, not an explicit plan.
Introducing new programming languages is tough. Though many hope that computing can improve by reforming or replacing languages, the incumbent power of existing languages is strong. Educating thousands or millions of programmers, building developer tools, and creating supporting libraries of code all can take years. As newer languages such as Java, JavaScript, and C# attest, though, it is possible.
Google also is trying to gain a foothold for Go, a programming language geared more for native software that today would most likely be written with C or C++.
Dart is designed to address several shortcomings Google sees with Web programming today, according to the Dart technical overview:
Small scripts often evolve into large web applications with no apparent structure--they're hard to debug and difficult to maintain. In addition, these monolithic apps can't be split up so that different teams can work on them independently. It's difficult to be productive when a Web application gets large.
Scripting languages are popular because their lightweight nature makes it easy to write code quickly. Generally, the contracts with other parts of an application are conveyed in comments rather than in the language structure itself. As a result, it's difficult for someone other than the author to read and maintain a particular piece of code.
With existing languages, the developer is forced to make a choice between static and dynamic languages. Traditional static languages require heavyweight toolchains and a coding style that can feel inflexible and overly constrained.
Developers have not been able to create homogeneous systems that encompass both client and server, except for a few cases such as Node.js and Google Web Toolkit (GWT).
Different languages and formats entail context switches that are cumbersome and add complexity to the coding process.
