But Dart is something else. Dart showed us what JavaScript would have been if it were designed this decade, and with some thought to its architecture. It's clinical in its cleanliness (have a peek at its standard library and you'll agree). It was pitched as a full stack language for web applications done right, and I certainly felt it lived up to that claim.

Personally, I'm more interested in Dart as a replacement for Node.js. Luckily that dream is still alive: "We continue our strong investment in Dart VM for server, embedded, and mobile."

Actually on most of the official benchmarks, dart2js output is slower than normal JS,

https://www.dartlang.org/performance/

(normal JS is faster on 3, matched on 1, and slower on 1).

Of course, the usual caveats apply regarding benchmarks and real-world performance, especially since those 5 benchmarks are fairly small and probably not representative of large real-world codebases. I'm not aware of any good benchmarks for Dart on that (there is a Box2D comparison, but the latest update isn't recent).

And I would be really skeptical about that 1 where they say dart2js is faster.

They removed a layer of indirection in DeltaBlue when they ported it to Dart (not due to any Dart language feature, just for no reason), then crowed about how dart2js made DeltaBlue faster than the original. Despite being made aware of it years ago, they never fixed this! But the JavaScript VMs got better enough to be faster even though running code with more indirection than the dart2js version based on the optimized port.

So when the one benchmark dart2js is faster on is one they say they rewrote because a direct comparison would be "unfair" it sets off alarms.

This claim always bugged me. The output of dart2js is raw JS. Same with CoffeeScript (which makes a similar claim). So these claims are totally reliant on parameters that haven't been defined, ie. what constitutes "equivalent" handwritten code?

I've always assumed claims like this are implying that average case code is written poorly and that's how It could be faster.

However as you point out we'd need all the assumptions made clear to believe such a claim.

In that case, they literally are writing JS and using a compiler to get JS that is faster than any normal handwritten JS would be. You could write your JS that way but it would be completely unreadable and unmaintainable.

In principle, it's always a certainty that JS can be written as performant as Dart, never just a possibility. The possibility part only comes in with respect how optimally the JS code is written.

The interesting part here is I think is how often does this happen? How often can significant improvements be made that would be impractical, or even unlikely for a developer to match?

But is it more performant than raw Dart?

It may be possible to compile pieces of a Dart program that don't need GC (think pure numeric computation stuff) to use asm.js and use the full JS language for the rest, but I don't know if anyone's seriously looked at doing that.