In this tutorial, I'll introduce you to Google's new web programming language, Dart, and explain why you should like it and what you need to know about it. Learn about this new language and form some opinions about it - will it really replace JavaScript?
What Is Dart?
Straight from the horse's mouth (which is located here):
Dart is a class-based, single-inheritance, pure object-oriented programming language. Dart is optionally typed … and supports reified generics and interfaces.
Dart programs may be statically checked. The static checker will report
some violations of the type rules, but such violations do not abort compilation
or preclude execution.
If that's a great, steaming pile of mumbo-jumbo to you, allow me to paraphrase the above.
Class-based: Dart expects you to use classes. While JavaScript is kinda-sorta class-based, you can't write Dart without writing classes.
Single-inheritance: Classes can extend other classes, but only one at a time. This is a common structure in Object-Oriented Programming. A rare few languages support multiple-inheritance, but the general consensus is that that causes more problems than it solves, so most OOP languages go for single-inheritance.
Object-oriented programming language: This statement is a bit redundant, given the "class-based" bit from before. But it is significant: Dart is OOP through and through. In fact, it's rather reminiscent of Java (not JavaScript; Java), which is also class-based.
Optionally typed: Most languages are either typed or not. JavaScript, for example, is not. When you define a variable, it will be untyped. You can set it to a String, then to a Number, and nobody will complain (well, I will). Moreover, you can call Array methods on that variable, and you won't have any problems until you actually run that line of code. In contrast, Java is typed. Every variable must be declared with a type, such as String or int. And when a variable is typed, you can't put a different type of value into it. And if you tried calling a method that doesn't exist on that type, the compiler will raise an error, letting you know your mistake before you run your code. C and its variants are other typed languages, while Ruby and Python are other untyped languages.
Optionally typed means, as you may now guess, that you have the option declaring a type for variables. It's as simple as this: you can leave the type off, and the compiler won't do any extra checking. If you supply a type, then the compiler will help you out with errors. ActionScript is an example of another optionally typed language.
This is rather clever move, one that is probably intended to help speed adoption. Dart programmers will most likely be JavaScript programmers making the leap. Providing support for an untyped language gives JavaScripters an easier learning curve, while providing a feature that many programmers insist is essential to serious programming, which can be picked up at a later time.
Reified generics: Generics are a language feature that allow you to type the elements of a collection. For example, an Array in JavaScript cannot guarantee that the objects it contains are any specific type (aside from the fact that JavaScript isn't a typed language). However, generics allow you to specify that every item in an Array - or any other collection type - must be of a certain type, perhaps a String. Thus if you try to insert a Number into the Array, you can get warnings. Reified generics go an extra step and allow this type safety past the compiler. Type integrity at runtime is preserved.
Interfaces: An interface is a handy Object-Oriented technique. It defines a type without defining functionality. It's uses are hard to sum up in a sentence or ten, suffice it to say that they are integral to advanced (and clean) Object-Oriented Programming techniques (namely design patterns). Once you grok interfaces, you'll lament the lack of them in other languages.
Statically checked: This goes back to the typing thing. When typing is in use, a variable with a type is considered "statically typed," and as such the type can't be changed once it's been declared. This allows the compiler (or "static checker") to make assumptions about your intentions with your code; that is, if you declare a variable as a String, then you shouldn't try calling changeTimeZone on it. If you did (maybe you typed in what you thought was that variable holding the Date object), then the compiler can alert you to the error without having to run the code.
So What Is Dart Really?
Yes, I had to provide the "official" explanation of Dart. But that may or may not satisfy you. Here's what Dart is, with the typical web developer in mind.
Dart is Google's replacement for JavaScript. It was announced in October of 2011, and the general intention is to provide the same tools that JavaScript does, only as power tools. As explained in the previous step, it has a lot of Object-Oriented features that the typical JavaScript programmer will be unfamiliar. But most programmers who are familiar with these features will readily advocate them as being essential for serious development.
In short, Google feels that JavaScript isn't up for the task of being a "real" programming language, given the amount of heavy lifting it's been doing since the iPhone shot a hole in Flash's zeppelin.
Google's hope is that Dart will be supported natively by all major browsers in the long term. That obviously isn't happening right now, given that Dart itself is still in early-release mode, and we can't expect Apple, Microsoft, or Mozilla to be jumping on board yet. However, what makes Dart worth looking at now is that Google has provided a compiler to convert Dart code into regular JavaScript.
Personally, this is something I've been longing for since turning to JavaScript, coming from ActionScript. Say what you will about Flash (and rest assured, I've probably said it, too), but ActionScript 3 is a good language. Going from advanced AS3 to JavaScript has been proven to cause swearing. I have actually been toying with my own JavaScript compiler (I did not get very far and am quite happy to abandon the project), and I wanted something that could at least let me develop with some niceties, like real classes, interfaces, and types, even if it compiled into untyped, prototypical JavaScript. The compile process can catch some errors before you run the project, which is a huge time saver.
So, whether or not Google gets its way, it is certainly possible to write Dart projects for the web today, and we'll do just that by the end of this tutorial. Hopefully, along the way, I'll convince you that Dart is actually pretty promising.
What's Wrong With Dart?
Now that you're all excited over "JavaScript 2.0," now for the hard truth. Only Google has plans to incorporate support for Dart into its browser. No one else has expressed interest in that. In fact, quite a few statements have been made against Dart, or at least the idea of supporting Dart natively, from the browser makers themselves.
And while Dart projects can compile into JavaScript, there's necessarily some overhead in this process. The Dart compiler isn't quite like the CoffeeScript compiler, which is more of a one-to-one process. Dart is its own language, with libraries and such, and when compiling into JavaScript it consequently compiles extra library code into the resulting JavaScript. This currently weighs more than a library such as jQuery. This is bound to change as the Dart team finesses the compilation, but basically it's a jQuery-ish library that is required to normalize browser differences, and also some extra "sugar" to help make JavaScript a little more honest about its dynamic nature. This kind of extra weight isn't terrible, but if you're building a simple UI widget for a mobile site, then maybe Dart isn't the best choice. It will shine more with larger-scale web applications that rely on significant JavaScript.
Lastly, Dart is currently in development. That's exciting, and it's not something "wrong" with Dart per se, but if you start developing in Dart now, there's a certain chance that the API will change, or that things won't be documented fully or correctly, and the amount of information on the web is less than, say, the amount you can find about jQuery. It's bleeding edge, and that may not be for you, or for a given project.
What's Awesome About Dart?
At the same time, it's bleeding edge, and that's awesome. Investing in a little time now to learn Dart could put in a nice place once Dart is more stable. If you get involved now, you even have the opportunity to help shape the language. The Dart mailing list on Google Groups often has some back-and-forth between people suggesting ideas and Google engineers responding to that idea. Often user-contributed ideas are considered and it's not uncommon to see them incorporated.
I've already discussed the advantages of a typed, object-oriented language, and it probably goes without saying that those traits are also awesome.
Dart is also rather reminiscent of Java, and that should be awesome if you're more of a Java (or C) programmer looking to get into web development. Dart should provide a better transition into that world than JavaScript would.
Lastly, Dart is not just about a JavaScript competitor. It's a whole new language, and it's poised to run anywhere. It's being used on the server side, a la Node.js, and promises to be another widespread tool, like Ruby or Python.
Should You Care?
This is, of course, a loaded question, and I'd be inviting a comment-based Inquisition no matter how I answer. But answer I shall.
You'll probably already care, or not care, depending on how much you're bothered by Dart's problems, or excited by Dart's advantages. The previous two steps give you plenty of information the lead you to your own conclusion.
If you're the type of person whose idea of programming JavaScript is to search the web for jQuery plugins and install them on your HTML page, then Dart probably isn't going to offer you much excitement. Feel free to not care. And let me save you a bunch of time and reveal that I base the rest of this tutorial on the assumption that the reader cares, at least enough to explore.
However, if you're the type of front-end developer that actually believes in object-oriented JavaScript, tries to build error-catching into your scripts, and tends to write more JavaScript than HTML, then you may be a redneck someone who cares about good programming, regardless of the language or platform, in which case you might care about Dart. You at least owe it to yourself to try it out.
In my opinion, Dart shows a lot of promise and has a place in web programming. But I don't think it's going to replace or even really offset JavaScript's dominion over scripting on HTML pages. I think it will find a place with the more serious web applications, but unless the browser makers (other than Google) agree to build in a Dart VM - which I don't think likely - Dart's destiny is relegated to Chrome experiments and large-scale web apps. Simple scripting tasks, like a dash of interactivity on an otherwise static page, will not greatly benefit from Dart.
Having said that, I feel it's always worth learning about new stuff. You may learn that the new thing isn't worth your time, but you should formulate that opinion on your own, through experience. We'll provide some experience in this tutorial, so if you're feeling adventurous, get ready for Dart.
Conclusion
This brief discussion of Dart has hopefully sparked your interest in this new language that may or may not take the web by storm. If you'd like to try it out, take a look at my Facebook-exclusive tutorial that will get your hands dirty with a simple Dart project.
(If you're not on Facebook, don't worry. The tutorial will be on the main Activetuts+ site eventually, and we have plenty more Dart content lined up in the mean time.)
Thanks for reading! Share your opinions about Dart in the comments.
