3 ms·

So today is typed JS day? https://i.imgur.com/XAEeEFm.png https://i.imgur.com/XAEeEFm.png Guess it's time for the question then... I haven't dived into this wh

So today is typed JS day? https://i.imgur.com/XAEeEFm.png https://i.imgur.com/XAEeEFm.png Guess it's time for the question then... I haven't dived into this whole types thing yet so could someone provide a TLDR about either Flow or TS being opinionated and their impact on an established toolchain? I have no intention of changing half of my tooling just to be compatible with what fb thought would be a good idea, and even less so for ms. A build step is required, I take it, but that's not a problem. Would I be able to use old libs and build tools? Are there properly working code formatters for both? What about editor support (Sublime)? I also understood that TS is a superset of ES6, what is Flow's relationship with ES6+?

TheCoreh 10y ago
They both aim to be JavaScript supersets, so in theory all your code should already work. In practice some of the things you're currently doing will probably upset the type checks. Nothing particularly hard to fix, and you could only use them on new files, or move files over gradually. If you're targetting ES5 with Babel, you can have TypeScript output ES6, and then pass that through babel. All libs should work fine, but you will not get all the benefits of the type checking if you don't install type definitions for them (some libs already come with those, though). There really isn't a lot to lose. If you ever feel like it was not a good fit for your project, you can run your code though TypeScript, targetting ES6, and it will produce pretty much the same code without the type annotations.
chadaustin 10y ago
I haven't used Flow (we actually couldn't get it to work with our build system in a few days and gave up, because TypeScript was easy). We integrated replaced Babel with TypeScript in about one day, and ported the entire codebase from ES6 to TS in about two or three days. The code looks almost identical except for the type annotations, which we were documenting in comments anyway. Also, you can pretty much switch right back to Babel if you want, since Babel will ignore type annotations. Editor support for TS is amazing. Both Atom and VS Code have great autocompletion and live typechecking as you edit. Build times with TS are okay. Our codebase rebuilds with ts-loader in webpack within something like 4 seconds upon saving. I'd prefer half a second of course. We have had no problem using any existing JS code. You can provide type annotations or not, but you don't have to. We use React, moment.js, underscore, jQuery. All the major libraries have type bindings. We also use some internal CoffeeScript libraries and occasionally bother providing type bindings, but usually not. In short, TypeScript is great and if you're going to adopt ES6 you might as well adopt TypeScript too.
smt88 10y ago
> Flow or TS being opinionated Neither is opinionated. They have some pretty uncontroversial (similar to other popular languages) typing on top of JS, and it's all opt-in. If there's something you don't like, you don't have to use it. > and their impact on an established toolchain? I don't know about Flow, but TypeScript is very easy to integrate into an existing chain. If you're using something like Gulp, there is a pure JS library that you can call to transpile your TS into JS. If you use Babel, you can simply insert the TS->JS transpilation before you call Babel. TypeScript has an executable called tsc that you can use to transpile your TS whenever the file is changed. You can use that, and then your tool chain doesn't even have to change at all. (Automatic TypeScript transpilation is built into WebStorm and easy to add to VS Code.) > I have no intention of changing half of my tooling just to be compatible with what fb thought would be a good idea, and even less so for ms. In my limited experience, TS is much more polished than Flow is. The tooling is mature, debugging works well, and the language is rapidly improved. It's not just MS using it -- Google also uses it, and some other larger companies. > A build step is required, I take it, but that's not a problem. Would I be able to use old libs and build tools? Anything (and I mean anything) you do with JS, you can also do with TS. It's a superset of JS and compiles to readable, idiomatic JS. > Are there properly working code formatters for both? WebStorm has mature formatting for TS, but there's also tslint if you want some additional error-checking. WebStorm has first-class support for TS, including integration with tslint. > What about editor support (Sublime)? No idea about Sublime, but WebStorm support is absolutely fantastic. Excellent debugging, hints, linting, and completion. VS Code is great, but it lacks some of the more niche-y features of the IntelliJ platform. Some people might not care, and VS Code will do everything they want.
illektr1k 10y ago
Sublime TS support is top notch https://github.com/Microsoft/TypeScript-Sublime-Plugin https://github.com/Microsoft/TypeScript-Sublime-Plugin
natmaster 10y ago
Flow is not a superset of any form of javascript. It is another language. See: https://github.com/facebook/flow/issues/825 https://github.com/facebook/flow/issues/825

