We are Switching to Dart | Hacker News Reader

We are Switching to Dart

ramen.io

105 pointsMartinMond94 comments

I think a few points are worth emphasizing. Dart produces JavaScript that is closer to being correct https://news.ycombinator.com/item?id=5424680

Dart can produce JavaScript that is faster http://news.dartlang.org/2013/03/why-dart2js-produces-faster...

The JavaScript output of Dart2js works across all modern browsers (IE9 and above, among others.) No browser hacks required.

Having said that, I wish they would stop working on advancing Dart and ship a 1.0 version. It's been 1.5 years since it was announced. Make the advancements in the 1.1 or 2.0 and give the tool developers a solid target to optimize for in 1.0. Let us not have to sell clients on a beta development system, even though that's what I'm doing and it's working, despite some panic when Dart developers break things with breaking changes (which is often.)

IE9+. I hope people don't miss this keyword.

That satisfies all mobile development as far as I know. The loss is on Windows XP desktop for those stuck on IE8 and below. So far, I'm doing ok telling people to run Chrome or FireFox on XP as most of them are anyway.

To give some perspective: we were lucky to have less than 2% of traffic coming from IE, most of those visits via IE9+. This made the decision to switch easy in terms for browser support in our case.

YMMV of course but it definitely makes sense to look into your target audience. For some people Firefox 3 and IE6 might still be user bases that are worth supporting, we are glad to have a product for web and mobile developers :)

I wouldn't be surprised if this decision also makes sense for a lot of other target audiences, especially when you consider that you are in it for the long term.

If your browser requirements are IE9+, then there's little need for things like underscore (and, arguably, even jQuery) since you can count on x-browser support for things like document.querySelectorAll() and other niceties that jQuery typically levels the playing field for.

For example, why would there have been confusing over _.each vs. $.each when you have perfectly consistent native support for [].forEach? Nothing against Dart... it's cool and all, but I'm not sure the JavaScript "fragmentation" rationale is all that strong when you have the luxury of only dealing with such modern implementations.

My understanding is that people continue to use jQuery because it makes DOM manipulation that much easier. The Dart authors kept this in mind and said jokingly on http://www.dartlang.org/articles/improving-the-dom/ One area where the DOM has a bunch of baggage is finding elements. Today’s DOM has a pile of methods for finding stuff. All of this piled up before jQuery appeared on a mountaintop to give us the revelation that Thou Shalt Find Nodes By Using CSS Selectors. With the One True Way in hand, we’ve stripped it down to just two (!) methods: query() and queryAll().

I'm all for simplicity, and, again, this isn't an argument against Dart. But I would still contend that merely shrinking your DOM API surface area is only of marginal significance.

Historically, the hardest part of interacting with the DOM has been the inconsistencies (and missing functionality) amongst ancient browser versions. We've had standardized methods for a long time now that make DOM interactions relatively trivial if you have the luxury of working with browsers that support them.

> Historically, the hardest part of interacting with the DOM has been the inconsistencies (and missing functionality) amongst ancient browser versions.

Even newer browsers have a surprising amount of DOM inconsistencies, especially for newer HTML5 APIs that are still evolving. While this is an ongoing job, the Dart DOM API tries hard to polyfill that so that you get a single API that works across most browsers.

Querying is only a small part of it, though. jQuery provides result sets as proxies for the actual objects. So this:

    $(".foo").css("color", "green");

will actually apply the CSS to all matches. This becomes doubly handy when doing things like attaching event handlers, removing nodes, etc.

Looking at Dart's API, I don't see anything like it; queryAll() returns a List<Element>. In order to act on a collection of elements, you have to use iteration mechanisms such as for loops.

The whole concept behind jQuery's $() is that it's a DSL.

I think the language is done. After listening to this FLOSS episode, I think they're just finishing off the libraries.

http://blog.sethladd.com/2013/03/dart-on-floss-weekly-from-t...

Sounds like 1.0 might be a Google I/O announcement.

There's still a small amount of language evolution going on. We recently added mixins, for example, and there's a couple of minor things still being batted around.

However, we are making very few breaking language changes right now. Most of the fast-paced evolution is in the core library. Unfortunately, the corelib was essentially stagnant for close to a year, so now that people are working on it, they are feverishly playing catch-up to get it to a good place before 1.0.

