There are many nice modern languages that compile to JavaScript. Personally, I like [Haxe](https://haxe.org/), which compiles to many other target platforms/languages as well.
I'm all for more new and innovative languages, but I think the key thing about TypeScript is not that it compiles to JavaScript, but (to quote basarat's great free book[1]) that "TypeScript is just JavaScript with docs".
TypeScript is a strict superset of JavaScript, so all our real-world JavaScript is TypeScript already — you can literally just change the file extension from .js to .ts.
Now, our existing JS code probably isn't great TypeScript, since it doesn't leverage those great machine-and-human-readable docs (the type system).
So, compared to code written from the beginning with TypeScript, our existing code doesn't go as far toward reducing the likelihood that we humans miss something while programming, and introduce a bug. And we probably won't get all the automated assistance that we could be getting from our machines, in terms of auto-complete, as-you-type errors and warnings, automatic imports, etc.
But for projects coming from JavaScript, it's hard to overstate the importance of being able to start from a place where all your existing code works like it always has, and you can choose the right mix of when/if to upgrade your legacy JavaScript code to TypeScript.
I think that design decision is probably the key to TypeScript's explosive adoption and popularity. A lot of languages could give you strong typing, and the increased code correctness and massively improved tooling that comes along with that — but I don't know of any others that literally require no code changes to start adopting them.
Of course, the choice to remain a superset of JavaScript does place some significant limitations on what kinds of cool improvements TypeScript can add. It can't break JavaScript code so lots of cool things one might imagine won't be possible. Still, a great tradeoff IMO.
My own understanding is that a few persons have made comments or blog posts along the line of, "Look at this convoluted edge case I created of valid JavaScript that isn't valid TypesScript! Ha! Gotcha!"
There may be some cases like that (though I've never seen one in the real world, since I started working with TypeScript three years ago). And there have been and will be more bugs in TypeScript and its compiler, etc.
Such claims might be true in some pedantic sense, but aren't really meaningful unless you are in some kind of internet flame-war thread on Reddit or something.
In the real world, for the purposes of writing software, Microsoft's claim[1] that "TypeScript is a typed superset of JavaScript" is generally true.
EDIT: Maybe I shouldn't have said "strict" superset. That might have just been me accidentally editorializing.
EDIT 2: After reading the post you linked, and its (good) comment thread, I understand where he was coming from, but as he notes in his update at the top, it mainly boils down to different interpretations of what "superset" means in this case. I think in the end his assessment is the same as mine above.
Thanks for the share! That's a great one that I will read into more, but I do want to add while TS isn't perfect. I think one of the biggest advantages has been community buy-in. A language like TS would be no where if the community wasn't adopting it and increasing its adoption through network effects. If you use TS and include a library that is written in TS, there's a huge advantage to having accurate typings. Many libraries that don't use TS and add typings later usually have conflicting community provided types.
I think a list of highly adopted libraries written in TS would be great. One I recently realized was TS is immutable.js!
TypeScript is a strict superset of JavaScript, so all our real-world JavaScript is TypeScript already — you can literally just change the file extension from .js to .ts.
Now, our existing JS code probably isn't great TypeScript, since it doesn't leverage those great machine-and-human-readable docs (the type system).
So, compared to code written from the beginning with TypeScript, our existing code doesn't go as far toward reducing the likelihood that we humans miss something while programming, and introduce a bug. And we probably won't get all the automated assistance that we could be getting from our machines, in terms of auto-complete, as-you-type errors and warnings, automatic imports, etc.
But for projects coming from JavaScript, it's hard to overstate the importance of being able to start from a place where all your existing code works like it always has, and you can choose the right mix of when/if to upgrade your legacy JavaScript code to TypeScript.
I think that design decision is probably the key to TypeScript's explosive adoption and popularity. A lot of languages could give you strong typing, and the increased code correctness and massively improved tooling that comes along with that — but I don't know of any others that literally require no code changes to start adopting them.
Of course, the choice to remain a superset of JavaScript does place some significant limitations on what kinds of cool improvements TypeScript can add. It can't break JavaScript code so lots of cool things one might imagine won't be possible. Still, a great tradeoff IMO.
[1]: https://github.com/basarat/typescript-book