http://wiki.ecmascript.org/doku.php?id=strawman:bignums
from 2010 (before the Dash memo leaked, before dherman or anyone on TC39 not from Google, and probably any of the folks from Google for that matter, knew that Dart had `int` as bignum).
With V8 jumping in, you bet that they'd have been implemented in at least V8 and probably SpiderMonkey -- just as many ES6 features proposed since then have been:
http://kangax.github.io/compat-table/es6/
Did you know about these precedents? Serious question. I'm not citing total what-ifs here: we did have bignums on the agenda, but we lacked a V8-level champion; we did -- we the various JS engine implementors -- implement a lot in the last few years.
No intuition is required to say that VM isolate snapshotting (if that's truly needed to deal with massive gmail-level cold-code on first load; I see other solutions) could be added to JS if it could be done for Dart. Lars Bak tried asserting no-way-in-JS because of the notorious JS global object. I say: never say never, opt-in is the way the web evolves. The global object is being ring-fenced by ES6 modules and new binding forms.
This is not a difference of opinion, it's a matter of choice and funding.
Also not flamebait: my point about JS not going away. You switched from "Dart does good for the Web via (eventual) JS uplift" (paraphrasing), to "Dart just needs to provide good development tooling", seemingly in response to my pointing out that there hasn't been much uplift over five years.
What's with the goalpost moving, and in a weak direction to boot? You were very much on target citing SIMD flowing from Dart to JS, thanks to John McCutchan, to whom I tweeted the idea when I saw his tweet about Dart SIMD:
https://twitter.com/BrendanEich/status/308343704194781186
John replied that he was going to look at JS SIMD next.
So thanks to me too -- this Dart => JS transfer was not as far as I can tell on the Dart leaders' agenda, it was bottom up work by John. After our twitter exchange, Mozilla and Intel joined in.
The `for (let...)` binding per iteration semantics in ES6 did not come directly from Dart. We'd been working on it for a while in TC39. Here's a note from me about it (find "binding per iteration") from 2009:
http://wiki.ecmascript.org/doku.php?id=harmony:let
It helped to have Dart do it, in the "moral support" and "evidence it is worth the spec/impl complexity" senses. But there was no tech transfer or direct causation.
Don't get me wrong, Google cannot spend tens of millions on top talent and make something of zero value. My point about opportunity costs stands. We could have come a lot farther, faster. This is true now as it was in the IE monopoly era (no, I'm not saying things are as bad, just that the hazard of doing WPF or Dart instead of working more directly on the Web stack remains).
Complaining about JS as a backward-compatibility-constrained language, to support the idea that JS uplift needs expensive, separate "REPLACE JS" alterna-language/runtime projects such as Dart, which inevitably -- because you can't replace JS, flamebait trigger warning LOL -- backpeddle to compile-to-JS tooling and tardy tech transfer into ECMA-262, doesn't justify the opportunity cost.
There are better ways to improve the system we're stuck with, sooner. I'm not religious about this, nor are the V8 folks now working in earnest on SoundScript. You're seeing more of what I'm advocating, finally. It wasn't in evidence for too many years.