- You don't need ts-loader/at-loader with Webpack anymore. You'll lose typechecking during webpack build but you can run it as separate step. Your editor will show them as usual still.
- You can use all the Babel plugins with Typescript without running two compilers (should speed things up)
- Should add first class support for React Native as it uses Babel (or at least no more 2-step builds)
EDIT: For the curious here's my build configuration with Webpack demoing this with extra plugins https://gist.github.com/epeli/bb8ae386f9dbb2a4ae2159e1f265fd...
If you also want to use it as an enforcer, you set it up as a pre-commit hook or a CI step or whatever you want.
The idea is not to be forced to typecheck on every little incremental build during development. Sometimes I _know_ what needs to be done to get typechecking to pass (I can see the type errors highlighted in my editor after all) but I don't want to have to fix it before running my code to see how it behaves, because maybe I'm just playing around with an idea.
There are pros and cons to typechecking and not typechecking, which is why both kinds of language exist. Annotation-
stripping lets you get the best of both worlds.
Tried this on a project of mine. Enums seem to work fine for me.
EDIT: There are some issues with enums indeed https://github.com/babel/babel/tree/master/packages/babel-pl...
Because he thinks you can't do JS development without Babel.
(I haven't used TypeScript yet, so I might be wrong)
The only counter-example that I know of is that async/await were initially only supported when transpiling to ES6, but this is not true since at least 2.2 (https://github.com/Microsoft/TypeScript/issues/5210).
The error log shows me the rest of the files that need fixing.
How would you get that with Babel?
But you could just run "tsc --noEmit --watch" which will just report the project wide type errors to the console as you edit files.
(I work on Babel)
We then tried Flow. Oh dear god, has it been a blessing.
* It's seamless to integrate with Webpack, ESLint & Babel.
* It's crazy fast
* Has great support for React
* Fits in perfectly with Redux
* Dead easy for beginners to learn
* Has an amazing Type system. My major experience with types has been Java, and Flowtype just blew my mind with - non-nullable types, subtyping and type refining.
* Documentation is great
* Community is very active
* About 1/3rd of the time error messages are not intuitive. But nothing you can not figure out. And it's getting better.
In the parent post, pcx shares his experience with trying to make TypeScript work, concludes that he wasn't able to make it work, then says he was able to make Flow work and lists ways in which Flow made his life easier.
Not even a word in the post suggests that the parent intended his "pros" list to be a comparison between TS and Flow. It's just a list of things Flow does for him. Not even one mention of TS on that list!
I don't quite understand why would one misinterpret a list of good things about one tool to be also, implicitly, a list of bad things about another tool. It's not politics, we don't need such polarization in technical discussions, saying that Flow has great docs is not the same as saying TS has bad docs.
But the real problem is that, by choosing to get offended by something entirely unrelated, the sibling commenters missed the one direct comparison between TS and Flow and a real TS criticism: parent says it's easier to setup Flow compared to TS. It would be better to discuss this point - I'm not qualified to do so myself, unfortunately - instead of focusing on statements the parent never wrote.
- Saying the error messages are "not intuitive" is a bit of an understatement. Most memorably, this was an actual message I was presented with after upgrading to Flow v0.53 - https://imgur.com/UseQxEz.png
- Flow's goal appears to be ensuring correctness rather than being useful. Object.value produces an array of mixed, effectively erasing their type (https://github.com/facebook/flow/issues/2174). document.body is a Maybe (https://github.com/facebook/flow/issues/4783). All use of getters and setters are marked as unsafe, with no way to selectively opt in or out (https://github.com/facebook/flow/issues/2826). These are pedantic to the point of uselessness.
- When a function call's parameter type disagrees with the function signature, Flow flips a coin and marks one of them as incorrect. GitHub issue from Oct 2016 - https://github.com/facebook/flow/issues/2587 (issue is closed because they're 'working on it', not because it's actually resolved)
- Flow's libdef is a fraction of TypeScript's. I frequently convert TypeScript libdefs to Flow libdefs. I have yet to see a library that has Flow libdef but not TypeScript libdefs.
- Flow has more & better type definitions for React than TS. I think it's because a lot more React devs use/develop Flow and also both are FB projects.
- For our Redux + Flow setup, we export an ActionCreator type that is a union of all action creators we've defined. This union gets refined by the switch statements in reducers, allowing us access to well typed action creators in reducers, without having to deal with import/export of individual types.
- The docs are pretty good. Several of my colleagues are new to static typing, and have picked Flow up easily because of the docs. I also heard some interest in providing video courses like Egghead.
- Flow has an amazing type system compared to Java. Except for enums though. Java Enums are much much better.
Of course it also means you can't upgrade React without upgrading Flow, and you can't target a specific (older) version of React without downgrading Flow.
What's stopping you from doing this in Typescipt?
The experience I've had around typing higher-order components in general, and specifically with the recompose library (https://github.com/acdlite/recompose), which I use heavily in just about every React project, has been much better in Flow than in TypeScript. Now this is not completely fair to TypeScript since the recompose types for it were still a work in progress last time I tried it, but recompose is a central building block in most of the codebases I work with on a day-to-day basis, so good typing around it is a vital consideration for me, and possibly others who prefer to work with React components using functional composition.
I'm surprised the author thinks that Flow is more popular amongst the React community than Typescript. I hardly ever hear about Flow, and I work with React and follow it's development. I've been gradually concluding that Typescript has won in terms of future-of-frontend, so I'd be curious to know if people disagree.
So it does kind of have React integration, but it's pretty loose - you can use it with any other framework, and there's nothing obviously React-specific about the language.
Edit: See https://flow.org/en/docs/react/types/
Nuclide for atom was the official release by facebook for supporting flow + react, and now you have Atom-IDE which is optimized for react + immutable.js + flow.
Plus the facebook guys are avoiding VScode like the plague and focusing entirely on Atom. Which now also comes with the BSD+ licence.
Agreed. Perhaps the thought that Flow is more popular in the React community comes from people who are not using either Flow or TypeScript? In my experience, I rarely ever see Flow being used in the wild.
Another metric we can look at to estimate popularity is the number of questions on StackOverflow.
Flow has 1K https://stackoverflow.com/questions/tagged/flowtype
TypeScript has 37K https://stackoverflow.com/questions/tagged/typescript
Also looking at NPM downloads this month:
Flow has 1M https://www.npmjs.com/package/flow-bin
TypeScript has 7M https://www.npmjs.com/package/typescript
Over time the argument in favour of Flow became the following: it has a "sound" type system, which means it produces better results in some extreme cases where TypeScript fumbles. I didn't seem to ever hit those corner cases, I just enjoyed the fact that TypeScript had a more robust type system.
Next argument was: Flow is just a linter that strips out the type annotations. Most projects that use Flow use a transpiler, which renders the linter argument moot.
As of today, I don't know of anything that you can do with Flow and cannot do with TypeScript, the reverse is not true though.
Unless I'm missing something, it seems that Flow's existence is based on tribalism rather than rationality, the Angular team realised that if there is already a project out there that covers 99% of their needs, it might be better to just work with the project instead of reinventing the wheel, Facebook seems to have been ignorant of that. Facebook developers seem to have a tendency to just re-invent the wheel instead of collaborating, see Yarn, I'm not saying that they are wrong in doing so, there is a chance that they might be on the right, however I don't feel that is the case when it comes to TypeScript.
This is my impression as well. The Facebook employees I see on Twitter seem like super-smart people, but unfortunately they also seem to have a degree of arrogance and aggressiveness about how their tech is superior to everything else, which they often express by trash-talking the "competition".
In fact, a lot of the Flow / React / Yarn, etc. community seems vaguely cult-like, with a cabal of Facebook/ex-Facebook employees as its leaders, and an implicit (or explicit) contempt for anyone too stupid to recognise their righteousness. That alone makes uncomfortable enough to avoid using any of these projects when I have the option not to.
- Switching everything to .ts and .tsx files
- Switching a lot of tooling (TypeScript's built-in ES6 transpiler instead of Babel, tslint instead of eslint, etc.)
- At the time, TypeScript's types were nullable, Flow's were non-nullable, which makes a huge difference to me
- Given that TypeScript is a transpiler along with a static type-checker, it's not always easy to tell which features are going to have build-time vs run-time effects (e.g. private properties, property decorators)
That said, some of the errors from Flow can be incredibly confusing, and even with the latest versions I feel like there's improvement which needs to be made here. This (in my view) is the number one thing it needs to drive adoption.
- Renaming to .ts and .tsx is nicer than adding comments, because it integrates better with tooling (compile all files that end with .ts) and it's easier to see at a glance what's ported
- You can always compile TS to ES2018 and run that through Babel, if you like. TSLint -> ESLint is indeed a change, though you can continue to use most of ESLint for TS 
- As a rule, TS is compile time only. There are a few exceptions, but that's almost always the case.
For me the advantages of TS are:
- Huge library of community written typings for JS libs
- Mapped types
- Full support for literal types
- Read only types
That said, I really like Flow's co/contravariance annotations, and the corresponding $Supertype and $Subtype functions. That, and nominal typing can be really convenient (coming to TS soon, hopefully).
I think you meant structural typing? TS was always nominally typed. I searched for a bit and it looks like TS also supports structural typing with explicit interfaces, and I think Flow tries to infer such types? I don't use either one, so I'm not sure about the details.
TS has a strange workaround to get nominal typing for now:
Ah, ok, makes sense. I think I was last looking at TS around version 1.1 or something like that. Thanks!
Sorry just for my information: which ones are those?
I personally don't think it's an attractive part of TS; it's confusing, and it's just duplicating efforts that Babel already does best. But that's just me.
This is a huge part of why I tend to prefer Flow for my projects these days as well.
I highly encourage people to try it out on a project where they can afford to do the same (i.e. for packaged projects where you have control over the runtime environment like Electron or React Native, or for web projects where most of your users happen to be also web developers). It's really been a breath of fresh air after dealing with all sorts of subtle transpilation induced bugs/edge-cases.
To be clear, I'm not trying to bash TypeScript, because it's an awesome project, with top-class tooling that has attracted an amazing community around it. I just wanted to remind all the people mindlessly shouting "TypeScript has won" into their own silos, that Flow is also a great type system, that just happens to be designed with a fundamentally different set of trade-offs in mind. That alone doesn't make either system better or worse than the other, but it does mean there are use cases where Flow can excel over TypeScript and vice versa, and that you should carefully consider your project's needs and what characteristics you value in a type system before simply cargo-culting one or the other.
The downside is that a few features don't have a jsDoc equivalent. But it would already catch most of the things you'd use a type checker for, without the hassle of going full Typescript: you could even completely remove typescript from the project and it would still work given they're just JS comments.
That sounds super exciting. I'm definitely going to have to give that a shot once it's ready.
Flow's excellent React Native support has also been a large part of why I've mostly been working in Flow-land these days, so I'm glad to hear TypeScript will soon become a first-class citizen in that ecosystem as well.
EDIT: As a follow up question, please correct me if I'm misunderstanding anything, but from what I've gathered so far, I suspect that the new babel-preset-typescript can't quite do _just_ type-stripping can it? Since some features in TypeScript have runtime implications, those would still have to be transformed as opposed to simply stripped, correct? So it looks like that fundamental difference between TypeScript and Flow remains in tact, but it's certainly still a huge leap in usability to be able to adopt the Babel toolchain as a first-class way of building TypeScript projects. Huge props to the Babel and TypeScript teams for making that possible!
I'm quite new to Typescript myself so I really don't know. At least I'm not aware of such features and don't think this Babel feature would make much sense if there were any?
EDIT: I think some of the runtime features are just TS doing ES6 to ES5 compiling. Such as "for of" loops, generators etc., but since those are just ES6 syntax they can be handled by other Babel plugins/presets or even by modern browsers directly.
I hope that in future Typescript would take the same approach as Flow and just focus on being a good type checker on top JS.
Less important, but you also have to add /* @flow */ to the top of every single source file. Sure its handy sometimes for existing projects, but it makes little sense for new ones and has also been an issue for years.
TypeScript works amazingly well with React. Also, it's great only having 1-2 build dependencies rather than 10+ Babel plugins.
Facebook is also working on ReasonML (a new front-end and some tooling for OCaml/BuckleScript) that compiles to JS and has strong typing. Stronger than either TS of Flow has.
I think in the long run ReasonML is a better approach: the underlying language (OCaml) is carefully designed, where JS seemed to have "happened".
Other options that have even stronger typing are Elm, PureScript and Haskell/GHCJS.
Here's a great article describing all the promising projects in functional/strongtypes front-end land:
I like Typescript. But wish it had exact types like Flow. This leads to not being able to type a simple Algebraic Data Type with complete precision.
I think the reasoning given on the github page for not having exact types(involving how it plays with intersection types and union types) has a bug. One can assign T & U to T even when T is exact(exactness of T ensures U wont introduce extra properties), and assigning T to T | U should be fine when U is exact(For a user to determine if a T|U value is T or U, they will have to check whether a property in T exists, not U).
But this is a very small issue.
It's yet another layer of organization and complexity that we need to keep track of on an already incredibly convoluted platform.
Neither TypeScript nor Flow force you to use third party type declarations, but using them seems to be strongly encouraged.
We'll see how problematic this issue turns out to be as these ecosystems evolve.
Another option is to use a proper statically typed language where that is feasible.
Choosing between TypeScript and Flow I would keep an eye on how each of these ecosystems deals with the issue of third party type declarations and versioning.
And if one of these languages gains support by library authors so that we don't need third party types, that would be a strong argument in favor of that language for me.
You don't want to be fighting to change the fundamental nature of something while being crammed in the trench with it.
I'm not saying they're perfect but they're practical. I've used numerous libraries with TypeScript using third party typing now and haven't come across any major issues yet.
If you can use a proper statically typed language with libraries then that would be preferable but is that a realistic option? Right now, TypeScript seems like a practical and realistic option to me.
Don't you give up a lot of efficiency/speed when you compile to JS instead of using JS directly? Or do I misunderstand the trade-off and the benefits of static typing are enough that it's acceptable to have a separate build step after every change, like you're a C++ programmer?
Like any comparison of programming languages, you come to rely on features F, G, and G because your usual features X, Y, and Z don't make as much sense in the new language.
Elm famously promises that if a program will compile then it will run without runtime errors, and delivers on that promise. As a consequence, more time is spent in conversation with the compiler in exchange for never having to step through a program and see where things went wrong. A working program just "snaps together" and lets you safely refactor or move on the next feature. The feedback loop in Elm is very fast because you don't have to run your program and play with it in order to see it fail.
As far as I can tell the Elm REPL can't analyze types in the way that the compiler can, so it's not really useful except to experiment with basic functions and values.
All this to say that a step through debugger might only seem essential if your program can be run in ways that require debugging.
There's a growing set of tools in the build tooling space called "Hot Module Reloading" (HMR). Webpack and JSPM/SystemJS both have picked up HMR tooling of different capabilities. HMR is very similar, from what I can tell, to the skewer-mode example you have posted: HMR tools watch for file changes, rebuild the bare necessary for those file changes, and via websockets between development server and browser communicate "live" reloading of modules as you work.
The work in HMR space is pretty impressive; I've started to rely on it in some webpack-built projects lately.
That said, "build step after every change like you're a C++ programmer" is a workflow that has survived a long time. There are some developers that prefer the comfortable routine of that workflow.
The dev inner loop is maybe a little slower with the compile step for us, but it is possible to use TypeScript's automatic compilation with webpack and Node and all the latest hotness and get automatic build/deploy/refresh (see Office Fabric: https://github.com/OfficeDev/office-ui-fabric-react)
Getting more errors to appear in your IDE at compile time compared to in the console speeds you up way more than any slowdown you'd get too e.g. being told a variable could be undefined at compile time is much faster to fix than having to wait for a runtime crash, you having to track down the cause then hoping you've fixed it.
However, I don't think flow is going to survive React, because it's only used there and internally at Facebook, while Typescript is used successfully with React, Angular, and basically everywhere people need typechecking outside of React (Typescript has definition files for most libraries with significant users)
From the outside it really seems there are 3 ecosystems, a large one (typescript) und 2 others (Flow and ReasonML) that are mainly used for parts of facebook.