Assuming this is not April 1 con'd.

Dart is really cool. Awesome, in fact. I want this project to do well.

But there's just no way I am going to base my business on it when not even Google uses it for their own stuff. It's just way too early.

I don't know if Google does not use it for their own stuff and you don't supply references. That's not the same as saying Google will not use it for their own stuff. That would be quite surprising. In fact, I'm assuming they are developing it primarily as an internal tool, hence the disregard for a reasonable time line for shipment of 1.0

> I'm assuming they are developing it primarily as an internal tool

It's neither primarily internal nor external. My understanding is that the higher-ups feel Dart must succeed both inside and outside of Google to be successful. Which one must happen first is an open question, but I think the end goal is wide use both inside and outside the company.

> end goal is wide use both inside and outside the company I agree fully. I would just add that, just in terms of salaries they've paid to Google employees working on Dart, they've spent millions, which they won't get back from by selling Dart. They probably have a compelling internal reason for doing this. They win if external developers adopt it because useful libraries will be written.

> they've spent millions, which they won't get back from by selling Dart

Yes, I think everyone understands today that languages don't directly generate revenue.

> They probably have a compelling internal reason for doing this.

Off the top of my head:

* If it makes Googlers more productive writing apps in Dart, that directly saves Google money. We, obviously have some very large JavaScript applications (gmail, maps, docs...) and we spend a ton of engineering time on them. If we can make those engineers more productive, that's a huge savings.

* If Dart succeeds externally, that's more third-party code that Google can then use for its own projects, so that directly saves us money.

* If Dart makes other web developers more productive, that makes the web bigger. A bigger web means more people spending time on it and more people doing web searches, which ultimately goes right back to Google. Google is happy when the web gets bigger.

Your first reason is the most compelling and what JavaScript developers might want to consider. My own experience is that I am much more productive writing code in Dart and then converting it to JavaScript. Why?

* Autocompletion (intellisense)

* Refactoring

* Use types and catch errors before runtime. Types are optional, although I don't know why you wouldn't use them unless you are pasting in some JavaScript code and running it as Dart. Hand converting JavaScript to Dart is fairly easy because types are optional.

* Quick turn around time in the "change code, set breakpoint, run code, stop at break point" cycle.

* Calling native JS code is painless. Libraries that are currently not available as Dart, such as three.js can still be used.

* Project organization is fairly automatic.

* Code analyzer - this one is my favorite. The analyzer will tell me if my change causes a problem in another file. It runs in the background, like C# does.

I have no information except what Google says publicly. In the absence of any information about whether Google is using it, I have to assume they are not when making a decision on that basis.

The Dart team has said that internal teams are already using Dart, but nothing they are allowed to talk about publicly yet. I'd imagine as part of the 1.0 launch they will start talking about it.

A lot of people like to say GWT is dead, but Google AdWords still uses it. And as a users of GWT still, their dev team actually seems to be more on-top of putting out new developer plugins (for each Firefox update). Sure releases of GWT have slowed down, but it is still being maintained and used within Google.

This makes sense. Every time I side-peek at JS, I get terrified by the huge amount of libraries that one is supposed to be used to just get it running. It must be a liberating feeling to be able to just use one language with one standard library, for all your stuff. The "batteries included" philosophy worked well for Python.

I wonder if we could go so far as to say Dart is to JavaScript what Python is to PHP? My whole reason for using Dart on a project was out of desperation because I was handed a JavaScript/PHP mess and I didn't want the nightmares to start again. I've been sleeping really well lately. Since Guido von Rossum did a stint at Google, all they need him to do is ask him to bless Dart and we're good, or find a suitable rock star replacement to promote "The Dart Way" ;-)

The title is inaccurate, they weren't using JavaScript before, they were using CoffeeScript.

Seems that the story is they are moving towards a more opinionated language/framework. That it is Dart isn't the story here; they don't even mention the Dart VM as a benefit for the switch. It just as easily could be ClojureScript, which provides all of the same benefits.

CoffeeScript is JavaScript with syntactic sugar so the title is accurate.

But the title makes it sound like they are changing languages when what the post is actually about is switching ecosystems.

[disclaimer: I work on Dart VM]

Even though Dart VM is not a deployment target for the client side code right now it is still an integral part of the development experience. It runs all your code while you develop (no need to compile to JavaScript just edit&refresh) and backs things like dart2js, dwc, pub which are all written in Dart itself.

