> I think the Dart team made all the right moves
They did do a lot right. But two big things that hampered adoption, I suspect, are
* Working on Dart in secret for a while and unintentionally revealing it to the world in a leaked email. This made it look threatening from day one, since the email seemed to imply covert plans to replace JavaScript. The impression may have been partially wrong, but given those circumstances, there was a negative initial impression.
* Intending to ship the Dart VM in Chrome, despite no interest - and some opposition - in standardization from all other vendors. That worried a lot of people in the web community, both because of policy reasons (vendors shouldn't ship that way; it's even against Google's own Blink principles) and technical reasons (the intent was to polyfill in other browsers, but semantic differences - e.g. in numeric types - meant that was risky). In the end Google didn't ship the VM, despite years of massive efforts towards doing so, but the damage was already done.
And some more minor things that I think were problems as well:
* Dart's syntax looked "Java-esque" to many people. Java isn't in fashion anymore. Yes, the goal was be a familiar and natural language, but it achieved that goal primarily for Java devs. Which is a large group inside Google, of course (hence other projects like GWT and Closure Compiler), but in the larger web dev community, "looking like Java" is a downside.
* The already-mentioned semantic differences on numeric types between the VM and the polyfill. Calling it "undefined behavior" excuses the difference, but the risk of web compatibility remains - undefined behavior makes more sense for a source language like C or C++, where you ship binaries, and not for the shipped code, especially on
the web. As far as I know, this was never resolved, because harmonizing those semantics had too much of a perf hit, despite attempts to optimize things. Perhaps there was too much optimism in early days that this could be achieved.