Typescript as a language may be more lightweight (i.e fewer features) than C# but the development process feels extremely heavyweight and convoluted in comparison.
Typescript has no standard library. So you have to resort to using JavaScript libraries and combine those with type descriptions written by yet another group of people for some version or other of the original library.
So essentially Typescript is importing JavaScript's already onerous dependency situation putting another set of dependencies on top of it without any formal correctness guarantees or automated compatiblity checks.
The language itself is under constant threat of breaking changes introduced by new JavaScript versions.
The whole setup feels exremely fragile to me and it is anything but lightweight. But I accept that many people are successfully navigating this mess for now, people who (unlike myself) have created actual production software in Typescript.
> So essentially Typescript is importing JavaScript's already onerous dependency situation putting another set of dependencies on top of it without any formal correctness guarantees or automated compatiblity checks.
An increasing number of JS libraries on npm maintain and provide their own Typescript definitions, so the ecosystem is getting better and in some cases there are no additional type information dependencies beyond your JS library dependencies.
> The language itself is under constant threat of breaking changes introduced by new JavaScript versions.
I've used Typescript in production software since around TS 1.0, and Typescript has been very adroit of working ahead of JS versions. The biggest change, and closest to a compatibility break, was that import/export syntax changed slightly to reflect ES module import/export syntax, and that wasn't entirely a breaking change (the old syntax still works, though is marked with a deprecation warning). On the other side there were ES2015 features I was happily using in Typescript years before ES2015 was finalized, and am happily using proposed features that are only Stage 2 or Stage 3 today in the standards process.
Ecma's TC39 is following a similar playbook to the rest of web standards and using an approach to where multiple implementations should be built before the proposal is accepted into the language. TC39 has the benefit that not only do they get browser implementations, but polyfills/prollyfills, Babel, and Typescript implementations to learn from in adopting a proposal.
Typescript very much is leading JS development as much as, if not more than, it is following.
Fair point, however I don't see how the situation will be drastically different for C#. The browser still uses JavaScript and I suspect any C# implementation for the browser will use typescript's definition files anyway.