Right, but the author here doesn't mention the Dart VM as a reason for the switch; they are not switching to get better performance in Chrome. They are switching because they like the language/ecosystem better.

Also, IANAL but I'm pretty sure you don't have to include a disclaimer to post on the internet. No one is going to rush out and buy Google stock based on your comments so there is no conflict of interest to what you wrote.

Yes, I agree with your point. Yet, I see quick edit&refresh as the part of the ecosystem. Hard to enable that without VM.

[regarding the disclaimer: I add it for two reasons. First, I have seen people accusing others of hiding their bias, so I prefer to state my affiliation explicitly. Second, if anybody wants to ask any Dart VM related questions and get response they know where to ask :-)]

Sweet... so how does Dart compare with asms.js?

/me ducks

Serious answer:

The Dart2js compiler could easily take advantage of asm.js additions, and generate javascript code that uses asm.js. If asm.js does take off, all it can do is help Dart generate faster running code.

Now, if we are talking about the DartVM, asm.js could be used as an argument not to include the DartVM in other browsers. But asm.js is still very much in it's infancy, so we really need to wait and see how it's adopted and how it progresses.

Thanks, I agree with your comments. I was mostly just trying to poke the bear, though (http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html) :)

No it couldn't. asm.js has no garbage collector. The only way to get dart running on asm.js would be to port the entire VM to asm.js, which afiak won't work since the dart JIT emits machine code at runtime.

I don't think @kyrra was suggesting that Dart would compile completely to asm.js code, just parts where it makes sense (just like normal JavaScript uses asm.js only where it makes sense).

I think there are incomparable. Dart is not a subset of JavaScript. Dart is dynamically typed. But Dart is more than just a language now, it's ecosystem of tools and libraries.

The DartVM has supported for typed arrays too, so it probably wouldn't be much work to hack emscripten to generate Dart source code.

It would be very interesting to see a benchmark of emscripten/SomethingMonkey/asm.js vs emscripten/DartVM.

(Could also add emscripten/dart2js/V8 for giggles)

Earlier you said:

> That it is Dart isn't the story here; they don't even mention the Dart VM as a benefit for the switch.

Which I think is equating Dart with the VM? Then you say:

> They are switching because they like the language/ecosystem better.

That sounds to me like Dart is the story then. The language/ecosystem is Dart, isn't it? Can that be separated somehow?

Dart just happens to be the ecosystem they've chosen; there's no reason they couldn't have chosen ClojureScript, for example, which provides all of the same benefits (a more out-of-the-box experience). It's more of a post about their desire for a package manager and module loader being built into the language.

Guys, if you can get somebody to write a decent (say, Flask level) server side Dart framework, Dart could gain a lot of ground there.

Server side is were people are looking for nicer solutions that what's available, even moving away from RoR towards more one-page-app friendly stacks.

