4 ms·

Considering Babel solves most ES2015/2016 needs and has support for flow, what does TS still bring to the table for people who aren't using Visual Studio? Seri

by pluma 11y ago

Considering Babel solves most ES2015/2016 needs and has support for flow, what does TS still bring to the table for people who aren't using Visual Studio? Serious question. I last looked at TS when it had plenty of warts (e.g. verbose metadata to make imports work, no real JS API) and since switched to Babel via JSX+harmony. Flow integrates nicely and seems to be better at understanding implicitly typed (legacy) code, too. TS's main selling points seem to be VS integration and Angular's blessings.

drinchev 11y ago
I don't wanna say that, but a language created by such a large company, which is open-sourced since day one and developed by a team of professionals with a solid research before any lines of code have been written ... sounds a like a big thing on the table for may day-to-day choices in this sea of possibilities.
nawitus 11y ago
You don't need Visual Studio to have automatic refactoring and code-complete. Atom, for example, supports that. TypeScript's benefits include all the generic benefits of type checking.
- pluma 11y ago
  So it brings nothing that babel+flow doesn't do already? The only advantage I seem to find is being backed by MS and blessed by Angular (i.e. Google). Sorry if I sound dismissive. I'm just trying to figure out why so many seem to find TS exciting outside the MS sphere.
  - Guillaume86 11y ago
    Flow is not available on windows, typescript is available on all major OSes.
  - nawitus 11y ago
    TypeScript is probably more refined and has better tooling than Flow as it's a lot older. One could ask what Flow brings to the table.
yareally 11y ago
> what does TS still bring to the table for people who aren't using Visual Studio?what does TS still bring to the table for people who aren't using Visual Studio? It doesn't require Visual Studio. Most major IDEs and some text editors have support either from Microsoft or the developers of the IDE/editor[1]. Also, strict typing (which I consider a huge plus for any long term large project to help make it sane). I think it matters (though maybe not for everyone) that Anders Hejlsberg (of Delphi and C# creation fame) is behind the architecture of the language. > no real JS API Not sure what you mean by that, please clarify. JS notation works fine in it (since typescript is just a super set of JS and typing is optional). If you want to add types to a JS library, you just build an interface for it. Lots of examples of how to do that out there[2]. [1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Editor-Support https://github.com/Microsoft/TypeScript/wiki/TypeScript-Edit... [2] https://github.com/borisyankov/DefinitelyTyped https://github.com/borisyankov/DefinitelyTyped
- pluma 11y ago
  > JS API I mean a JS interface to the transpiler. At the time there was only the CLI, nothing that worked on strings or streams within node code. > IDE support ... strict typing ... Ditto for flow, though.
  - deleted 11y ago
    [deleted]
  - AntiRush 11y ago
    The compiler api has gotten a lot better: https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi... If you just want string->string compilation, there's typestring, which wraps the api: https://www.npmjs.com/package/typestring https://www.npmjs.com/package/typestring
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
Guillaume86 11y ago
I'd like to try flow but it isn't available yet on windows [1] so it's not even an option for me (I'm on windows and I like to keep my things multi-platform friendly if possible). At the moment I'm using babel in Atom and typescript in VisualStudio. [1] https://github.com/facebook/flow/issues/6 https://github.com/facebook/flow/issues/6
Keats 11y ago
Last time I tried flow (maybe 6 months ago?), it didn't work very well for me. I can't remember the details unfortunately. Typescript covers pretty much all the ES6 features that I use while flow is still missing let/const apparently. I only miss async/await and that should be in TS 1.6 so it's not a big deal for me and I believe you should be able to do a TS -> Babel -> ES5 workflow if you wanted by having ES6 as target for TS. For JSX, I prefer using React.DOM anyway but support will be in 1.6 and is already in master. TS main selling point is DefinitelyTyped which means typing for pretty much all the third party code and the fact that it's been out for a couple of years now. A tool to convert .d.ts to flow definition has been on flow short-term todo list since november and without it, flow is not viable for me. TS definitely shines when starting new projects though, it can be a bit annoying on a legacy codebase. (I use Pycharm, not VS and it integrates well in it, minus lagging a bit behind versions)
- pluma 11y ago
  Thanks for the insights. I haven't encountered any issues with third party code myself and don't mind the client/server model, but for me the killer app is Babel support (so flow is only a type checker, not another transpiler). Do imports and import resolution work out of the box in TS these days? Last time I tried, I had to jump through hoops to get it to understand node imports and it wouldn't work without magical comments. I also don't want to have to wrap everything in module declarations -- the import logic of node should be sufficient. If TS has sorted these problems out, it might be worth another look for me.
  - Keats 11y ago
    You just have to declare which external module (3rd party dep) you are using so typescript knows how to apply typings. Ie you can use ES6 imports, you just need to have a /// <reference path="../typings/all.d.ts" /> line or declare them in tsconfig.json now (I believe, haven't checked yet). I agree the modules are tricky and my least favourite thing about TS though
    - pluma 11y ago
