John Au-Yeung
Oct 28, 2021 ⋅ 7 min read

Comparing statically typed JavaScript implementations

John Au-Yeung I'm a web developer interested in JavaScript stuff.

Recent posts:

Exploring Advanced Support For Vite 5 In Storybook 8

Exploring advanced support for Vite 5 in Storybook 8

Explore the latest updates in Storybook 8, focusing on its improved support for Vite 5 as a build tool.

Will Soares
Jun 20, 2024 ⋅ 5 min read
Exploring Angular 18's Redirectcommand Class And Let Block

Exploring Angular 18’s RedirectCommand class and @let block

Angular’s latest update brings greater control over redirects and the ability to define and assign variables within the template.

Lewis Cianci
Jun 19, 2024 ⋅ 6 min read
Showing Progress For Page Transitions In Next Js

Showing progress for page transitions in Next.js

Progress bars help create a smooth UX during page transitions in your Next.js app, informing users that their request is processing.

Elijah Agbonze
Jun 19, 2024 ⋅ 9 min read
Qwik Adoption Guide Overview Examples And Alternatives

Qwik adoption guide: Overview, examples, and alternatives

Qwik’s focus on performance, innovative features, and commitment to DX make it a fantastic choice for building high-performance web apps.

Fimber Elemuwa
Jun 18, 2024 ⋅ 10 min read
View all posts

8 Replies to "Comparing statically typed JavaScript implementations"

  1. After writing writing a few reasonably sized applications with flow, I’ve got to say I’m a fan and haven’t run into many of the cons you list in the article (my IDE supports it, it has a decent community, and there are community-created types for popular libraries).

    For me, flow’s biggest benefits are that it’s easy add (can be done incrementally) and remove, and it works with every system out of box.

  2. I don’t know why people compare TypeScript so much with Flow. Both of them are great, for different teams. In 2017 we built our new frontend technology with Angular and TS but we encountered difficulties shortly, especially when it came to debugging Angular (we are mostly backend devs, inexperienced in frontend). But we found ourselves less productive in TS (even if it’s closer to the type system we are used to in Java) and didn’t even use it in a strict way, we couldn’t see the benefits to pursue it further. Because of that, at the end of 2019 we have adopted a new stack, React with Hooks and Flow. It’s just that it is more suitable for our team, the features are delivered faster, a good choice for our 3-man army on the frontend. I recommend people to experiment with both and please don’t disconsider Flow, it is pretty powerful. We got sold on the idea that TS is for Java devs, but this wasn’t true in our case. It could be in yours. Moreover, we are using IntelliJ for everything JavaScript and I have to say the Ultimate version has strong Flow support, didn’t let us down.

  3. “Flow checks types locally and doesn’t have a language server or type definitions like TypeScript. We need to run the Flow compiler to check our app, whereas we can check our JavaScript code with a TypeScript language server as we’re typing code into our files.”
    This is completely wrong. Flow has always been able to do the type checking in real time (look for “flow check-contents”). Same as TS Flow has plugins for popular editors and IDE’s (https://flow.org/en/docs/editors/) which are using this API.

  4. A really biased comparison, this would seem to me. I have used both flow and TypeScript extensively and can concur with previous replies that:
    – Flow is easier to integrate incrementally into an existing codebase thatn TypScript.
    – It is well supported in Webstorm, PhpStorm and other JetBrain products. There are several good plugins for VSCode as well, and they can give real time flow checking too.
    – Community support is fine enough. To be honest, I’ve had more trouble finding solutions to TypeScript issues than I’ve had with Flow. But that may be personal.
    – The argument that libraries do not support it is a bit weird. Never looked at https://github.com/flow-typed/flow-typed/tree/master/definitions/npm?

  5. I agree with those above. This is a super completely bias comparison from someone who hasn’t put enough effort into flow to create a fair comparison.

    – React does not offer TS out of the box, but it does for Flow because React defs are built directly into the Flow base defs. I think you may be confusing React from CRA, which are two completely different things.
    – The licenses you specified can have the wrong impression saying that Flow’s license is `Facebook`? They’re both MIT
    – Your development experience comparison also shows the lack of research. Yes there are less libraries that are shipped with flowtype by default but just like TS, these are added to the flow-typed library.
    – Your tutorial for installation of Flow should have at least given instructions to install `flow-bin`. Which is the equivalent to the `typescript` package in flow world.

    For those who are reading the comments to learn more here are my 2 cents.
    I think it all depends on what you’re trying to accomplish and what your stack is. If you’re coming from a node or react background, flow may work for you.
    Flow’s main driving force is soundness, which helps you prevent runtime errors through type checking and statically analysing your code.

    Its focus is to prevent runtime errors but of course because it always compiles down to Javascript types can always be typed wrong as its done by humans, it doesn’t block compiling. In that case I recommend putting lint-staged so that you at least don’t comment code with flow errors.

  6. I don’t really get how PropTypes is part of this article. PropTypes is NOT a static typing system – it tests the types on runtime. It also built specifically for React component props checking. A very narrow usage.
    It feels that someone needed here to compare 3 systems so PropTypes was thrown into the mix.

Leave a Reply