5 ms·

Fast and precise type checking for JavaScript

98 points by deltux 9y ago

swlkr 9y ago
I thought this was a new thing, but it turns out it's facebook's flow. https://flow.org https://flow.org
- spraak 9y ago
  Yes, it would be good to add that to the title
- keratin 9y ago
  my thought as well, precisely..
dgreensp 9y ago
I 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 fast-moving, with bugs fixed and features added at a high rate, and the quality of discussion on the issue tracker is high. Flow, in comparison, was not evolving as fast. Flow touts global inference, which I think means better types when you don't necessarily have annotations on module boundaries, but I mostly care about what's possible in a greenfield or well-annotated codebase. Flow deserves a ton of credit, and Microsoft probably studied it in detail, but I think the advantages are overblown at this point. Take the soundness thing. TypeScript added null-strictness a while ago, and recently they improved function type polymorphism. The reality is that both type systems have limits and you sometimes need to type something imperfectly or use an escape valve ("any"). In most cases, however, TypeScript gives you more sophisticated tools to construct the types you want, so you actually get better types. Maybe TypeScript lacks a theoretical underpinning for soundness, but there's no reason it can't continue to get "more and more sound," with it harder and harder to find good examples of unsoundness.
- oceanic 9y ago
  Apologies, offtopic: wait, Coda.io only uncloaked less than a month ago and you've already left??
  - AnkhMorporkian 9y ago
    I mean, I've worked for several companies and left months before they actually launched. Any contractor who works with startups have been through similar situations. Can't speak for OP's situation though.
- _ar7 9y ago
  Yeah I second this. Despite having a superior type system, flow is so behind in both tooling and 3rd party library definitions it's really hard to justify continuing to use it over typescript. It's weird to say, but the unsoundness of typescript doesn't matter much next to all the other advantages. Besides, I feel like if I really want a strong type system https://reasonml.github.io/ https://reasonml.github.io/ might be the better choice over flow.
- hackits 9y ago
  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.
  - pjmlp 9y ago
    Verbosity is quite helpful when doing maintenance on foreign code.
  - dahauns 9y ago
    >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.
chmln 9y ago
Flow capitalizes on its soundness, but its not as useful when the error messages are so cryptic. We tried adopting Flow at a company I worked at, but dealing with gibberish errors and the huge meaningless stack traces was a productivity sink. We migrated to Typescript. Error messages are more understandable and unlike flow include line numbers and the column. Add huge number of typings, and ts definitely wins. There are many gripes we've had with typescript too, but at least we didn't spend hours trying to understand error messages.
- hasenj 9y ago
  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?
  - alangpierce 9y ago
    Soundness means that if the type system says that a variable has a particular type, then it definitely has that type at runtime. A sound type system is always correct, and an unsound type system might be incorrect in some cases. Here's an example of unsoundness in TypeScript: https://www.typescriptlang.org/play/index.html#src=function%20messUpTheArray(arr%3A%20Array%3Cstring%20%7C%20number%3E)%3A%20void%20%7B%0D%0A%20%20%20%20arr.push(3)%3B%0D%0A%7D%0D%0A%0D%0Aconst%20strings%3A%20Array%3Cstring%3E%20%3D%20%5B'foo'%2C%20'bar'%5D%3B%0D%0AmessUpTheArray(strings)%3B%0D%0A%0D%0Aconst%20s%3A%20string%20%3D%20strings%5B2%5D%3B%0D%0Aconsole.log(s.toLowerCase())%0D%0A https://www.typescriptlang.org/play/index.html#src=function%... TypeScript incorrectly (but conveniently) says that Array<string> can be assigned to Array<string | number>, and you can exploit that to create an "s" variable that TypeScript thinks is a string but is actually a number. You can try the same code in Flow and it gives a type error: https://flow.org/try/#0GYVwdgxgLglg9mABAWwKYGd0FUAOAVAC1QEEAnUgQwE8AKC8gLkTMqoB50pSYwBzRAD6IwIZACNUpAHwBKJgDc4MACaIA3gChE2xPVIA6HCHQEaAZhkBuDQF8NGiAk6JO3PuiYtqHLj15TEAF5EAG0AcmA4ODCAGkQwsXowgF1rNExcQhJyahpXP3Qre0cwZw8XXz4girdedBCAJlSHJzgAG1R9NrhePP0oOAAZOAB3SQBhCnRUGhkZDSA https://flow.org/try/#0GYVwdgxgLglg9mABAWwKYGd0FUAOAVAC1QEEA...
    - maxbrunsfeld 9y ago
lewisl9029 9y ago
I'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 laid to rest with the introduction of the official ES modules spec (at least from the perspective of the application developer when it comes to module code they actually write), and I'm hoping an official type annotation spec can do the same for the JS static type checking landscape. Flow has already long-since demonstrated that it's perfectly possible to introduce useful type annotations to JS code without changing any runtime behavior whatsoever, and Flow and TypeScript have mostly converged on similar syntax and semantics when it comes to the type annotations. Given all this, I'd have thought that the standardization process would be pretty far along by now. Maybe someone more familiar with these matters can offer some insight on the seeming lack of progress?
- yortus 9y ago
  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_.28abandoned.29 https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_.28aban... [2] https://www.ecma-international.org/activities/Languages/Language%20overview.pdf https://www.ecma-international.org/activities/Languages/Lang...
  - WorldMaker 9y ago
    See also ActionScript [1] which was the closest real world language to an ES4 implementation, and how much it seems like Typescript/Flow. [1] https://en.wikipedia.org/wiki/ActionScript https://en.wikipedia.org/wiki/ActionScript
- Vinnl 9y ago
  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.
zefei 9y ago
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.
nl 9y ago
I 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.
makkesk8 9y ago
I've always wondered if you could let the engine do the type checking or create type definition files for you, maybe an optional v8 flag? This would be best case scenario so we could get rid of the tedious work that one has to put in to make an older library have type checking.
- WorldMaker 9y ago
  Typescript has inference for "plain" JS files if you use the `--allowJS` flag. That inference is also made available more directly in dts-gen [1], which is a tool built around Typescript inferencing that produces decent first pass type definition files for a library. dts-gen may be something to try the next time you need a definition file. (Personally, I still prefer to start a new definition file by hand, but it's good to have an automated option, even if only to double-check your work.) [1] https://github.com/Microsoft/dts-gen https://github.com/Microsoft/dts-gen

98 points by deltux 9y ago

swlkr 9y ago

I thought this was a new thing, but it turns out it's facebook's flow. https://flow.org https://flow.org

spraak 9y ago
Yes, it would be good to add that to the title
keratin 9y ago
my thought as well, precisely..

dgreensp 9y ago

I 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 fast-moving, with bugs fixed and features added at a high rate, and the quality of discussion on the issue tracker is high. Flow, in comparison, was not evolving as fast. Flow touts global inference, which I think means better types when you don't necessarily have annotations on module boundaries, but I mostly care about what's possible in a greenfield or well-annotated codebase. Flow deserves a ton of credit, and Microsoft probably studied it in detail, but I think the advantages are overblown at this point. Take the soundness thing. TypeScript added null-strictness a while ago, and recently they improved function type polymorphism. The reality is that both type systems have limits and you sometimes need to type something imperfectly or use an escape valve ("any"). In most cases, however, TypeScript gives you more sophisticated tools to construct the types you want, so you actually get better types. Maybe TypeScript lacks a theoretical underpinning for soundness, but there's no reason it can't continue to get "more and more sound," with it harder and harder to find good examples of unsoundness.

oceanic 9y ago
Apologies, offtopic: wait, Coda.io only uncloaked less than a month ago and you've already left??
- AnkhMorporkian 9y ago
  I mean, I've worked for several companies and left months before they actually launched. Any contractor who works with startups have been through similar situations. Can't speak for OP's situation though.
_ar7 9y ago
Yeah I second this. Despite having a superior type system, flow is so behind in both tooling and 3rd party library definitions it's really hard to justify continuing to use it over typescript. It's weird to say, but the unsoundness of typescript doesn't matter much next to all the other advantages. Besides, I feel like if I really want a strong type system https://reasonml.github.io/ https://reasonml.github.io/ might be the better choice over flow.
hackits 9y ago
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.
- pjmlp 9y ago
  Verbosity is quite helpful when doing maintenance on foreign code.
- dahauns 9y ago
  >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.

chmln 9y ago

Flow capitalizes on its soundness, but its not as useful when the error messages are so cryptic. We tried adopting Flow at a company I worked at, but dealing with gibberish errors and the huge meaningless stack traces was a productivity sink. We migrated to Typescript. Error messages are more understandable and unlike flow include line numbers and the column. Add huge number of typings, and ts definitely wins. There are many gripes we've had with typescript too, but at least we didn't spend hours trying to understand error messages.

hasenj 9y ago
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?
- alangpierce 9y ago
  Soundness means that if the type system says that a variable has a particular type, then it definitely has that type at runtime. A sound type system is always correct, and an unsound type system might be incorrect in some cases. Here's an example of unsoundness in TypeScript: https://www.typescriptlang.org/play/index.html#src=function%20messUpTheArray(arr%3A%20Array%3Cstring%20%7C%20number%3E)%3A%20void%20%7B%0D%0A%20%20%20%20arr.push(3)%3B%0D%0A%7D%0D%0A%0D%0Aconst%20strings%3A%20Array%3Cstring%3E%20%3D%20%5B'foo'%2C%20'bar'%5D%3B%0D%0AmessUpTheArray(strings)%3B%0D%0A%0D%0Aconst%20s%3A%20string%20%3D%20strings%5B2%5D%3B%0D%0Aconsole.log(s.toLowerCase())%0D%0A https://www.typescriptlang.org/play/index.html#src=function%... TypeScript incorrectly (but conveniently) says that Array<string> can be assigned to Array<string | number>, and you can exploit that to create an "s" variable that TypeScript thinks is a string but is actually a number. You can try the same code in Flow and it gives a type error: https://flow.org/try/#0GYVwdgxgLglg9mABAWwKYGd0FUAOAVAC1QEEAnUgQwE8AKC8gLkTMqoB50pSYwBzRAD6IwIZACNUpAHwBKJgDc4MACaIA3gChE2xPVIA6HCHQEaAZhkBuDQF8NGiAk6JO3PuiYtqHLj15TEAF5EAG0AcmA4ODCAGkQwsXowgF1rNExcQhJyahpXP3Qre0cwZw8XXz4girdedBCAJlSHJzgAG1R9NrhePP0oOAAZOAB3SQBhCnRUGhkZDSA https://flow.org/try/#0GYVwdgxgLglg9mABAWwKYGd0FUAOAVAC1QEEA...
  - maxbrunsfeld 9y ago

lewisl9029 9y ago

I'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 laid to rest with the introduction of the official ES modules spec (at least from the perspective of the application developer when it comes to module code they actually write), and I'm hoping an official type annotation spec can do the same for the JS static type checking landscape. Flow has already long-since demonstrated that it's perfectly possible to introduce useful type annotations to JS code without changing any runtime behavior whatsoever, and Flow and TypeScript have mostly converged on similar syntax and semantics when it comes to the type annotations. Given all this, I'd have thought that the standardization process would be pretty far along by now. Maybe someone more familiar with these matters can offer some insight on the seeming lack of progress?

yortus 9y ago
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_.28abandoned.29 https://en.wikipedia.org/wiki/ECMAScript#4th_Edition_.28aban... [2] https://www.ecma-international.org/activities/Languages/Language%20overview.pdf https://www.ecma-international.org/activities/Languages/Lang...
- WorldMaker 9y ago
  See also ActionScript [1] which was the closest real world language to an ES4 implementation, and how much it seems like Typescript/Flow. [1] https://en.wikipedia.org/wiki/ActionScript https://en.wikipedia.org/wiki/ActionScript
Vinnl 9y ago
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.

zefei 9y ago

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.

nl 9y ago

I 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.

makkesk8 9y ago

I've always wondered if you could let the engine do the type checking or create type definition files for you, maybe an optional v8 flag? This would be best case scenario so we could get rid of the tedious work that one has to put in to make an older library have type checking.

WorldMaker 9y ago
Typescript has inference for "plain" JS files if you use the `--allowJS` flag. That inference is also made available more directly in dts-gen [1], which is a tool built around Typescript inferencing that produces decent first pass type definition files for a library. dts-gen may be something to try the next time you need a definition file. (Personally, I still prefer to start a new definition file by hand, but it's good to have an automated option, even if only to double-check your work.) [1] https://github.com/Microsoft/dts-gen https://github.com/Microsoft/dts-gen