2021-10-28
2170
#typescript
John Au-Yeung
14269
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:

Nx Adoption Guide: Overview, Examples, And Alternatives

Nx adoption guide: Overview, examples, and alternatives

Let’s explore Nx features, use cases, alternatives, and more to help you assess whether it’s the right tool for your needs.

Andrew Evans
Mar 28, 2024 â‹… 9 min read
Understanding Security In React Native Applications

Understanding security in React Native applications

Explore the various security threats facing React Native mobile applications and how to mitigate them.

Wisdom Ekpotu
Mar 27, 2024 â‹… 10 min read
Warp Adoption Guide: Overview, Examples, And Alternatives

warp adoption guide: Overview, examples, and alternatives

The warp web framework for Rust offers many enticing features. Let’s see when and why you should consider using warp in your projects.

Ukeje Goodness
Mar 26, 2024 â‹… 8 min read
Integrating Next Js And Signalr For Enhanced Real Time Web App Capabilities

Integrating Next.js and SignalR to build real-time web apps

In this tutorial, you’ll learn how to integrate Next.js and SignalR to build an enhanced real-time web application.

Clara Ekekenta
Mar 25, 2024 â‹… 8 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