It's also an area were IE compatibility doesn't matter (because we're server side), whereas raw speed, good tooling, type checks and such matter a lot, so it plays to Dart's strengths, especially if it could provide both a freaking fast raw server performance (the way V8 is already 10x faster to PHP and Python) AND a good async story with futures, that for Node.js are bolted-on.

Since I primarily enjoy using Dart on server-side and like to use it as a replacement for Node when I can, I am actually working on a CRUD framework with middleware for Dart.

Inspiration comes from Express for Node, but it is similar to what you can achieve with flask.

Give it a look, and file feature/bug requests if you want to see something or something breaks.

I know of 1 person that implemented a Google Oauth endpoint with it, so it does work well.

http://github.com/Daegalus/fukiya

> ClojureScript [...] provides all of the same benefits.

That doesn't seem to be the case. Dart provides great tooling and you can also step-debug your code from within the IDE. The workflow with Dartium (Chromium with embedded Dart VM) is pretty neat. The performance of the generated JavaScript is pretty good, too. There are also Dart Web Components which give you custom tags (with shadow DOM) and two-way data-binding.

Finally, Dart, with its "boring" C-like syntax, is familiar to pretty much anyone.

Sure, but those aren't the arguments the post made. The post focused primarily on the ecosystem and package management aspects, which Clojure/script certainly has.

I only mention the virtual machine very briefly in a list of things that come with Dart (batteries included rock) as I didn't want to loose/confuse the reader since there are no browsers that come with a Dart VM yet (except Dartium which is awesome for development).

As mraleph already mentioned the Dart VM is very useful for the instant-feedback development experience that you get from working with Dart.

It would be awesome to see it in Chrome or other platforms going forward but having it from the start is a big plus for day to day development and for the people building infrastructure on top of Dart.

There are also people who do exciting stuff with the VM in node-like scenarios.

I personally can't comment on that because we haven't looked into that use-case yet (our backend is in Python and App Engine does not support Dart yet) I'm very interested in the VM and I guess we'll see some interesting things in this area going forward.

Why does so many startups feel the need to brag about the fact that they're switching to <hot new technology>? To me it just comes off as an attempt to convince themselves it's a great idea.

How about coming back in a year and telling us how it turned out instead? Actual case-studies and analysis are interesting, fashion statements are not.

I think it does at least 3 things well:

1. It lets developers familiar/interested in the tech to know that you use it and that they should apply there.

2. You've done the work to research it and make the decision to switch - it doesn't hurt share that. Who knows someone may point out some flaws you didn't expect.

3. It increases the inertia of the technology. There are strong network effects in technology and if everyone sees that something is growing they'll make the jump too. One new library created per X developers is a big win and makes it better.

Thanks a lot for your comment.

We'll definitely keep you posted on our journey with Dart. I don't have specific announcements yet but we're looking forward to share code examples and open source a few web components going forward.

So far Dart really has been a pleasure to work with and we'll definitely blog more about it in the future and hopefully also go a bit more into detail.

The main motivation behind this blog post came from people asking us about how it was to work with Dart and why we chose to adopt it.

I can see how this might come across as a fashion statement but I just wanted to share my thoughts and have a url to point people to :)

The idea that this is fashion statement is laughable because Dart has been quite unfashionable until recently (like 2 weeks ago.)

It seems very risky to base your core business on a language that's only been around for two years. Sometimes web development seems to be more volatile than the fashion industry.

With the state of javascript at the moment you would certainly be using library code that's less than two years old to build core parts of your app. The line between language and library can get pretty blurry, particularly when we're talking about a language that compiles to JS.

To be fair, there's a difference between a library and a language here. Replacing or taking on the maintenance for a library is a much more feasible option for many than jumping to a new language or taking on the maintenance for an entire language (as it's not just the compiler, it's also custom tooling, debugging, plus Dart really needs its own libraries, etc.)

I thought the same thing and wondered if they have a backup plan if/when Google suddenly decides to stop supporting it.

Quite true.

Every time I see such posts here, I think what is the business value of such changes.

Why go through so much pain to avoid JavaScript, coffeescript now Dart? JavaScript is not the problem, it's how terrible our community is at sharing/creating modular things. Classes and shitty syntax wont help you there

> JavaScript is not the problem, it's how terrible our community is at sharing/creating modular things. Classes and shitty syntax wont help you there

How would you switch communities without switching languages? As far as I can tell, it's actually much easier to switch tech than it is to convince a million existing users to change their culture to something different.

Not really just stop using/promoting bad design like jQuery plugins, eventually people catch on.

I'd like to know how they prevent plugins from colliding and polluting the $ namespace.

We shouldn't use a $ namespace haha, that's a big part of the problem, which has nothing to do with JavaScript. jQuery was and always will be poor design. It's a great project and has obviously helped a lot of people but it makes no sense.

I think you're wrong. JavaScript has a great community with tons of talent. JavaScript is the problem. You don't see nearly the same level of problems in the Python community for example.

The problem here is browsers, not JavaScript. Python has evolved much since the '90s, just like JavaScript has. The problem unique to JavaScript is browsers, and end users running browser versions with a decade span in between them. This is also why the "IE9+" requirement is so relevant to this conversation, because developing with that luxury is entirely different than developing for IE7+ (or, for some poor souls still out there, IE6+).

You touch on a good point, but I'm not sure it has to do with this particular piece. Rather, the author seems really confused:

  There are great projects like Underscore, Sugar,
  Prototype, jQuery, CoffeeScript and many many more that
  help to work around JavaScript’s language quirks.
  Unfortunately they don’t mix and match very well. Also,
  which map() or forEach() implementation should I use if I
  have multiple available?

