Can Google Dart replace JavaScript?

As a front-end developer, the prospect of putting down some thoughts about Google Dart got me both excited and intrigued. A new programming language to replace JavaScript? Even coming from Google this seems a bit abrupt, especially given their bad track record with commitment. Or is it? Could Dart be the general solution that many developers have been waiting for? Let’s look at some language basics and try to gain some perspective on Dart and Google’s position in regards to JavaScript and the future of web development as we know it.

Language overview

“Hmm… looks a lot like Java” is the first thing that pops into your mind when looking at the sample code. Dart runs in a virtual machine but Google also provides a cross compiler to JavaScript for compatibility with non-Dart browsers. The compiler is accessible both from the Dart Editor, whose binaries have recently been launched, or by using some command-line tools. There are plans to include the virtual machine in Chrome’s future releases as well.

Its syntax is fairly simple and familiar, rather boring, both a plus and a minus – natural, easy to pick up and with a fast learning curve but yet another programming language with slight changes to syntax, making it difficult to remember particular details. The similarities to Java and C# are one of the factors that created a full-fledged controversy among developers even before the official preview (GOTO conference, October 10th 2011). The changes in syntax weren’t necessarily considered an improvement.

Dart is object-oriented, single inheritance, class and interface-based – a class can implement multiple interfaces, but it only inherits from a single superclass – thus rewriting JavaScript’s prototypal inheritance. Is switching back to classical inheritance a smart move? As Douglas Crockford – the creator of JSLint and developer of JSON – concluded, in JavaScript’s case prototypal inheritance is more efficient and has more expressive power than classical one.

There’s just one constructor for the classes but additional named constructors can be added with a method name prefixed by the class name:

Another interesting feature is that one can add factory constructors making it easy to explicitly return an instance of the class. This can prove very useful for recycling and returning something from the cache. In the example below no new Symbol object is created when invoking it the second time around with the same parameter. Instead, the cached instance is returned:

The visibility is simple, using just private and public, with no real private, just a naming convention: private variables or classes are prefixed with an underscore.

It’s optionally typed (performance increase, also helps with simple prototyping) and single threaded. Similar to JavaScript’s workers, Dart solves concurrency issues through isolates, an actor-like concurrency model. As the name states there is no shared state, isolates accept and dispatch messages:

Some syntactic sugar is also available, allowing fields, getters and setters to be indistinguishable, so fields don’t have to be hidden behind getters and setters. When one just wants to return a value (take for example getters) a fat arrow => is used instead of the full curly-braced function body. Class Rectangle below has four actual fields and two more fields (right and bottom) defined through getters and setters. As you can see there is no notable difference between fields and getters/setters:

Dart also supports interpolated strings allowing both ${name} or $name. A somewhat funny minus in syntax – agreed upon by many developers – is that it requires semicolons as mandatory end of line markers, otherwise the compiler will prompt an error that will stop the execution flow.

Dart is open-source

Events, on the other hand, have been so far left out. But given that Dart is still in an early stage of development this may come as understandable. The team does accept and encourage submissions for feature requests and contributions. And why wouldn’t they, since community support is crucial. Developers need to start identifying with their ideas and philosophy as large-scale adoption is what ultimately will drive the language to maturity. The compiler to JavaScript is a nifty “trick” so developers can start committing to the language before browsers have a built-in native Dart virtual machine. The question is how many competitors will want to compel to a Google designed alternative.

Although according to recent statements “the competition is not JavaScript, but fragmented mobile platforms”, Google has been at JavaScript’s throat for some time now. In a leaked memo last year they were on a clear mission to completely replace JavaScript with a more versatile and well-thought language in terms of performance. The motivation behind this is that a major improvement in JavaScript syntax would break backwards compatibility.

Where does JavaScript stand?

JavaScript is a great option for low to mid-scale web development and it’s excellent for mobile applications. However, when it comes to very scalable solutions with complex front-ends, highly structured code is not one of JavaScript’s core strengths, driving many developers to turn to alternative solutions (such as Google Web Toolkit). On the other hand, Alex Russell – Google Chrome Frame developer and supporter of improving JavaScript rather than replacing it – steps in with another theory: “the language isn’t the problem, the platform is”. In one of his blog posts, while agreeing that JavaScript is “painful in large quantities” he points to these amounts as being a direct consequence of the “DOM, CSS and HTML standards letting you down”:

Any language wired up to the browser today is subject to the same fate, and the insane reality is that these things are specified under different roofs in processes that aren’t subject to the popular will of web developers. […] The only thing that’s going to replace the web as universal platform is the next version of the web. Those of us working on Chrome believe that to the core and feel a deep urge to make things better faster.

Alex Russell, Google engineer

While I know web developers love to get under the hood with JavaScript, HTML and CSS I bet there are tons of other developers trying to avoid this exact same thing. But the increasing popularity of Node.js reveals that at least there’s an interest in using a common language for both client and server-side.

Why Dart?

It seems that even Google is fighting on several fronts at the same time. So can anyone blame developers for wanting to give it a little more time before committing? But according to Google engineer Bob Nystrom who is involved in the project, they’re dead serious about Dart: “Google’s already put more resources on it than I was expecting. Gilad (Bracha) doesn’t f**k around, and he came to Google to work on Dart. I don’t think he’d be happy if it fizzled out”.

Happy or not, given that JavaScript is so widely spread and popular that even Microsoft decided to include it together with HTML5 in Windows 8 for application development, two valid questions pop up. Why Dart? We’ve already answered this one: rapid prototyping to production-ready code and the appeal of having an actual web language that encapsulates both client and server. What’s the real motivation behind going through the trouble of yet another new language? Well, if they succeed to stick to their initial commitments without getting lost on the way (which has been known to happen) and get sufficient followers on board, Google may not need acceptance or cooperation from its rivals.

So, will this be the hit under the belt that will dethrone JavaScript as the open web browser programming language? Time will tell.