Dart: on its merits

Younger Paul was an inquisitive chap. He liked to monkey about with loads of different technologies, frameworks and platforms. That's changed, and I've found myself opposed to one technology in particular: Dart. But I think that's because I was conflating the language with the VM...

  • Last updated: 18 Dec 2013
  • Est. Read Time: 10 mins
  • Tagged: #perfmatters, #dart

Duke Nukem vs Quake

I was, I think, 12 years old when both games came out. There were turf wars over which game was better. The humour of Duke Nukem was brilliant to teenage Paul, but Quake had, like, a for realz 3D engine, none of this sprited characters nonsense!

The Paul Lewis Approach™: buy both, play both, enjoy both.

Taking stock

Roll on to today and I’m a little disappointed with 2013 Paul, if I’m honest. To understand why, you need to know a little about what I got up to before Google. The list of technologies on my CV (resume for the non-Brits) looked a little like this: HTML, JavaScript, CSS, Flash (AS1, 2 and 3), PHP, MySQL, Java, Objective-C.

In order to know something is the right tool for the job you have to understand your entire toolkit.

If you speak to anyone I worked with during that period I’m pretty confident they would tell you I could hold my own in any of those stacks, and a few others besides. The point here is absolutely not “look at me, aren’t I amaaaazing?” but rather my underlying attitude: I was inquisitive and thorough. I dedicated myself to understanding as many technologies as possible, their strengths and weaknesses. I didn’t really care whether something was in fashion per se; if it was the right tool for the job it was going to get used. There is a certain amount of subjectivity to the term ‘right’ in my mind, it’s sometimes just a judgment call.

But in order to know something is the right tool for the job you have to understand your entire toolkit.

Did something change?

You know, it did: I had kids. Kids, as every parent knows, equate to way less free time. Consequently I’ve let my drive to look at new technologies wane. Worse than that, though, without that drive I’ve not had as broad an outlook, and I’ve noticed I’ve become a little, umm, polarized in some areas. Not necessarily in a good way.

Bias

I’ve caught myself being opposed to Dart, and yet I couldn’t articulate why. Younger Paul would be disappointed in such a lack of openness. I suspect it’s more a product of laziness or, more charitably, that lack of time I just mentioned.

It’s been super easy to be that way though, because today’s recorded opinion on chromestatus.com, at least from vendors and JavaScript devs, is against Dart. But I’m starting to wonder why. Perhaps they, like me, have conflated Dart the language with Dart VM.

The Language

When I look at the language itself it doesn’t have any of the frankly bonkers aspects of JavaScript. It also has some pretty cool features in and of itself, like classes, maps, cascade operators, streams or tree-shaking. Parallels for some of those are already landing in JavaScript as of ES6, which is awesome.

The genius of the JavaScript is that it’s super simple to get started with, ubiquitous, and once you get used to it developing is fun and fine.

The genius of the JavaScript is that it’s super simple to get started with, ubiquitous, and once you get used to it developing is fun and fine for many classes of applications. To say it’s the greatest possible language we could have on the web (which seems to be a consensus view, though I grant not everyone’s) seems myopic to me.

What matters to me most is developer productivity and that you can make better apps and sites for your users. Whatever makes that possible is A+ in my opinion. If that’s JavaScript, great. If it’s something else, high fives.

#perfmatters

You know me, I love performance, and I won’t tolerate anything that causes problems. Thankfully dart2js is not a hacked-up bit of code, but rather an optimizing compiler that attempts to take Dart and output human readable and optimized JavaScript. What kind of performance they’re aiming for I do not know, but if it’s as good as plain old I-wrote-that-myself JavaScript that’s cool. And currently, on some benchmarks, it is.

In short, I don’t want a penalty if I use Dart because I could’ve just as easily written JavaScript and not taken the hit. That’s a big deal for me and I’m sure many other developers, too.

But what does Dart solve? Why can’t we just evolve JavaScript?

Who said it had to be an either-or thing? Bear in mind I’m the guy who bought Duke Nukem and Quake. (I repeated that feat with Unreal Tournament and Quake 3 FWIW. Believe me, it’s the showbiz move.) Apple allows iOS apps to be built with Objective-C and C++. The lack of support for C++ would hamstring a huge quantity of games, since many engines are authored in it. Microsoft allow apps to be authored in C#, C++ and VB, all of which are compiled down to their CLR and then executed. Android lets you use Java or C++. You get the idea.

My point is that I see a lot of people asking what Dart solves, rather than asking what limiting the web to JavaScript alone prevents. But that assumes an attempt to replace JavaScript with Dart. (I’m familiar with the infamous memo.)

To my mind Dart makes sense for large and/or complex codebases where classes and optional static typing become critical to productivity and stability. It also makes a lot of sense for any developers who struggle with or simply dislike the fundamental building blocks of JavaScript like prototypal inheritance or function scoping. I personally have no problems with those aspects of JavaScript, mainly because I’ve spent time understanding them, but I sympathize with many programmers who come from a classical background and don’t have the time and inclination. You can say that “they shouldn’t be on the platform”, something I’ve heard said a few times, but I would respond that that’s antithetical to the inclusive nature of the web.

In summary, I consider the Dart language a great option (possibly one of the best) amongst the compile-to-JavaScript options like CoffeeScript, TypeScript, GWT, or any of these languages.

Dart VM != Dart the language

What I do see, however, is the concerns of those who do not have the engineering resources or desire to include two VMs (JavaScript and Dart) in their browser. But that’s why dart2js exists. Nobody has to ship a Dart VM. From a Chrome point of view, there are very clear criteria in place for adding new features to Blink, which we set out in April of this year.

My main problem is seeing the Dart VM be conflated with the Dart language: Dart as a language is great, the Dart VM itself may not be, depending on your perspective. They’re related, but objections for one should not be leveled at the other: the language is developer-facing, the VM is a vendor concern in the main.

I believe everyone should be cautious of introducing a new VM, Dart or otherwise, because it potentially represents a huge investment for the platform as a whole, not just one vendor.

I believe everyone should be cautious of introducing a new VM, Dart or otherwise, because it potentially represents a huge investment for the platform as a whole, not just one vendor. Nor should we rule it out, but rather we should judge it against our goal of producing the best possible multi-device experiences for our development teams and users.

So if I want to do the Dart thing I’d have to keep two versions of my code on my server?

Sure, I guess. But I don’t see how that’s different to keeping multiple video file formats, image formats, or source maps (and corresponding unminified source code). Ultimately you would write Dart code and the publishing process would create the equivalent JavaScript.

We have a long tradition of developing in languages that is most convenient for us (ActionScript, C++, CoffeeScript, TypeScript, JavaScript), having some kind of processing step in the middle (Grunt, Ant, Maven, Makefiles, Flash), then serving the most appropriate thing for the browser. If any vendor isn’t shipping a Dart VM ultimately there’s JavaScript that can run. I don’t get any real heebie-jeebies from that, especially in light of my former points about productivity and performance.

2014 and onwards

I don’t know if Brian was thinking of Dart when he tweeted this, but it resonated with me:

You might think I’ve “drunk the Dart Kool-Aid”, but that’s really not the case. All I’m saying is there are many things about Dart to like and by taking a step back I’m appreciating them, much as I appreciate the niceties of Objective-C, Java, PHP (seriously) or pretty much any language: classes, optional static typing, collections and tree-shaking are all great features. Again it’s not an either-or thing in my head, this is about being open to different technologies and approaches.

I think 2014 Paul is going to recapture a bit of his former agnosticism. Kind of like buying Duke Nukem and Quake.