I'm not sure what you mean by "not JS compatible" here.

TypeScript obviously compiles into JavaScript, and any valid JavaScript is also "valid" compilable TypeScript (the compiler will complain, but it will still compile it into JavaScript that does the same thing). With the right assertions (and @ts-ignore where necessary), you can even get the compiler to stop complaining!

TypeScript does have some differences beyond just type annotations: namespaces and enums come to mind. But it's easy enough to just not to use those features - they're not even supported by Babel.

The main downside is that you have a compile step where you might not have had one before. And it can be frustrating to deal with situations where there's no way to "fix" an error except by suppressing it – but these are really rare. But these are relatively minor issues.

Also, even namespaces and enums aren't that foreign, and are still "JS compatible" in that they transpile to perfectly normal JS code that you can still use quite obviously in other JS code (enums create a list of constants and sometimes a reverse lookup map; namespaces create ugly, nested, mergeable object literals and IIFEs just like Grandma jQuery used to bake back in the bad old days before module systems). From one point of view they are nothing but syntactic sugar for common JS patterns.

There is a significant difference between TS and a non-standard anything. Nothing goes into typescript until it is stage 3, meaning intent to ship. There is now two compilers supporting the syntax. It is well supported.

Also, if that was a concern I would be willing to say we start out with jsdoc style types - I would much prefer the regular syntax and would like to use things like enums, but it would be a massive improvement over not having it.

In my mind, you are writing javascript with types whether you use typescript or not - using TS makes those types explicit and allow a compiler to check your work, on top of the other benefits.

I will rephrase though - instead of "there are no downsides" I'll say "Any downsides I have found are minute in comparison to the benefits", but my intent behind bringing this up in the first place is to hear from anyone else who does see more downsides than I do and to understand those.

You're wrong.

Once you transpile the TS, you have standardized ECMAScript. Want to stop using TS? No problem. Just delete your TS files and work from your JS files.

And, beyond that, TS is intended to be a superset -- never incompatible, just "extra".

Finally, you can use TypeScript the same way Flow is used, through comments.

Tying yourself to TS isn't really something you can do, and there's zero risk in using it. You can always throw it out later.

> No problem. Just delete your TS files and work from your JS files.

This is quite an irresponsible comment.

The JS code generated isn't really meant for editing especially if you used a feature that isn't present on the runtime (like async/await in browser), not to mention all the formatting is rearranged.

If you're willing to go back to JS, you want to keep the original source.

"Irresponsible" is a bit of an overstatement, don't you think? The TS team explicitly says their goal is to generate readable JS, unlike (for example) Clojure or Scala.

Also, the async/await thing isn't an issue if you target the latest ECMAScript version. That's the only really ugly thing, and it's been easily avoidable for over a year.

Readable JS doesn't mean, convert back to the file in the format you used to for editing.

That comment could make people throw away the original and end up with machine generated code when going back.

Have you read transpiled TS before? It's sometimes almost identical to the source. It's as close as you can get to just removing the static typing. Variables have the same names, for example.

I used to have a problem where I'd be debugging the JS instead of TS file because visually, they were almost identical.

Have you seen the code the TS compiler spits out?

You do not want to work on that. It readable to an extent, but it's definitely not pleasant.

I don't think you could just go back.

If you're referring to generator-style async/await, you can change that now.

Otherwise you can just prettify it and be on your way.

Sure you don't want to go back, but that's the whole reason TS exists: writing JS with good organization and discipline is impossible at worst, full of boilerplate at best.

TypeScript and Flow are very similar. Compilation of both of them mainly consists of removing type annotations. TypeScript has a few extra things it adds but they're very minor and not that hard to translate into Javascript.