That said, back when we got started, we found that TypeScript is all around a better team player. For us, we found that it worked better with npm modules, different operating systems, vanilla JavaScript, and various coding tools (VIM, Visual Studio Code, Atom, etc).
(1) It is less intrusive. Flow's type system is built on annotations which are simply stripped away at runtime (as opposed to writing in another - albeit similar - language that gets transpiled to JS. Sure the transformations are always "file-local" as TS folks say but still it is another, totally unecessary level of abstraction and transpilation.
(2) Flow's type system is at least equally and quite possibly much more expressive and nuanced than TS.
(3) Flow annotations can be applied in a much more piece-meal way than TS.
(4) zero issues integrating with 3rd party libraries (because of 1) - and that includes the ability to type-check said 3rd party libraries (which is a breeze with flow-typed)
(5) To take advantage of TS you have to write JS code in the "JS with classes" style (a.k.a "JS for C# coders"). In contrast Flow allows you to take advantage of its type checking while coding: (a) in idiomatic JS (prototypes) (b) in JS with classes (c) any combination and mix of the two approaches. Flow feels a lot less opinioned as to your JS programming style.
(6) Flow it is not coming from microsoft (but hey, don't you know we've changed, please give us another chance and we won't fuck you over this time, please we love you so). TS team is trying very hard (perhaps too hard) to distance themselves from the negative brand value of microsoft
(7) Flow is not a blueprint for the Mother of all embrace-extend-extigunish strategies (see #6).
- There's an implication that Flow is vastly different than TypeScript because its annotations are stripped away - that's how TypeScript works too.
- There's an implication that TypeScript has some sort of unusual syntax - Modern JavaScript (ES6+) and TypeScript code is identical (except for the addition of type annotations where desired).
- Flow may have a nuanced and expressive type system - I don't know - but TypeScript attempts to accurately model the type system of JavaScript.
- TypeScript can be used in a very loose mode where it type-checks plain .js files with no annotations at all, all the way up to a very strict mode where it must know the type of everything (which you can set to `any` on a per-variable basis if you don't care).
- TypeScript is JavaScript, so it has no issues integrating with any JavaScript library. If you want perfect strong typing of a given version of a given JS library, someone has to do that work and this is where some people do struggle. Microsoft has put forth a lot of effort to help here recently. Flow-type may be a great resource (I don't know), but I can scroll its list of supported libraries on its repo on GitHub. https://github.com/flowtype/flow-typed/tree/master/definitio... . The DefinitelyTyped repo breaks GitHub with the number of libraries it has definitions for: https://github.com/DefinitelyTyped/DefinitelyTyped/tree/mast... (nearly 2000 entries are omitted).
- Item 5 is flatly false. For example, TypeScript is itself written in TypeScript and there is not a class in the entire code base - it is 100% idiomatic functional JS. By contrast, Flow is not self-hosted.
- Regarding item 6, TypeScript is the poster child for the new Microsoft. It has been open source (Apache 2.0) and cross platform from its original release in 2012. And regardless of what happens with TypeScript (I forsee it tracking ECMAScript standards for the next several years at a bare minimum), the emitted JS is basically identical to your TypeScript code (minus the annotations) so worst case scenario if Microsoft somehow magically deleted all copies of TypeScript in the world, you'd just keep going with the ES6+ code you have.
I'd like to hope many people are using TS in a functional style.
EDIT -- there was one object ... we had to create an exception class for some reason ... don't fully recall the details.
function test ({param1, param2}: {readonly param1: string, readonly param2: number}) {
return
}I think the only legitimate reason left not to use ES6 class syntax is (for perf sensitive code) performance, but that's a negligible and temporary problem as the JS engines will fix that over the next 6 months.
Point number one in particular bothered me since both languages are transpiled (in both cases that just means types stripped). However, I think MarcusBrutus was talking about Flow type comments which can be added to Javascript files to get type checking, but which will not need to be transpiled at all as all nonstandard stuff is in the comments.
Otherwise, can you please explain why bother implementing a transpiler if the emitted sources are identical to the input sources minus the annotations?
Even the names should give you a hint: "TypeScript" is a language name (the microsoft version of ECMAScript more specifically). "Flow" is not. That's why it's called "Flow" and not "FlowScript".
> TypeScript being a transpiler means what gets executed at runtime is not what you wrote but some other sources emitted by the TypeScript transpiler.
This is also true with Flow, if you want to be technical. What you write with Flow is not valid JavaScript (with the sole exception of comment style types) but some other sources emitted by another program like Babel.
If you haven't looked at TypeScript in 3-4 years, then you can't really make an informed opinion on the subject, because in that timeframe React has gone through 12 versions, Flow did not publicly exist, and TypeScript has changed significantly. It might be worth looking at TypeScript again and seeing how it compares to Flow in 2017.
TypeScript is a transpiler to the extent you want it to be a transpiler. You can use it to remove annotations only with '--target ESNext' - then it works the same as Flow does in your use case and does not add anything.
In the same vein, most people use Flow with babel. Then it's "transpiling" in the same way TypeScript is "transpiling".
You're either severely misinformed or opting to make your argument by misleading. I wonder how much you have actually used TypeScript.
> as opposed to writing in another - albeit similar - language that gets transpiled to JS
How is a nicely typed bit of flow-code different from the equivalent TS? If you make actual use of the type system in either of Flow or TS you should end up with code that looks a lot like Java or C#, with generic types and functions etc.
It's nice that you can do it gradually in flow for an existing codebase, but it's still no difference once properly applied in full.