Both flow and typescript are great tools. Typescript has much better tooling and great IDE integration, using typescript is a no-brainer for new projects. Flow's soundness does shine though once your codebase (and your team) becomes very big, as any unsafe cast can be reliably treated as error. I use flow at work, and so far my experience is that unsafe cast in flow always indicates a bad design or actual bug.
Fast and precise type checking for JavaScript
21–30 of 41 posts
Re: Fast and precise type checking for JavaScript
#22Earlier quoted context omitted.
What is soundness, exactly, and how is Typescript unsound? It seems like a useless academic term that doesn't work so well in the real world, maybe?
Just as an example, this program type checks in TypeScript but crashes at runtime: class Dog { } class Greyhound extends Dog { doGreyhoundThing(): void { console.log("I am a greyhound!"); } } class Poodle extends Dog { doPoodleThing(): void { console.log("I am a poodle!"); } } function f(g:(Dog) => void) : void { let hound: Greyhound = new Greyhound(); g(hound); } function h(p: Poodle): void { p.doPoodleThing(); } f(…
When I was student (1992), a friend noticed exactly the same issue in the eiffel language. They answered also that the incorrect check was more practical.
Re: Fast and precise type checking for JavaScript
#23I think the-morning-paper is one of the best things on the internet. It's probably the thing I miss a proper blog reader for most.
Re: Fast and precise type checking for JavaScript
#24I used both Flow and TypeScript extensively at my last job (coda.io), and through a series of thoughtful discussions and debates, we chose to migrate to TypeScript, even though we had already started using Flow in parts of our codebase. Microsoft did a really good job putting resources behind TypeScript, making sure tooling and IDE integrations are good, and generally getting a ton of momentum going. TypeScript is fa…
I only post on HN about once a year. But I want to chime in on this topic.
At my current job we started a clean slate codebase (react/redux/webpack) beginning of 2016 and had everything typechecked by Flow from the start.
We found Flow to be extremely unreliable and cumbersome to use with not much apparent commitment behind it. As soon as Typescript hit 2.0 we converted the entire codebase (fairly easy to do since the syntax and semantics are very similar') and have been super happy with that decision.
I wholly agree on you remark about soundness vs. tooling. Flow tooling sucked, error messages were cryptic and unhelpful and we ran into obvious mistakes all the time that Flow did NOT catch, without being able to figure out why that was. Editor support was lacking and we just never trusted the typechecker.
Bolting on types to Javascript has tradeoffs and Microsoft did an amazing job of making the right tradeoffs.
There is noticeable effort and momentum behind the project that inspires a lot of confidence in the languages future. It has completely changed the way I write Javascript and I can't imagine going back to an untyped world.
That change was not in rock-solid confidence that TS catches all my errors (although it does a remarkably good job at that), but the sheer productivity improvement types enable (autocompletion, project-wide renaming, all that stuff users of Java or C# IDEs have available to them).
Re: Fast and precise type checking for JavaScript
#25I used both Flow and TypeScript extensively at my last job (coda.io), and through a series of thoughtful discussions and debates, we chose to migrate to TypeScript, even though we had already started using Flow in parts of our codebase. Microsoft did a really good job putting resources behind TypeScript, making sure tooling and IDE integrations are good, and generally getting a ton of momentum going. TypeScript is fa…
Flow/Typescript both of great but writing from start from scratch both flow and typescript slow me down with all the hassle of needing to define the types of parameters and data structures. Typescript being a bit verbose at time too. When working with another person API then typescript does become a godsend in helping understand what the bloody hell does this callback parameter are required.
Verbosity is quite helpful when doing maintenance on foreign code.
Re: Fast and precise type checking for JavaScript
#26I used both Flow and TypeScript extensively at my last job (coda.io), and through a series of thoughtful discussions and debates, we chose to migrate to TypeScript, even though we had already started using Flow in parts of our codebase. Microsoft did a really good job putting resources behind TypeScript, making sure tooling and IDE integrations are good, and generally getting a ton of momentum going. TypeScript is fa…
I advocated flow for two years, and I still find it interesting as a typesystem. But what finally led me to give up was the core team's lack of community engagement.
It's very difficult get the team's attention to a bug or a question. As a result, they fail to see the common pain points of actual users.
Typing higher order components is one common pain point that still doesn't have a clear solution. So, unless you're avoiding HOCs altogether, you can't really benefit from type annotations in your react codebase (you'll have too many implicit `any`s).
You'll find more of these common use cases that flow doesn't optimise for. They're all over the issues section. Unfortunately, issues on Github generally don't get much attention from the team either, so I'm guessing users sometimes give up on reporting them. This has happened to me quite a few times. I didn't report some bugs because putting together a reduced test case takes time, and that time would be wasted if your issue is not gonna be paid attention to.
What makes matters worse, is that there is no public roadmap. You don't know what the team's priorities are. You don't know when the bugs that affect your work are gonna get fixed, or some feature you need is gonna get implemented. You don't even know if it's on the radar.
Of course, the Flow team is under no obligation to do any of that. They have no obligation to fix bugs for us or publish a roadmap. I'm already grateful that they've given us access to their work and without charging money. However, they do have the responsibility to communicate what their priorities are. If they're positioning Flow as an alternative to TypeScript, which is a well-supported, community-oriented project, then they should state clearly that Flow simply isn't. Call it a research project, or a project focused on a single company's use cases. Don't ask people to bet their own projects on it, when they clearly shouldn't. It'll be a big loss of productivity for them down the line, and your messaging is partly responsible for that.
Re: Fast and precise type checking for JavaScript
#27I'd be much more enthusiastic about using a type system if it was a part of an official ES-next spec. Right now community efforts around static typing are divided between two very similar, but incompatible type systems, similar to the situation we had a few years ago with CommonJS and AMD modules (though the two module systems are much more dissimmilar than Flow and TypeScript). The module debate has been been mostly…
Interestingly, a type system was proposed for JavaScript around 2007 as part of ES4, which was later abandoned [1]. The proposed details in [2] are strikingly similar to what we've ended up with in Flow and TypeScript.
[1] https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_.28aban... [2] https://www.ecma-international.org/activities/Languages/Lang...
Re: Fast and precise type checking for JavaScript
#28I'd be much more enthusiastic about using a type system if it was a part of an official ES-next spec. Right now community efforts around static typing are divided between two very similar, but incompatible type systems, similar to the situation we had a few years ago with CommonJS and AMD modules (though the two module systems are much more dissimmilar than Flow and TypeScript). The module debate has been been mostly…
It feels a little bit like if you'd want a linter to be part of an ES spec. As in: I appreciate TypeScript for the compile-time guarantees it gives me.
Re: Fast and precise type checking for JavaScript
#29I'd be much more enthusiastic about using a type system if it was a part of an official ES-next spec. Right now community efforts around static typing are divided between two very similar, but incompatible type systems, similar to the situation we had a few years ago with CommonJS and AMD modules (though the two module systems are much more dissimmilar than Flow and TypeScript). The module debate has been been mostly…
It feels a little bit like if you'd want a linter to be part of an ES spec. As in: I appreciate TypeScript for the compile-time guarantees it gives me.
The point of having type annotations in the spec is so that library and tooling authors can focus on providing and refining a single set of type annotations that any tool (Flow, TypeScript, anything else that comes up) can check for correctness and perform static analysis (for things like autocomplete, find references, go-to definition, etc) against. Over time, this would vastly improve the quantity and quality of available type definitions compared to what's available for either the Flow or TypeScript camp alone.
And once type annotations are part of the language proper, the possibility opens up for browsers to use type annotations to provide runtime safeguards, optimizations, and reflections, all of which would be invaluable since static checking alone is often not enough to provide correctness guarantees in all cases in JavaScript. When all is said and done, JavaScript is a dynamic language, and the ability to reuse the same type annotations for both static and dynamic checks is the piece that I'm sorely missing from both the Flow and TypeScript ecosystems so far.
Re: Fast and precise type checking for JavaScript
#30I used both Flow and TypeScript extensively at my last job (coda.io), and through a series of thoughtful discussions and debates, we chose to migrate to TypeScript, even though we had already started using Flow in parts of our codebase. Microsoft did a really good job putting resources behind TypeScript, making sure tooling and IDE integrations are good, and generally getting a ton of momentum going. TypeScript is fa…
Flow/Typescript both of great but writing from start from scratch both flow and typescript slow me down with all the hassle of needing to define the types of parameters and data structures. Typescript being a bit verbose at time too. When working with another person API then typescript does become a godsend in helping understand what the bloody hell does this callback parameter are required.
>When working with another person API then typescript does become a godsend in helping understand what the bloody hell does this callback parameter are required.
Plot twist: While you are cursing at the person who wrote that API, you slowly realize that it was you all along.