Dart The JavaScript Alternative

Google unveils Dart, its new programming language for building web applications and it’s a new platform developed with simplicity, efficiency, and scalability in mind, combining powerful new language features with familiar language constructs into easy to define code. Google says that its new language will assist developers by helping create a structured yet flexible language for web programming for and ensure that Dart delivers high performance on all modern web browsers and also environments ranging from small handheld devices to server-side execution………………..


Programmer and project leader Lars Bak detailed the project in a talk at the Goto conference in Denmark and in a blog post, Dart is geared for everything from small, unstructured projects to large, complicated efforts and Google also unveiled a Dart language site that includes open-source tools for writing Dart programs, code samples, and tutorials; 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 a 2010 internal memo about Dart, then called Dash, surfaced on a mailing list. One tidbit from that memo was that Dart was designed to replace JavaScript as the lingua franca of Web development. Google is a big company 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 a cornerstone of the Web today, and it will continue to be for a long, long time.” Bak bristled at some of the 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.” . “It will be fairly lonely to create a standards committee when there’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. 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 startup time. Snapshotting involves taking an application and serializing it into a single block of data. In one test of snapshotting, a 55,000-line Dart program loaded in 60 milliseconds compared to 640 milliseconds without it, Bak said. A conventional JavaScript program would load in comparable time as Dart without snapshotting. Bak‘s quick description of Dart‘s design goals:

  • 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 and they’ll also be able to run using a compiler that translates Dart code into JavaScript code for browsers that don’t support Dart. 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 and 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. 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. 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, 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.



 [ttjad keyword=”general”]

Leave a Reply