From the language goals
> 4. Emit clean, idiomatic, recognizable JavaScript code.
https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
I love Dart personally and I mostly see it’s compile to nonsense looking code as a feature not a bug because it’s an ACTUAL compilation step worked on by ex Chrome team members who understand V8 internals not just code splitting and running terser over it and calling it a day. Want to get the same compilation optimisations that Google uses to run all of their multi billion dollar ad business? Cool, that’s enabled by default out of the box. [1]
The part where Dart on the web falls over for me is that they have shitty support right now for modern web APIs. They are building against some ancient version of Chrome’s WebIDL files so you can totally forget about things like web components for example.
So in that sense it doesn’t feel like a sensible choice in 2022 for basic web development which is a shame because it’s otherwise probably the best developer experience I’ve ever seen.
[1] I say this somewhat theoretically, I don’t know that Dart is in anyway an obvious thing to point to in terms of web performance from what I had seen casually. I think their goal there you can write huge business critical applications with stupidly large code bases and still get good performance. But nobody’s experience after using Google Ads is to talk about how snappy it was.
It's to increase adoption. Some people still remember migrating to coffeescript and away from it. It's in line with tsc accepting regular JS files, the degrees of strictness, things like that. Typescript is optimized to be adopted by the maximum number of people, which in turn increases its usefulness, the feedback they can get, their influence on JS. People are going to write bindings for popular libraries, even migrate them.
Some other people (like at my job) have some people use typescript, and others the generated code. It makes debugging and reasoning about code easier.
As for Dart, I'm not really convinced. The language seems to have the same philosophy as Go (incremental improvement over old technologies), and while for Go it works because Go is relatively "low level" (lower than Dart), for Dart it's just weird.
Im making the argument that JavaScript is a target that we have all been collectively forced into due to the limitations of the web as a platform but short to medium term horizon that is changing where things like WASM are maturing and will let a lot of new options flourish (.NET folks seem to be probably leading this charge currently)
But just stopping to think about the implications of that kind of changing landscape and what’s coming, I don’t think aiming for 100% JS interop not just from a code perspective but it also the entire tooling and developer ecosystem perspective is going to be as important.
Again, I just think people are somewhat forced to at the moment because the web has always been a one language show. That wasn’t because JS was the best choice but rather a limitation of the platform itself which is already in the early stages of changing.
For Dart specifically I kind of get what you’re talking about I guess because it’s pretty commonly referred to as the best bits of JS and Java put together while ditching the worst parts of each so it’s clearly aimed at productivity for application sized code bases rather than something low level but again… that’s literally why they have a proper complication step because getting it down to something a lot more low level is exactly what a compiler is for. That doesn’t feel weird to me at all, that actually feels like an incredibly sensible choice.
