3 ms·

> I still don't understand why MS keeps wasting energy on implementing ES.next features in their transpiler when there's already an established modular open sou

> I still don't understand why MS keeps wasting energy on implementing ES.next features in their transpiler when there's already an established modular open source solution available. Isn't this like asking why there still are people "wasting energy" on promise libraries now that several well-established ones exist? Isn't it good for us developers to have more choice?

pluma 11y ago
The problem is that using TypeScript locks you into TSC. TypeScript solves one fairly specific problem: adding type annotations and static type checking to JavaScript. In this regard it competes with Flow. But unlike Flow it ships its own transpiler. So if you want support for any new feature you have to wait for the TypeScript team to implement it or you have to abandon TypeScript altogether. Compare this to how Facebook dealt with JSX. JSX solved one fairly specific problem: adding syntactic sugar for nested `React.createElement` calls. Facebook used to provide their own JSX transpiler with support for various experimental features. This had the same problems as using TSC does now. So instead they just replaced their transpiler with Babel using the JSX plugin. In other words, no matter what new features other plugins add to Babel in the future, JSX only has to deal with transpiling JSX. It's not about diversity, it's about separation of concerns. TSC is for TypeScript primarily but it makes things messy by adding all kinds of unrelated crap it has to support to compete with Babel. That creates a lot of potential for subtle differences and bugs. I'm not talking about the features TypeScript adds, specifically. The ES proposals are likely going to end up in the ES standard eventually (unless they are dropped in which case you likely don't want to be using them anymore anyway), translating "future ES" to "current ES" (or "previous ES" as most Babel plugins produce code that works fine in ES3 environments) is an entirely separate problem from translating "proprietary extension X" (like JSX or TS) to some flavour of ES. But that's the crux of the problem, really: TS isn't intended to be an extension to ES. It's conceived as an entirely separate language that just shares a common subset. It diverged after ES5 and carried on separately. It belongs in the same category as CoffeeScript or LiveScript or ClojureScript, not the same category as JSX or Flow.
- jbrantly 11y ago
  You don't actually have to use the transpiler features of TypeScript if you set `--target` appropriately. And Flow has the same problems regarding language features. Flow doesn't just magically understand all JS features now and forever. When new stuff comes out it has to be added to Flow, same with TypeScript. Edit: To be clear though, I agree with you about the TS transpiler. I think TypeScript's strength is in its static type checking, not in its transpiling.

pluma 11y ago

The problem is that using TypeScript locks you into TSC. TypeScript solves one fairly specific problem: adding type annotations and static type checking to JavaScript. In this regard it competes with Flow. But unlike Flow it ships its own transpiler. So if you want support for any new feature you have to wait for the TypeScript team to implement it or you have to abandon TypeScript altogether. Compare this to how Facebook dealt with JSX. JSX solved one fairly specific problem: adding syntactic sugar for nested `React.createElement` calls. Facebook used to provide their own JSX transpiler with support for various experimental features. This had the same problems as using TSC does now. So instead they just replaced their transpiler with Babel using the JSX plugin. In other words, no matter what new features other plugins add to Babel in the future, JSX only has to deal with transpiling JSX. It's not about diversity, it's about separation of concerns. TSC is for TypeScript primarily but it makes things messy by adding all kinds of unrelated crap it has to support to compete with Babel. That creates a lot of potential for subtle differences and bugs. I'm not talking about the features TypeScript adds, specifically. The ES proposals are likely going to end up in the ES standard eventually (unless they are dropped in which case you likely don't want to be using them anymore anyway), translating "future ES" to "current ES" (or "previous ES" as most Babel plugins produce code that works fine in ES3 environments) is an entirely separate problem from translating "proprietary extension X" (like JSX or TS) to some flavour of ES. But that's the crux of the problem, really: TS isn't intended to be an extension to ES. It's conceived as an entirely separate language that just shares a common subset. It diverged after ES5 and carried on separately. It belongs in the same category as CoffeeScript or LiveScript or ClojureScript, not the same category as JSX or Flow.

jbrantly 11y ago
You don't actually have to use the transpiler features of TypeScript if you set `--target` appropriately. And Flow has the same problems regarding language features. Flow doesn't just magically understand all JS features now and forever. When new stuff comes out it has to be added to Flow, same with TypeScript. Edit: To be clear though, I agree with you about the TS transpiler. I think TypeScript's strength is in its static type checking, not in its transpiling.