chimeracoder 11y ago
> has support for flow I've used both Typescript and Flow. In my experience, Typescript is far superior to Flow. In terms of the sorts of errors they catch, they're about the same. In practice, Flow caught essentially no real errors that Typescript did not, and vice versa. (This is based on my workflow, YMMV obviously.) However, Typescript is installable through NPM and runs as a basic Node module that reads files and parses text when you call it. Flow is written in OCaml, which means it's not available through NPM. This means either installing a separate binary (if one exists for your system) or installing an OCaml compiler so you can compile it from source. Afterwards, Flow uses a client-server setup, which makes it really annoying to run in a headless and automated environment. It's also surprisingly slow; it took a full ten seconds to typecheck a small project the first time. Supposedly the server makes it faster to do repeated checks, but honestly, the Typescript compiler is fast enough that this seems like a solution in search of a problem. Also, Flow would keep getting confused and insisted on typechecking my node_modules. This was a problem because one of my imports had a third-level dependency with syntax error in an unused test, which meant that my entire Flow typecheck would fail. I couldn't add it to the [ignore] section of my ~/.flowconfig, because then Flow would literally pretend the file didn't exist, and then the project wouldn't compile due to missing imports! All in all, I'm sure there's some way to set up flow without running into any of the above issues, but it definitely was way more work to set up (compared to a simple 'npm install'), and for seemingly no benefit whatsoever.

by pluma 11y ago

drinchev 11y ago

I don't wanna say that, but a language created by such a large company, which is open-sourced since day one and developed by a team of professionals with a solid research before any lines of code have been written ... sounds a like a big thing on the table for may day-to-day choices in this sea of possibilities.

nawitus 11y ago

You don't need Visual Studio to have automatic refactoring and code-complete. Atom, for example, supports that. TypeScript's benefits include all the generic benefits of type checking.

pluma 11y ago
So it brings nothing that babel+flow doesn't do already? The only advantage I seem to find is being backed by MS and blessed by Angular (i.e. Google). Sorry if I sound dismissive. I'm just trying to figure out why so many seem to find TS exciting outside the MS sphere.
- Guillaume86 11y ago
  Flow is not available on windows, typescript is available on all major OSes.
- nawitus 11y ago
  TypeScript is probably more refined and has better tooling than Flow as it's a lot older. One could ask what Flow brings to the table.

yareally 11y ago

> what does TS still bring to the table for people who aren't using Visual Studio?what does TS still bring to the table for people who aren't using Visual Studio? It doesn't require Visual Studio. Most major IDEs and some text editors have support either from Microsoft or the developers of the IDE/editor[1]. Also, strict typing (which I consider a huge plus for any long term large project to help make it sane). I think it matters (though maybe not for everyone) that Anders Hejlsberg (of Delphi and C# creation fame) is behind the architecture of the language. > no real JS API Not sure what you mean by that, please clarify. JS notation works fine in it (since typescript is just a super set of JS and typing is optional). If you want to add types to a JS library, you just build an interface for it. Lots of examples of how to do that out there[2]. [1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Editor-Support https://github.com/Microsoft/TypeScript/wiki/TypeScript-Edit... [2] https://github.com/borisyankov/DefinitelyTyped https://github.com/borisyankov/DefinitelyTyped

