[rst]

And yet, oddly, one of the front-page testimonials for node.js is LinkedIn saying that use of that particular brand of server-side Javascript gave them "huge performance gains". That obviously doesn't mean that Node (or Javascript in general) will perform well in every situation, but it does show at least an existence proof that JS is capable of high performance in some very demanding environments.

What I haven't seen out of the Dart project, so far, is a description of what performance targets they're trying to meet, why they think that no set Javascript extensions (e.g., the "freeze" proposals for Harmony) would suffice to meet those targets, and why they think that any of this is relevant to people whose needs _are_ adequately met by Javascript as it stands.

[georgemcbay]

So your justification for Dart being unnecessary is that the Javascript interpreter built by the people who are building Dart is really fast (for a Javascript engine)?

Don't you think that building V8 (the engine inside Node) may have given them some very good insight into the upper bounds of Javascript performance and insight into ways to fix them?

[rst]

If v8 is fast enough for anything that I might want to do with it, further performance improvements (as opposed to other changes) are not going to be really high on my wish list. That's why the performance case doesn't work for me.

Other people might have different tradeoffs, of course. Which is fine. But nothing I've seen the Dart crew say yet explains in plain English who those people might be, and why the particular set of tradeoffs in Dart is better for them than either v8 or, say, some other language reduced to strongly typed bytecode for PNaCl.

[zoips]

They haven't reached them, that much is obvious since Lua is every bit as dynamic as Javascript and LuaJIT is orders of magnitude faster than V8.

[ootachi]

The other browser vendors have built fast JavaScript engines as well, and they seem to think that Dart is unnecessary.