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:

Comparing Hattip Vs Express Js For Modern Application Development

Comparing Hattip vs. Express.js for modern app development

Explore what Hattip is, how it works, its benefits and key features, and the differences between Hattip and Express.js.

Antonello Zanini
May 2, 2024 â‹… 8 min read
Using React Shepherd To Build A Site Tour

Using React Shepherd to build a site tour

React Shepherd stands out as a site tour library due to its elegant UI and out-of-the-box, easy-to-use React Context implementation.

Onuorah Bonaventure
May 1, 2024 â‹… 14 min read
A Guide To Cookies In Next Js

A guide to cookies in Next.js

Cookies are crucial to web development. This article will explore how to handle cookies in your Next.js applications.

Georgey V B
Apr 30, 2024 â‹… 10 min read
Handling Dates In JavaScript With Tempo

Handling dates in JavaScript with Tempo

Use the Tempo library to format dates and times in JavaScript while accounting for time zones, daylight saying time, and date internationalization.

Amazing Enyichi Agu
Apr 30, 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