TheCoreh 10y ago

They both aim to be JavaScript supersets, so in theory all your code should already work. In practice some of the things you're currently doing will probably upset the type checks. Nothing particularly hard to fix, and you could only use them on new files, or move files over gradually. If you're targetting ES5 with Babel, you can have TypeScript output ES6, and then pass that through babel. All libs should work fine, but you will not get all the benefits of the type checking if you don't install type definitions for them (some libs already come with those, though). There really isn't a lot to lose. If you ever feel like it was not a good fit for your project, you can run your code though TypeScript, targetting ES6, and it will produce pretty much the same code without the type annotations.

chadaustin 10y ago

I haven't used Flow (we actually couldn't get it to work with our build system in a few days and gave up, because TypeScript was easy). We integrated replaced Babel with TypeScript in about one day, and ported the entire codebase from ES6 to TS in about two or three days. The code looks almost identical except for the type annotations, which we were documenting in comments anyway. Also, you can pretty much switch right back to Babel if you want, since Babel will ignore type annotations. Editor support for TS is amazing. Both Atom and VS Code have great autocompletion and live typechecking as you edit. Build times with TS are okay. Our codebase rebuilds with ts-loader in webpack within something like 4 seconds upon saving. I'd prefer half a second of course. We have had no problem using any existing JS code. You can provide type annotations or not, but you don't have to. We use React, moment.js, underscore, jQuery. All the major libraries have type bindings. We also use some internal CoffeeScript libraries and occasionally bother providing type bindings, but usually not. In short, TypeScript is great and if you're going to adopt ES6 you might as well adopt TypeScript too.

smt88 10y ago

> Flow or TS being opinionated Neither is opinionated. They have some pretty uncontroversial (similar to other popular languages) typing on top of JS, and it's all opt-in. If there's something you don't like, you don't have to use it. > and their impact on an established toolchain? I don't know about Flow, but TypeScript is very easy to integrate into an existing chain. If you're using something like Gulp, there is a pure JS library that you can call to transpile your TS into JS. If you use Babel, you can simply insert the TS->JS transpilation before you call Babel. TypeScript has an executable called tsc that you can use to transpile your TS whenever the file is changed. You can use that, and then your tool chain doesn't even have to change at all. (Automatic TypeScript transpilation is built into WebStorm and easy to add to VS Code.) > I have no intention of changing half of my tooling just to be compatible with what fb thought would be a good idea, and even less so for ms. In my limited experience, TS is much more polished than Flow is. The tooling is mature, debugging works well, and the language is rapidly improved. It's not just MS using it -- Google also uses it, and some other larger companies. > A build step is required, I take it, but that's not a problem. Would I be able to use old libs and build tools? Anything (and I mean anything) you do with JS, you can also do with TS. It's a superset of JS and compiles to readable, idiomatic JS. > Are there properly working code formatters for both? WebStorm has mature formatting for TS, but there's also tslint if you want some additional error-checking. WebStorm has first-class support for TS, including integration with tslint. > What about editor support (Sublime)? No idea about Sublime, but WebStorm support is absolutely fantastic. Excellent debugging, hints, linting, and completion. VS Code is great, but it lacks some of the more niche-y features of the IntelliJ platform. Some people might not care, and VS Code will do everything they want.

illektr1k 10y ago

Sublime TS support is top notch https://github.com/Microsoft/TypeScript-Sublime-Plugin https://github.com/Microsoft/TypeScript-Sublime-Plugin

natmaster 10y ago

Flow is not a superset of any form of javascript. It is another language. See: https://github.com/facebook/flow/issues/825 https://github.com/facebook/flow/issues/825