pluma 11y ago
> JS API I mean a JS interface to the transpiler. At the time there was only the CLI, nothing that worked on strings or streams within node code. > IDE support ... strict typing ... Ditto for flow, though.
- deleted 11y ago
  [deleted]
- AntiRush 11y ago
  The compiler api has gotten a lot better: https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi... If you just want string->string compilation, there's typestring, which wraps the api: https://www.npmjs.com/package/typestring https://www.npmjs.com/package/typestring

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

Guillaume86 11y ago

I'd like to try flow but it isn't available yet on windows [1] so it's not even an option for me (I'm on windows and I like to keep my things multi-platform friendly if possible). At the moment I'm using babel in Atom and typescript in VisualStudio. [1] https://github.com/facebook/flow/issues/6 https://github.com/facebook/flow/issues/6

Keats 11y ago

Last time I tried flow (maybe 6 months ago?), it didn't work very well for me. I can't remember the details unfortunately. Typescript covers pretty much all the ES6 features that I use while flow is still missing let/const apparently. I only miss async/await and that should be in TS 1.6 so it's not a big deal for me and I believe you should be able to do a TS -> Babel -> ES5 workflow if you wanted by having ES6 as target for TS. For JSX, I prefer using React.DOM anyway but support will be in 1.6 and is already in master. TS main selling point is DefinitelyTyped which means typing for pretty much all the third party code and the fact that it's been out for a couple of years now. A tool to convert .d.ts to flow definition has been on flow short-term todo list since november and without it, flow is not viable for me. TS definitely shines when starting new projects though, it can be a bit annoying on a legacy codebase. (I use Pycharm, not VS and it integrates well in it, minus lagging a bit behind versions)

pluma 11y ago
Thanks for the insights. I haven't encountered any issues with third party code myself and don't mind the client/server model, but for me the killer app is Babel support (so flow is only a type checker, not another transpiler). Do imports and import resolution work out of the box in TS these days? Last time I tried, I had to jump through hoops to get it to understand node imports and it wouldn't work without magical comments. I also don't want to have to wrap everything in module declarations -- the import logic of node should be sufficient. If TS has sorted these problems out, it might be worth another look for me.
- Keats 11y ago
  You just have to declare which external module (3rd party dep) you are using so typescript knows how to apply typings. Ie you can use ES6 imports, you just need to have a /// <reference path="../typings/all.d.ts" /> line or declare them in tsconfig.json now (I believe, haven't checked yet). I agree the modules are tricky and my least favourite thing about TS though
  - pluma 11y ago

chimeracoder 11y ago

> has support for flow I've used both Typescript and Flow. In my experience, Typescript is far superior to Flow. In terms of the sorts of errors they catch, they're about the same. In practice, Flow caught essentially no real errors that Typescript did not, and vice versa. (This is based on my workflow, YMMV obviously.) However, Typescript is installable through NPM and runs as a basic Node module that reads files and parses text when you call it. Flow is written in OCaml, which means it's not available through NPM. This means either installing a separate binary (if one exists for your system) or installing an OCaml compiler so you can compile it from source. Afterwards, Flow uses a client-server setup, which makes it really annoying to run in a headless and automated environment. It's also surprisingly slow; it took a full ten seconds to typecheck a small project the first time. Supposedly the server makes it faster to do repeated checks, but honestly, the Typescript compiler is fast enough that this seems like a solution in search of a problem. Also, Flow would keep getting confused and insisted on typechecking my node_modules. This was a problem because one of my imports had a third-level dependency with syntax error in an unused test, which meant that my entire Flow typecheck would fail. I couldn't add it to the [ignore] section of my ~/.flowconfig, because then Flow would literally pretend the file didn't exist, and then the project wouldn't compile due to missing imports! All in all, I'm sure there's some way to set up flow without running into any of the above issues, but it definitely was way more work to set up (compared to a simple 'npm install'), and for seemingly no benefit whatsoever.