A web application is always a dialog between a client-browser requesting a page and the server responding with processing and delivering the page and its resources (such as pictures and other media). In the technology of the early dynamic web (the 90s of the previous century, extending even until today), the server performed most of the work: compiling a page, executing the code, fetching data from a data store, inserting the data in the page templates, and in the end, producing a stream of HTML and JavaScript, which was delivered to the browser. The client digested this stream, rendering the HTML into a browser screen while executing some JavaScript, so processing on the client side was minimal. The whole range of applications using Perl, Python, Ruby, PHP, JSP (Java Server Pages), and ASP.NET follows this principle. It is obvious that the heavy server loads impact negatively the number of clients that could be served as well as the response time in these applications. This mismatch is even clearer when we realize that the power of the client platforms (with their multicore processors and large memories) is heavily underutilized in this model.

The plugin model, within which the browser started specialized software (such as the Adobe Flash Player) to handle all kinds of media and other resources, partly tipped the balance to the client side. Following this trend, a whole range of technologies for developing Rich Internet applications (RIA) were developed that executed application code in the browser at the client side instead, ranging from Java applets around 1995 to Microsoft Active X Objects, culminating in the Adobe Flex and Microsoft Silverlight frameworks. While they have their merits, it is clear that they are more like a parasite in the browser; a virtual machine that executes, for example, ActionScript or C# code that is alien to the browser environment.

Empowering the client is the way to go, but this should better be done with software technology intimately linked to the browser itself: HTML and JavaScript. In order to eliminate the need for alien plugins, the power of HTML needs to be enlarged. This is precisely what is achieved with HTML5, for example, with its <audio> and <video> tags. JavaScript is the ubiquitous language of the web and it can, like Dart, request/send data from/to the server without blocking the user experience through technologies such as Ajax. However, flexible and dynamic as JavaScript may be, today it is also often called the assembly language for the web.

Why is this? JavaScript was, from the beginning, not designed to be a robust programming language, despite its name that suggests an affiliation with Java. It was designed to be a simple interpreted language, which could be used by nonprofessional programmers and that would be complemented by Java for more serious work. However, Java went away to prosper on the server and JavaScript invaded the browser space. Today, JS is being used to develop big and complex web applications, with server components such as Node.js, far beyond the original purpose of this language. Most people who have worked on a large client-side web application written entirely in JS will sooner or later come to the conclusion that its use in these applications is overstretched and the language was not meant to build this kind of software.

Understanding program structure is crucial in large, complex applications: this makes code maintenance, navigating in code, debugging, and refactoring easier. Unfortunately, JS code is hard to reason about, because there is almost no declarative syntax and it is very hard to detect dependencies between different scripts that can appear in one web page. JavaScript is also very permissive: almost anything (spelling mistakes, wrong types, and so on) is tolerated, making it hard to find errors and unpredictable results. Furthermore, JS allows you to change the way built-in core objects function, a practice often called monkey patching (for a reason!). Would you trust a language in which the following statement is true in its entirety and all of its comparisons?

10.0 == '10' == new Boolean(true) == '1'

Because of this sometimes undefined nature of JS, its performance is often very unpredictable, so building high performance web apps in it is tricky.

Google is the web firm par excellence: its revenue model is entirely based on its massive web applications, such as Gmail (some half a million lines of JS), Google Docs, Google Maps, and Google Search. So, it is no wonder that these teams encountered the difficulties of building a large JS application and strived for a better platform. Due to the fundamental flaws of JS and its slow evolution, something better was needed. A first attempt was Google Web Toolkit (GWT), where the development was done in Java, which was then compiled to JS. Although it was reasonably successful because it enabled a structured and tooled approach to application building, it was clear that the use of Java is somewhat awkward in a web environment. Thus, arose the idea for Dart: a kind of hybrid platform between the dynamic nature of JS and the structured and toolable languages such as Java and C#. In order for Dart to run in all modern web browsers like GWT, it must be compiled to JS. Google has provided a special build of Chromium, called Dartium, which provides a Dart VM to execute Dart code on the fly without any compilation step. This is useful for testing in Dart Editor (Chrome or any other browser can be used to test the JS version of your Dart app).

This way, Dart can get a better performance profile than JS (remember that the same experts who developed the V8 JS VM are forging Dart, see http://www.dartlang.org/performance/) and, at the same time, maintain the simple and rapid development process of JS in the browser: the edit code, save, and refresh browser cycle to view the latest version, rather than having to stop, recompile, and run for every little change. Dart delivers high performance on all the modern web browsers and environments ranging from small handheld devices to server-side execution. When it runs on its own VM, Dart is faster than JS (currently, around 1.5 times the performance of JS). Moreover, through snapshotting (a mechanism inherited from Smalltalk), a Dart app has a fast application startup time in contrast to JS, where all the source code has to be interpreted or compiled from the source.

Dart executes in the browser after having been compiled to JS, so Dart runs everywhere JS does. The Dart VM can also run standalone on a client or server.

Another big advantage compared with GWT is that Dart is much better integrated with the web page and like JS can directly manipulate the page elements and the document structure, that is, the Document Object Model (DOM). Like JS, it has intimate access to the new HTML5 APIs, for example, drawing with the canvas, playing audio and video clips, or using the new local storage possibilities. Following the RIA model explained earlier, Dart executes the full application code in the browser, requesting data from the server and rebuilding the page user interface when needed. Because Dart wants to be a part of the web, not just sit on the top, the team has also built a Dart to JavaScript interop layer to call JavaScript from Dart and the other way around. Together with its out-of-browser and server capabilities, Dart is also conceived to build complex, large-scale web applications. This can be clearly seen from its object-oriented nature, and Dart code is built with code clarity and structure (using libraries and packages) in mind. To summarize it: