A web application is always a dialog between the client's 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 that 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, in which the browser started specialized software (such as the Adobe Flash Player) for handling 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 and 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; for example, a virtual machine that executes code, such as ActionScript or C#, 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, and 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, as with Dart, request/send data from/to the server without blocking the user experience through technologies such as Ajax. But 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 that could be used by nonprofessional programmers and that would be complemented by Java for more serious work. But Java went away to prosper on the server, and JavaScript (JS for short) 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 that kind of software.

Understanding program structure is crucial in large, complex applications: this makes code maintenance, navigating in code, debugging, and refactoring easier. But 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 development was done in Java, which was then compiled to JS. Although reasonably successful because it enabled a structured and tooled approach to application building, again 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, as for GWT, it must be compiled to JS. Google has provided a special build of Chromium, called Dartium, that provides a Dart virtual machine (VM) to execute Dart code on-the-fly without any compilation step (this VM will soon be incorporated into Chrome; for the time being Chrome can be used to test the JS version of your Dart app).

That 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 https://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 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 (in Dart v1.0 around two 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 source.

Dart can execute in the browser, either in its own Dart VM (only in Chrome for the moment) or 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 mentioned 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 part of the web, not just sit on 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 for building 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:

The Dart web model