[jlongster]

I somewhat skimmed the article, but it doesn't mention the fact the JavaScript is on the verge of getting modules. Unless you really love Dart, you can fix most of these problems by using something like the ES6 module transpiler: https://github.com/square/es6-module-transpiler. Even better, in then next few years JavaScript will start adapting these natively, solving many of the organizational issues laid out in this post.

[sethladd]

Thanks for the feedback. I did point out, in the end of the article, that some of the techniques (e.g. libraries, futures) aren't impossible in JavaScript. And I'm really happy to hear they might be coming to a future version of JavaScript (everyone should have modules and promises!). Part of the point of the article is that Dart has these features now.

[Excavator]

Thought you'd might want to know that Promise¹ is available in Firefox & Chrome since quite a while back and the spec for Modules can be found here:

Spec: http://wiki.ecmascript.org/doku.php?id=harmony:modules

1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[sethladd]

Yup, thanks! What's the story for modern browsers that don't yet support those features? Do they both have polyfills?

As I mentioned in the article, libraries and futures aren't exclusive to Dart. It's just that they are here now for Dart and are compiled to JavaScript for all modern browsers.

I think it's telling that the original author didn't use Promises or Modules. Of course he could have, but we should ask, why didn't he?

[jamesknelson]

While a lot of browsers are still lacking pretty much any ES6 support, you can get around this by using Traceur [1] to compile your ES6 javascript down to ES5, and then using the es6-shim [2] for new ES6 libraries (Promise, etc.)

Given that you'll need to compile dart down to JS for it to run on any browser (including chrome), and given that it seems unlikely Mozilla will ever include a dart VM, I'd say that starting to learn ES6 now is probably a better long-term bet than learning dart. Which isn't to say Dart isn't a nice language...

[1] https://github.com/google/traceur-compiler

[2] https://github.com/paulmillr/es6-shim

[Touche]

I don't see the different between using 1) Using Dart and 2) Using a framework that supports modules. The difference seems to be that Dart has a different syntax that some people might prefer. But the point is that everyone chooses to either use frameworks with JavaScript or chooses to using a compiled language (and probably use frameworks on top of that).

[ulisesrmzroche]

+1, and also, safest place to use es6 right now is on the API side. No need to wait or use the transpiler.

[sethladd]

Can you be more specific about what "API side" means?

[ulisesrmzroche]

Like, when you build an API, (or other backend stuff) you're not concerned about browsers or the DOM - thats really just a delivery mechanism. So you can run --harmony within your own server and have it spit out JSON. Client doesn't know or care what your running, just the JSON.

[sethladd]

Ah, you mean "server side". Gotcha. Yes, building for the server is easier because you have a single runtime to target. In the case of Node, it's V8. In the case of Dart, it's Dart VM on the server.

[ulisesrmzroche]

So what's Dart vs ES6?