3 ms·

TypeScript isn't competing with Flow, it's also competing with Babel. I still don't understand why MS keeps wasting energy on implementing ES.next features in t

by pluma 11y ago

TypeScript isn't competing with Flow, it's also competing with Babel. 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. I understand why it started that way but even FB stopped using their own transpiler (JSX) once Babel gained traction.

lukasm 11y ago
because TypeScript is a super set of ES.
- pluma 11y ago
  That would have been an argument when Babel was still 6to5. Babel supports all kinds of extensions to ES including ES proposals and extensions like JSX or type annotations.
MasterScrat 11y ago
> 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.
Keats 11y ago
You can use TypeScript just for the types and hand the es6 files to Babel after. Also TypeScript existed before Babel and there are some features not supported by Babel (modules, public/private). See this issue for more details https://github.com/Microsoft/TypeScript/issues/1641 https://github.com/Microsoft/TypeScript/issues/1641
- pluma 11y ago
  That issue is back from when Babel was still called 6to5. Babel didn't support JSX, decorators or type annotations. Now it does. Babel 6 is even more modular, lending itself even more to extension than Babel 5 did before. There's nothing stopping MS from adding TS extensions to Babel.
  - Keats 11y ago
    I'm guessing Microsoft is not keen on starting from scratch for no visible benefits for them. You could try opening another issue to see if they changed their minds though

by pluma 11y ago

lukasm 11y ago

because TypeScript is a super set of ES.

pluma 11y ago
That would have been an argument when Babel was still 6to5. Babel supports all kinds of extensions to ES including ES proposals and extensions like JSX or type annotations.

MasterScrat 11y ago

> 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.

Keats 11y ago

You can use TypeScript just for the types and hand the es6 files to Babel after. Also TypeScript existed before Babel and there are some features not supported by Babel (modules, public/private). See this issue for more details https://github.com/Microsoft/TypeScript/issues/1641 https://github.com/Microsoft/TypeScript/issues/1641

pluma 11y ago
That issue is back from when Babel was still called 6to5. Babel didn't support JSX, decorators or type annotations. Now it does. Babel 6 is even more modular, lending itself even more to extension than Babel 5 did before. There's nothing stopping MS from adding TS extensions to Babel.
- Keats 11y ago
  I'm guessing Microsoft is not keen on starting from scratch for no visible benefits for them. You could try opening another issue to see if they changed their minds though