[Nemcue]

Sure — I guess it's nice that Dart comes with a lot of useful things built in.

Outside of Dart we already have pretty good solutions for Promises (with Promise A+ compatible libs; Q, RSVP etc) and modules (ES6 modules, Require etc), which /kind of/ makes those points moot.

Which leaves type checking and autocompletion as the big benefit. Which are nice, I guess.

[sethladd]

I've clarified at the bottom of the post that JavaScript is probably going to get some of these features in the future. One of the points I was trying to make was Dart has these features now (and because Dart compiles to JS, it means I can deploy these features now).

The other question we should ask is, why didn't the original author use those new shiny JS features in his app? He's a crazy smart developer. My hypothesis: because the out-of-the-box dev experience doesn't include modules, promises, etc, there's a higher barrier to using the new shiny JS features because the developer needs to first A) know about them B) find the right polyfill.

Thoughts?

[Nemcue]

As a counterweight: I'm not a crazy smart developer, and I use those features. In production. Now.

I'm not going to argue against your point though, because I think you are right. One needs to have some grasp of the JS ecosystem to know what libraries to use. And as I said, it's nice that Dart has made that choice for you.

But that said, poking around a bit in the Dart documentation I think it's interesting that "Futures" are seemingly /not/ entirely interoperable with the de facto standard of Promises (A+) in JS.

[sethladd]

I don't know enough of the intimate details of Promises to know if Future == Promise. I hope I didn't make it sound like Future == Promise, but I do think they are quite similar in intention.

Can you expand on why you think Futures aren't entirely interoperable with Promises? Also, which specific implementation of promises? (what's the link to the promises that you're talking about?)