[isoos]

Your worries about being locked in may have been valid 2-3 years ago (1), but things have changed a lot since:

Dart has an ongoing project (Dart Developer Compiler) which has a goal, among others, to produce readable, idiomatic EcmaScript 6. That is as close to your TypeScript fallback as it can get. (2)

Somebody also demonstrated Dart to LLVM compilation is possible. The language has a decent library for parsing the Dart sources, worst case, if you are that heavily invested in your product, you could also write something that does transpile your codebase. I did try to do it on small scale and specific examples, it is actually not _that_ hard to do, if my business relied on it, it would be certainly within reach.

(1) I'm not sure if you can call it lock-in as it is entirely open source, you can fork it, build it for yourself, change it if you have special needs. The same goes for perl, php, python, go, whatever language you prefer. Yeah, most people don't do it. Why? Because most people don't need it. If you become Facebook-size, it may look better to invest in the PHP toolchain and VM than in transpilers. YMMV.

(2) From the pure technical point of view, I wouldn't call it reassuring that the default fallback platform is JavaScript for so many people (even on the server-side). It is sure depressing that we are stuck with "1" == 1 and wrong ordering of "[1, 2, 10].sort()" for as long as we fall back to JS, and TypeScript does not improve on it.

[throwawaydbfif]

I didn't know of the developer compiler, when that reaches production I won't have any real citicism of Dart.

For now Js fallback is the only realistic option for running code on the web. Even if we get native typescript or dart support tomorrow we will still need to put up with JavaScript for like 7-10 years. For this reason a readable JS fallback seems like a vital feature to me at least. It's depressing but reality for the majority of web projects.

Does dart have a pluggable compiler framework similar to Roslyn or Antlr AST's? That would make it a lot easier to write your own conversions.

One more point in Typescipt's favor though... It would be a lot easier to modify the JS VM in browsers to support native typescript than dart. In my mind it's a lot more likely to happen because of this(less work)

[munificent]

> when that reaches production I won't have any real citicism of Dart.

It's still got bugs, of course, but we have internal customers working on real projects using it on a daily basis.

I agree totally that picking a language is a huge commitment and you want to do that with an organization (company, standards committee, group of open source hackers, whatever) that you trust.

Google is a huge company and has done lots of good and bad things, so it's easy to find enough evidence to support assertions that we should or shouldn't be trusted based on whichever view you want to demonstrate.

One way I look at it is that instead of answering the absolute question "Can I trust Google to shepherd the language well?", consider the relative question "Can I trust it to shepherd the language as well or better than the maintainers of other languages I might choose?"

Assuming you've got some code to write, you have to pick some language, so the relative question is probably the pertinent one. I hope that we on the Dart team are a trustworthy pick, but different reasonable people have different comfort zones.

> Does dart have a pluggable compiler framework similar to Roslyn or Antlr AST's?

All of our stuff is open source[1], including all of our compilers and the libraries they are built on. Most of it isn't explicitly pluggable because plug-in APIs are hard and Dart in particular doesn't do dynamic loading well.

But it's all hackable, and much of it is reusable. In particular, the static analysis package[2] that we use in our IDEs also exposes a set of libraries for scanning, parsing, analyzing, etc. that you can use.

[1]: https://github.com/dart-lang/sdk [2]: https://github.com/dart-lang/sdk/tree/master/pkg/analyzer

[isoos]

Yes, Dart has similar constructs (kernel for low-level parts, and AST and analyzer for high-level parts).