Care to elaborate on that?
As for the rest of your comment, I'm with ya. I guess they're reasoning behind that was they thought a lot of development would start out untyped with additional types added as development progressed. I think that assumption didn't pan out, at least that's not how I do it.
Official answer from https://www.dartlang.org/faq:
"Q. But don’t you need sound typing information to get high performance?
Sound types can help with performance but aren’t essential. What we need are uniform, simple semantics. Modern VMs can use actual runtime behavior as a valuable signal for optimizations."
I'm not the OP, but TypeScript supports union types (A | B ; a type that can be either type A or type B) and intersection types (A & B ; a type that is both A and B), while Dart doesn't. https://www.typescriptlang.org/docs/handbook/advanced-types....
Typescript also has structural types, like Go and OCaml, which many people find nicer than nominal types. Structural types mean if I have an interface Blaz with two methods Foo and Bar, if I have an object MyObject with Foo and Bar methods of the same types then my object counts as a Blaz, while nominal types mean I have to write something like MyObject extends Blaz.
If I were aiming to replace JS, I'd fix what Dart does, but I wouldn't stop with merely fixing what Dart does.
Dart, despite being an entirely new language, has a less expressive type system than TS. It's transpiler (and it's VM) also does no optimisation based on the type system, instead heavily relying on the JIT to infer what the types already imply (e.g., it would be nice to do things like LICM at compile-time).