In the summer of 2013 I wrote a blog “How Serious is Google About Dart“. It’s January of 2015, and I’d like to give you an update from the trenches. Our team has developed and deployed in prod a beta version of the application that helps consumers with finding and rating insurance agents and getting quotes online. The front end of EasyInsure is written in Dart language.
Before introducing the Dart ecosystem, I’d like to give you a little background about our prior experience in developing Web applications (I work for Farata Systems).
On the server side we always use Java and have no plans to switch to any other technology. After spending many years developing the front end with Adobe Flex framework and ActionScript programming language we got spoiled by this super-productive environment. After the mankind led by Apple killed Flash Player, we started to look for an alternative.
Back in 2005 we’ve abandoned JavaScript, but decided to give it another chance. Things were a little better this time. JavaScript has better IDEs and browser-based tools for developers. The number of JavaScript frameworks and libraries went down from two hundred to a couple of dozens, which is a good thing.
Still, the productivity of our developers dropped substantially in JavaScript comparing to what we’ve seen with Flex. I can’t give you exact numbers, but it looks like developing in Flex is at least three times faster than with any JavaScript framework we tried (ExtJS,AngularJS, and lots of small libraries). When I say JavaScript, I mean its version based on the ECMAScript 5 specification.
In 2013 we got familiar with the Google Dart language. The syntax of the language was pretty appealing and easy to understand. It felt like Java, but a little more modern. Dart is optionally-typed language. You can run the compiled Dart code in DartVM, but no browser except Dartium support it, and it’ll remain this way. Generating JavaScript from the Dart code is a realistic way of delivering Dart applications for any browser today.
But any language without the proper tooling is doomed, and this is what makes Dart stand out. Here’s the list of tools available for Dart Developers:
1. The IDEs: Dart Editor from Google and WebStorm from JetBrains. We use Dart Editor because it’s smarter than WebStorm today.
2. dart2js is a Dart-to-JavaScript compiler and a tree-shaker, which removes the unused code from the third-party libraries used in the application.
3. pub is a dependency management, development server and build tool.
4. gulp is a task manager. It’s an analog of Grunt or Gradle. We use gulp to prepare optimized ready-to-deploy application from the code produced by the pub build. In particular, we do the gzip compression there.
5. Dartium is a Web Browser for developers. Google Chrome is based on the open source project called Chromium, and Dartium is Chromium with built-in DartVM. We use it for launching and debugging applications.
6. Dump-Info Visualizer – allows to inspect the generated JavaScript. It gives a very convenient breakdown by the application’s JavaScript code so we can analyze file sizes and identify the scripts to be optimized.
7. Observatory is Dart profiler (we haven’t used it yet).
8. AngularDart framework. It’s a port of a popular JavaScript framework AngularJS.
The above list is pretty impressive, isn’t it? As Google Dart evangelists say, “Batteries included”.
Developing JavaScript applications in Dart is definitely more productive. I do recommend you to start learning Dart and develop the front end of your Web applications in this developer-friendly environment. Having said that, I’d like to warn you that there are no jobs on dice.com that require programmers with Dart skills. Oops… Moreover, three years from now your Dart skills may be in even lesser demand in the enterprise world. Oops…
After these two oopses half of the readers may lose interest to Dart, because it doesn’t meet their career objectives. For those of you who continue reading I’ll explain why IMHO you still should learn and use Dart today. Because the final release of ECMAScript 6 (ES6) is around the corner. Because this spec already gave birth to JavaScript 6 (it’s a boy)!
By the way, do you know why there is no enterprise jobs that require Dart skills? Because enterprise architects will fight hard against any language that runs in a browser unless it’s called JavaScript. Back in 2007 Adobe sales force did a great job by pushing Flex framework into enterprises. Enterprise architects were fighting hard against Flex then, and they will do the same with Dart. But Google is not Adobe. They won’t fight for Dart in enterprises.
But promoting Dart in your organization can be easy. Just explain your enterprise architects that programming in Dart is just a smart way of preparing the enterprise to embrace the bright JavaScript 6 future with classes,modules, promise, fast image rendering, et al. The code that you’ll be writing in Dart during the next 12-18 months will need to be converted into EcmaScript 6 as soon as several major Web browsers will start supporting it.
The syntax of Dart and ES6 are literally the same. Google invested time and resources in creation of IDE for Dart, and now they’re working on the IDE for ES6. Even manual refactoring of the code from Dart to ES6 shouldn’t be a major project, but I’m sure this process will be automated soon.
As a matter of fact, some browsers already started supporting ES6. See for yourself:
I’d like to draw your attention to the greenest column on the right side. Yes, it’s the successor of the today’s funniest browser known as IE! Microsoft calls it Spartan, and promises that Spartan will be a lightweight browser that feels like Chrome or Firefox. You just can’t go wrong with such a name.
Spartan already supports ES6. Courageous early adopters can start developing code in ES6 now, than compile the code down to ES5 with Traceur compiler and deploy it in any today’s browser. But if you want to work in a tools-rich environment just develop your single-page applications in Dart and AngularDart. Give the ES6 some time to mature. The work on ES7 is being done too, and it looks very interesting and promising.
I’ve created a New York City Dart Meetup with a hope to get some Manhattan-based firm to host our meetings in the future. Meanwhile we’ll run our meetings online so you’re welcome to join no matter where you are located. Go Dart if you need to deliver today!
yakovfain.com 
Thank you very much, Yakov! As always it was very informative and I’m sure it will help greatly to make right decisions.
If you have lots of Java in the back end GWT should be the natural choice not Dart. It s funny that you like Dart but bashed GWT in one of your books.
I’ve never used GWT, but usually the problem with things like GWT – they do not give you access to the most recent Web APIs. That’s not the case with Dart. Yes, it compiles to JS, but it has its own APIs to access all the features in a Web browser (often even more advanced than JS versions). To give you an idea of what APIs we use – pure HTML-based PDF viewer, signature capturing, WebRTC-based browser-to-browser calls, integration with 3rd-party JS components, etc. Correct me if I’m wrong, but I believe GWT won’t allow you to do all these things.
I’m an experienced GWT developer and JAVA developer, I’ve started using Dart for a new project’s frontend and would never touch GWT again while Dart is around – just too much boilerplate code to get simple things done. Building a site in Jquery is also doable, but not very maintainable once you start hitting the 6+ digits LOC, from the tooling support it seems Dart might be easier to maintain for large frontend projects.
GWT does allow you to use all of those APIs, for example, here’s GWT easily consuming Polymer components https://www.youtube.com/watch?v=wFMD1GXR2Tg and here’s a demo of Elemental (which comes with GWT 2.5) in 2012 accessing WebRTC https://www.youtube.com/watch?v=VOf27ez_Hvg#t=1474
GWT 2.8 has fantastic JS interop. You can even do things impossible in Dart like subclass native JS in Java and vice versa, e.g.
function Foo() {}
Foo.prototype.meth = function() { return “Hello “; }
@JsType(prototype=”Foo”)
interface Foo {
String meth();
}
class Bar extends Foo.prototype {
String meth() {
return super.meth() + ” World”;
}
}
This actually makes ‘Bar’ a subclass of the JS ‘Foo’ constructed object.
The upcoming GWT 3.0 will feature Elemental 2.0 which auto-regenerates the complete browser bindings automatically for each and every API in the browser by directly processing both the W3C specs as well as the browser source repository IDL files. Whenever the specs and browsers are updated, the Java interfaces will adjust, without waiting for Google engineers to update them.
i am currently doing both: gwt and dart. when i started web development, dart was not available, and after shortly trying javascript, i knew that i never ever would touch that language to do any serious development.
so i started with gwt and got an app that is in production now and works pretty well.
then dart came around and as i was about to start a new project i was giving it a try.
the language differences apart (to me dart feels a much more modern, flexible, dynamic language than java)
the main difference for me now (as i maintain the two codebases) is the speed of development/debugging.
in dart/dartium it comes down to hit save in the editor and refresh the browser; then you can step through your code with a good debugger. this edit/debug cycle in dart is very fast whereas in gwt, even in superdev mode, you have to wait some seconds between the save and the debug. and then you are stuck with the browsers developers tools for debugging, which, having sourcemaps, is not that bad anymore.
in this aspect, for me, dart is far better.
where gwt is still doing a better job (in my experience) is the compatibility of the produced javascript. it normally runs pretty well in the browsers my company uses (which, for gods sake, does not include ie).
the produced javascript from dart normally does not make problems with chrome, but with firefox there are sometimes subtle differences. although, i must say, that dart has gotten better in this aspect, gwt seems much more reliable/robust.
Обязательно начну учить дарт, когда под шконарь загонят
Great post! I’m just waiting to see more like this. Exaclty the reason why Dart is the better choice (at least as we speak). No sane developer if tryed Dart for a little more than a quick glimpse will say something like – “don’t fragment the web, stick with javascript”. Of course Dart miss some stuff for now (easy plugable architecture come to my mind here), but after I switch my project to it almost an year ago from javascript/php I’m so happy – maintainability, server/client code reuse has never been at that level.
Thanks for interesting overview of Dart. Tools list is very impressive and the Dart looks ready-for-production.
“no browser except Dartium support it ”
“no jobs on dice.com that require programmers with Dart skills”
“Dart skills may be in even lesser demand in the enterprise world”
“They(Google) won’t fight for Dart in enterprises.”
“The syntax of Dart and ES6 are literally the same”
“now they’re(Google) working on the IDE for ES6”
So why learn Dart? Why not learn Javascript(ES6) directly ?
I dont understand. can you pl explain?
The answer is in the last words: if you need to deliver today. Dart is available today, but ES6 not.
I believe unless ECMAScript (6, 7, etc.) introduces optional type annotations (at least similar to TypeScript), it won’t improve the situation enough to choose JS over Dart. I think type annotations is the foundation for advanced tooling (static code checking, IDE autocomplete, code navigation, documentation hints, tree-shaking, etc.). Classes and modules in ES6 will be a step forward, but still not even close to Dart.
Anton, here is the answer to your concern – AtScript: http://www.theregister.co.uk/2014/11/04/improving_javascript_google_throws_atscript_into_the_mix/
Is it Google digging under its own Dart? Or just trying to own the whole field? 😉
AtScript is not intended to be a full-fledged language. It’s just a tool to write the code that can be semantically mapped to JS and to Dart. Angular team developing AtScript to unify codebase for AngularJS and AngularDart. Even if JS will have type annotations, introspection and major browsers will support it natively, by that moment the life cycle of most JS apps written today will end.
Would be so great to see your another review for Meteor (http://www.meteor.com) framework (platform, stack whatever). Interestingly, there are also someone among that community making mention of Adobe/Apache Flex days at “http://forums.meteor.com/t/the-history-of-flex/2418” . Looking forward to see your own words. Thanks very much.
Dart still a good choice today for web development ? We still have a Flex application and we need to migrate it to another platform; I was considering Dart, but I don’t have much experience in programming with Javascript; I’ve read many opinions about it, some really excited about Dart 2, others saying Dart is dead; Wish I could have a better understanding in order to make a well fundamented decision; thanks in advance
Go TypeScript. Dart didn’t make it mainstream.
Dart + Angular5 still works fine, although KotlinJS + TypeScript looks very attractive especially if you’re already using Kotlin in the backend. KotlinJS basically wraps TypeScript interfaces in Kotlin code, so at least you get to write Kotlin instead of JavaScript. TypeScript on its own is not terrible either.