That's like comparing barricuda, rubberbands, and bolts. Only one of the projects he mentions has anything to do with "JavaScript’s language quirks," and that's CoffeeScript. Just another person who did not know JavaScript/frontend development, expected it to be like any other programming environment, and bailed rather than stepping back and reconsidering his original assumptions.

I understand what you're saying but I'm humbly disagreeing.

I do believe that all the mentioned frameworks (while positioned differently) do offer solutions to work with/around JavaScript language quirks. e.g. simple things like

    * working with collections
    * working with objects
    * extending 'things'
    * iterating over 'things'
    * working with async

That's one of the main things that I (and probably more) people find confusing about the JavaScript ecosystem even while I'm not new to it.

JavaScript provides arrays and objects, and also functions for grouping data (via closures). What else would you expect it to come with? The quality `goog.structs` package speaks to how easy it is to create very high-level data structures.

Are you perhaps thinking of the baroque and once-very-inconsistently-implemented DOM API?

Regarding your other points, JS is an extremely object-oriented language. I really don't think you need more "working with obejcts" things out-of-the-box. Iteration is very straightforward in all cases, unless you find hasOwnProperty confusing. The Node.js project has demonstrated well how easily Async maps to JS outside of the browser model (where Async has always reigned).

JS is a strange beast in certain ways, but it is a featureful language.

JavaScript is extremely poor at expressing OOP, it requires so much un-intuitive boilerplate to express your intent that many don't bother and will just hack together the simplest thing that works. Which causes the current situation of having so many different libraries to declare classes and they all do it their own unique way which are not compatible with each other.

It's the same for iteration, the hasOwnProperty is mostly omitted because it works most of the time without it and specifying it adds un-necessary boiler plate.

Same with async, there's a zillion async libraries that try to manage async in different ways and they aren't interchangable either. By standardizing on Futures/Streams it means all libraries can build on consistent and composable foundations and build higher-level functionality.

If you avoid inheritance js is just fine, inheritance is a pretty terrible concept to begin with IMO.

Hey TJ, thanks for your work on component.io, Stylus (we use Stylus) and in the node community. I applaud every effort to improve the JavaScript ecosystem.

I feel that Dart having a solid foundation make it hard to bike-shed over simple things that just should work out of the box. This is where I see Dart helps, where CoffeeScript didn't (because it was not its design goal).

Isn't that the point of http://requirejs.org/ and the AMD API - http://requirejs.org/docs/whyamd.html ? Why is there not more of a push for frameworks and libraries to be AMD compatible? The Dojo Toolkit is, and thus lets you load just what you need.

Don't forget npm, and bower, and jam, and component, and ender, and volo, and...

Really, it's only a matter of time before someone creates a JavaScript package manager manager so you can manage your package managers.

i think of it more as systemd than apt. calling it a package manager isn't all that accurate.

Scroll down to the "Module Loaders" section at http://todomvc.com/ I don't see any of the products listed you mentioned.

Notice that require.js works with Backbone.js, Ember.js, Knockout, AngularJS, Ember.js, Knockout, AngularJS, CanJS. TroopJS uses require.js. The only major competition it has is Thorax + Lumbar or Twitter's Flight.

http://requirejs.org/docs/whyamd.html#amdtoday

jQuery 1.7, Dojo 1.7, EmbedJS, Ender-associated modules like bonzo, qwery, bean and domready, Firebug 1.8+, and the BBC all use it or work with it.

This sure sounds like April 1 joke, but, I get that developer(s) wanted something even more innovative then brunch and coffeescript. Like arkitaip said, it is a very risky move.

Riskier than using the latest perpetual beta JavaScript library? I don't think so.

Which one ?! JQuery? What are you angry about?

I'm not angry, I just want something better. As Anders Hejlsberg said "you can write large programs in JavaScript. You just can't maintain them."

http://lostechies.com/derickbailey/2012/06/04/anders-hejlsbe...

BTW this is not an April fools joke :)

I like your post since it's a refreshing take on today's language and framework decisions. Usually people go for Coffee, Node, Go, Clojure or ClojureScript nowadays (I mixed FE and BE tech deliberately).

What I am interested in: Why did you go for Dart? What was the trigger? When I look at Google Trends Dart seems to have a very hard time compared to other current technologies regarding search popularity.

And what's your backend based on? Could I go for Dart with Node?

