Dart2js is not conformant. You could, maybe, twist the meaning of the spec this way, but it goes against the spirit of the sentence and the spec.
Tbh we never implemented a fully compliant dart2js backend. We have seen how slow the output is when some of our optimizations don't trigger (i.e. when we have bugs) and numbers are not correctly inferred.
Eventually we would like to give it a try, but there are much more important and useful issues we want to fix first.
In practice, numbers are a surprisingly small problem. Programmers have learned to look out for big numbers, and, while a nuisance, they are rarely the source for bugs.
So there's not an urgency to make dart2js conformant, it sounds? I can understand if there's lots of other stuff to do, yeah - I suppose I am only surprised because the language is at version 1.5 and has a full spec, which could be my fault for assuming that meant it was more "finished" (by some vague meaning of the term).
I am still worried about numbers, though. Yes, programmers mostly know about this stuff, but rare and hard to debug issues are the concern when you have different numeric types than expected, in my experience (for example, in pyjamas, emscripten, etc.).
With the exception of numbers we should be conformant (and if we aren't please file a bug). A fully compliant dart2js would be theoretically nice, but practically mostly useless (because of its speed).
The Dart language and its spec are independent of dart2js (which is just an implementation striving to implement the spec). Clearly there is a huge connection between both (same team, ...), but in the end we decided to accept the non-conformance for the benefit of a better language. On the server Dart developers can already enjoy the more complete number-hierarchy, and, even if it takes time, I still have the hope that client-side we will eventually be able to enjoy Dart VMs everywhere. (Call me "optimist" ;)
Wrt debugging: the VM has a mode where it detects incompatibilities. For example when a number exceeds the 53bits of JS. This should reduce the difficulties in developing cross-platform tremendously.
I prefer not to give any numbers (not even ballpark). It is extremely dependent on the benchmark, the JS engine, execution order (which function is optimized first, and/or inlined, ...).
Things get more complex if you want to implement the double/integer distinction that exists in Dart. That would either require to box integers or doubles, or to come up with some kind of tagging.
Dart2js is not conformant. You could, maybe, twist the meaning of the spec this way, but it goes against the spirit of the sentence and the spec.
Tbh we never implemented a fully compliant dart2js backend. We have seen how slow the output is when some of our optimizations don't trigger (i.e. when we have bugs) and numbers are not correctly inferred.
Eventually we would like to give it a try, but there are much more important and useful issues we want to fix first.
In practice, numbers are a surprisingly small problem. Programmers have learned to look out for big numbers, and, while a nuisance, they are rarely the source for bugs.