There appears to be a real movement to move from Flow to typescript. Is Flow dying?
Edit: but, their main codebase is in Flow, and that sounds like a mess to migrate, so I wouldn't be _too_ worried. It might slow down, but I doubt it will become unmaintained anytime before Facebook gets sued out of business :-P
I'd consider flow dead.
Sure they would. Flow has nothing to do with Facebook's business strategy, or its marketing campaigns, or even its corporate strategy. I'd be surprised if anyone on VP or higher even knows what it is.
Insofar as "NIH" wins at big companies, it's when there's a business motive to promote a certain technology or FUD about what other technologies might exist.
But engineering team A deciding not to use engineering team B's tools despite working at the same company? Happens all the time.
1: https://npm-stat.com/charts.html?package=babel-core&package=...
2: https://trends.google.com/trends/explore?date=today%205-y&q=...
3: https://developers.slashdot.org/story/18/11/25/017227/micros...
[0]: https://medium.com/@bluepnume/introducing-paypals-open-sourc...
[1]: https://medium.com/@bluepnume/jsx-is-a-stellar-invention-eve...
Disclaimer: I work with TypeScript professionally.
The React team is _very_ busy already with work around Hooks, Concurrent Mode, and Suspense. There's no way they're going to pause development on implementing all these major chunks of functionality just to rewrite from one type system to another.
I've seen Dan express some frustration with Flow's pace of development on Twitter a couple times, but beyond that, no indications whatsoever that React would be converted to TS. In the entirely hypothetical scenario that React _did_ get rewritten to another language, I have to assume it would be something like ReasonML (which was created by Jordan Walke, the original creator of React).
A declaration file(s) could be included. There they could just declare types for all classes, methods, constants, etc. Similar to C header files.
(This is how the DefinitelyTyped repository handles typings for untyped source repositories: https://github.com/DefinitelyTyped/DefinitelyTyped)
Ex:
JavaScript: app.js
function app(arg1, arg2, arg3) {
// does something
return {
key1: someStringValue,
key2: someNumberValue,
};
}
declare type AppReturnValue = { key1: string, key2: number };
declare function app(arg1: string, arg2: string[], arg3: boolean): AppReturnValue;And like I said, Flow is providing sufficient benefit for the React team right now, and their focus is on expanding React's capabilities. Changing type systems is not on their radar as far as I know.
And I certainly get your point. However I wonder if they'd consider community-contributed TypeScript declaration files to the official repo as they wouldn't cause conflicts with the Flow system—
To pick a specific example, here's the file that implements the core logic for the new Hooks feature:
https://github.com/facebook/react/blob/6cb26774e27e03c7d5d6e...
As for the TS typings, there's been lots of agitation from people asking them to be officially included and shipped with React. But, again, the React devs themselves aren't TS users (that I know of), and so they don't have the expertise to write and maintain those typings. Better that they be left over in DefinitelyTyped for the community to maintain.
(I'm a Redux maintainer, and I feel exactly the same way about the typings for React-Redux. I don't have any actual TS experience myself yet, and I couldn't do anything useful in regards to the React-Redux typings. Plus, I've got far too much else on my plate to worry about those.)
Isn't Flow more concerned with soundness than intellisense? Has TypeScript caught up with Flow in this regard?
Perhaps it's because I prefer to do my work in strongly typed, pure FP languages where I can but I work professionally with JS and have been investing in Flow there for over a year now. While Flow is still not exactly great it can at least mimic exhaustive pattern matching and catches most unsafe type errors without getting in the way of common JS patterns too much.
The reason the yarn maintainers are giving is because they want more contributors? What advantage will that have if TypeScript isn't catching the errors you used to be able to catch or don't know about yet?
Curious to know if it's worth migrating over to TS without sacrificing anything other than the minor inconvenience.
I think the answer is: it's very close. It's still a little behind flow on soundness, but it's now close enough (if you enable strict mode, which you should!) that you're unlikely to notice the difference.
The TS type system is very impressive. It can't do everything that the functional languages can do, but it can do some things that they can't, and importantly it's still improving rapidly.
You may be interested in the roadmap/changelog page: https://github.com/Microsoft/TypeScript/wiki/Roadmap
There was initially talk of Flow using comments to actually work without touching the source code at all, but I don't think anything came of that... is there anything else on the horizon?
[Edit: Nevermind: I went looking for the github issue about adding types as comments, and it turns out it's already supported by flow: https://flow.org/en/docs/types/comments/ - is there anything like this for TypeScript?]
I have to ask what you're trying to achieve here. Moving types into comments just gives people who build without your typechecker the chance to break your code.
If I can have a folder of plain JS that I know will work in a browser 20 years from now without having to resurrect an ancient/abandoned toolchain, then I'll do that!
That's what Typescript is. Type annotations don't change your code, they're stripped away by babel at compile time. In fact, by default, tsc does compile TS code which fails typechecking, into valid JS code (which will likely error when you use it at least in some circumstances, but can run just fine).
Typescript is a clear superset of JS, so there's no actual logical changes or even syntactical changes done by the compiler. However, you may be confused by the often-used "compilation target" features of babel (and tsc), which is that you may write ES2018 code, target ES5, and have your ES2018 syntactical sugar be turned into ES5-compatible code. This is entirely opt-in, and not related to typescript (other than the fact that Typescript is always compatible with the latest ES spec, so you can use any legal ES2018 syntax in it).
Hope that clears it up…
With Flow, the type annotations are just stripped away, none of your Flow code affects runtime code.
This is not so with TS since you have things like Enums, which will be compiled into objects and are part of your runtime code.
If you write type annotations in Flow, they're stripped away.
There's no difference. TS has some additional features which are purely optional that don't get purely stripped out, but you're not mandated to use them.
In my eyes, it's a philosophical difference between the two, Flow can be more easily integrated into an existing codebase by just adding //@flow at the top the file and has no features which can affect runtime code. Whereas TypeScript tries to be a different language altogether that uses a new file extension, adds new features, and has its own compiler.
When you can implement a tool like this using TS, let me know https://github.com/flowtype/flow-remove-types
Enums are a fair point, those aren't in the ES specs (though I suspect at some point they will be). However, they're an incredible addition and they really are just syntactic sugar for a more complex type of object.
BTW, typescript supports jsdoc-style annotations, and --allowjs even lets it typecheck javascript code. It also supports more, because nobody actually only wants those things; they're not that great on their own.
You might not think the differences is a big deal, but affecting runtime code is a pretty major line to cross. Not that there is anything inherently wrong with that, but at that point it becomes a different tool, in my opinion.
enums are a tiny, extremely useful and extremely optional part of the language and they don't warrant this label of "philosophical difference", IMO.
Still, I once did Flex development (would compile to a SWF file, or with Adobe Air to a native executable). It was a pleasure -- so long as you used the Flex/Flash Builder IDE (which was itself built on top of Eclipse). Trying to develop in vim was harder, though mainly because of the MXML part, but I still liked MXML better than HTML. Later at the same job I did Node and found that pretty enjoyable too, plus I could use vim all the time.
Tooling is always a concern with a language. I think dynamically typed languages are partially successful because they let you get away with so much less tooling. Though not all dynamic languages are equal in the tooling they can trivially support, e.g. Common Lisp with Slime enables all the usual stuff (who calls x, who sets y, who specializes method z...) and you can use Slime from a variety of other tools.
You can turn typescripts type inference on on a regular js file.
https://www.typescriptlang.org/docs/handbook/type-checking-j...