You could write the back-end in Dart, too. The Dart VM can do IO out-of-the-box. Just like the Node executable, it can be used to run command line scripts, web servers, or anything else you can think of.

Anyhow, since the front-end only communicates with the back-end via standardized protocols (say, HTTP or WebSockets), it doesn't matter what's used on the server-side. These two parts are completely decoupled.

While I think dart is a nice language, I do not think JavaScript is bad enough to justify switching to a completely different language.

I worked on some big js projects, and together with a good module-system and jslint with strictmode on it works out all quite well.

I think OOP is nice but you can do without much of it by focussing on composition instead of inheritance. http://en.wikipedia.org/wiki/Composition_over_inheritance

Dart has a big focus on OOS and looks a lot like "JavaScript for Java Programmers". Which is not a bad thing.

5k large? 10k large? 500k large?

the real test of a language is when it has all the millions of bug fixes built in over the years. At that point, do you feel comfortable refactoring/rearchitecting it to remove development inefficiencies? I argue that with Javascript there is no way you do once it grows beyond a small team size.

Interesting post! I'm wondering:

1. How do you test your Dart code?

2. How do you integrate Dart with your existing Javascript?

3. Do you use Dart Web UI?

[disclaimer: I work on the Dart team]

1) We have unit tests and mocks built-in. Check out https://www.dartlang.org/articles/dart-unit-tests/

2) We have JS-interop. Check out http://www.dartlang.org/articles/js-dart-interop/

3) We have tutorials for Web UI. Check out http://www.dartlang.org/docs/tutorials/

Hope that helps!

Great questions. Seth already hinted on some answers but I'll try to go more into detail.

1.) We have an acceptance test suite for the existing app (pre-Dart) using web driver and written in Python). This is currently quite useful since we can continue to use the same test suite when we've migrated a certain widget to Dart.

Additionally to that we use the testing infrastructure that comes with dart: https://www.dartlang.org/articles/dart-unit-tests/

2.) We use js interop http://www.dartlang.org/articles/js-dart-interop/ to communicate between Dart and JavaScript.

For the migration we are rewriting widget by widget (Backbone view by view). That's fairly straight forward since our existing Backbone.js codebase already was structured in a way where widgets are encapsulating behaviour, dom and style.

3.) Yes we do use Web UI. It's awesome. A bit like Angular.js but on top of a solid language foundation. We'll also look into open sourcing some of our web components going forward :)

How well does Dart work with node.js? Should I even consider Dart if using node.js?

It works transparently on the client to a node server of course. I haven't seen a lot of examples Dart interop with Node on the server. There are two choices, Use the Dart VM on the server and interop with Node through the js-interop lib, or use Dart2Js to convert Dart to JavaScript and operate with the node packages that way. There's still a lot of uncharted territory with Dart, which I think provides me with a lot of interest and opportunity.

I think if you are using it in the server-side to just use the DartVM. its the direct analogy to Node.js. It runs server code and everything else. and I am not sure why you would even try to run it on Node.js except for some library that you really need.

DartVM seems to outperform V8 anyway from the benchmarks on the Dart site.

I would be too afraid to base a business on a language that's only two years old. It's not even a guarantee that the language will remain supported by Google in the long term, given their periodic house-cleaning.

I hope Google gets (even more) serious with Dart. Web App Development with JavaScript is a joke. Just remember the recent callbacks vs promise debate. It's like JS devs know nothing about software engineering.

debate?

I'm talking about https://news.ycombinator.com/item?id=5466872

Where to start, where to start...

Many libraries, including Underscore, default to the native browser methods when they're available. It's not really much of an issue deciding which map() to use.

April fools?

It's not, we're serious about Dart :)

Why Dart over http://meteor.com/ https://github.com/yahoo/mojito or http://derbyjs.com/ ?

The answer is contained in your question, I think.

Exactly :) even more-so given the list is incomplete.

there are others? what other frameworks render the page server and client side?

http://derbyjs.com/#why_not_use_rails_and_backbone

edit: ok I forgot http://www.socketstream.org/ but regardless, the realtime single page app sector really is dominated by those four products. everything else is already obsolete.

http://derbyjs.com/#introduction_to_racer

My April fools joke should have been that I've modified the CoffeeScript transpiler to emit Dart code - CoffeeDart!

Reply on news.ycombinator.com