should we keep flow?

[magopian]

This is an honest, open question.

I've tried using flow from the get go on this project, assuming that it was a good practice to have some level of type proof.

Some new contributors are around (hey @peterbe) and more might come in the near future (hey @mythmon @andymikulski @rehandalal), and so the question is up: should we keep it?

I'm personally +0 on keeping it: I'm not sure the benefit we get from flow's
non complete type system (with no approximative type inference and ugly error messages) compensate for the increased effort in both writing the code and maintaining it. I've had a couple of times where I had to spend hours fixing a flow issue (after an update, or the addition of a new dependency), while on the other hand not having the peace of mind I would have with a full and complete type system with good type inference and nice error messages (like in Reason or Elm).

What do you folks think? Have you used flow already, are you familiar with it? Would you like to use it? Do you know if there's some kind of consensus among the other front end teams at Mozilla?

[peterbe]

Can we add it later when the ("Delivery Console") is thousands of lines of code and tens of active contributors? At least, unlike TypeScript, you can sprinkle it into existing code and get better checks where it can.

Note! If you use Flow for your React components you don't have to bother with PropType which is a nice bonus.

Personally I'm quite attracted to Flow and as a layman more attracted to it than TypeScript and ReasonML because of human reasons. It seems to be the least invasive (compared to TypeScript) and most mature (maintained by the React people and already works great with create-react-app). But if it scares people I think we should avoid it. But if we're going to be a bunch of different people working on the same code, I think we should use it.

[mythmon]

I haven't worked with Flow or TypeScript on any sizable project, just a few toys. I am however a fan of good type systems, and I think Flow can be used that way. I'm not scared away by type systems, and I'm willing to go through a bit of extra rigor if it means a more maintainable system in the long term.

I'm -1 on using Elm or Reason, as they are too far away from JS for me. TypeScript and Flow are both explicitly supersets of JS syntax. That way you only have to learn a type system and not a new language when you're coming from JS. Elm and Reason, as interesting as they are, don't have that property.

I'm weakly in favor of either TypeScript or Flow, where it fits well into other workflows and doesn't get in the way. I think Flow is easier to integrate with other webpack-based workflows, but TypeScript has a better integrated experience if you buy in all the way. It sounds like Flow has been more work than it saved in practice though? That's not great.

In the past, @rehandalal, @andymikulski and I talked about type annotations as a lighter-weight form of documentation. It read better to us than JSDoc @param notation most of the time, and lets JSDoc focus on the interesting human parts. We never really implemented any form of type checking in our projects though.

Note! If you use Flow for your React components you don't have to bother with PropType which is a nice bonus.

Also, prop types are a very weak projection in React, I've found. I haven't seen a way to make them break a CI build, so they mostly end up being noise in the console we fix up every once in awhile. I've found that rules that aren't enforced in CI rarely get enforced.

[andymikulski]

Personally, I'm a huge fan of TypeScript - I use it for almost all of my side projects. Admittedly, I haven't tried Flow in quite some time, so perhaps they're a bit more interchangeable than I think. For TS, the support for generics, union types, and the intellisense hooks for VSCode are all fantastic imo. It feels like you're writing in a "real language" while having the flexibility/wackiness of JS.

I'm -1 on using Elm or Reason, as they are too far away from JS for me.

I agree with @mythmon - I think JavaScript (ES6+) or a JS-derived language is the way to go. In terms of accessibility, I think more devs would be familiar with something based on JS rather than OCaml.

Regardless of what we end up working with, I do believe we should have some sort of type checking. If anything, type annotations would provide an easier onboarding experience for devs that would like to contribute.

[rehandalal]

Also, prop types are a very weak projection in React, I've found. I haven't seen a way to make them break a CI build, so they mostly end up being noise in the console we fix up every once in awhile. I've found that rules that aren't enforced in CI rarely get enforced.

I basically mirror the above sentiments.

I'm not 100% sold on Flow vs TypeScript and am still looking for compelling arguments for one over the other.

I also have to be a -1 on Elm or Reason. I dug deeper into both this afternoon and I strongly believe that if the goal is to reduce the barrier to entry then this is the wrong choice.

[magopian]

We've been talking about "barrier to entry", but without having defined "for who".

Is it the barrier to entry for

• current frontend devs at Mozilla outside of Firefox (which I guess are nowadays mostly using react, but are we even sure about that? A LOT of projects used to be based on jquery a couple of years ago)
• current frontend devs at Mozilla inside of Firefox (I believe react has been introduced there two years ago, i'm not sure about their adoption of it)
• people who are currently writing some form of JS (maybe outside of Mozilla)
• backend developers who would like to write a UI for their service

What is our target?

If our target is people writing JS for Firefox, we might want to copy their stack verbatim? If our target is "mostly ourselves" (because we are the ones who are going to write the UIs), I guess we can be much more liberal regarding the stack.

But I would go even further: if we are the target, and if you already chose a stack for Normandy, and seeing that this project dwarfs delivery-dashboard on just about every metric (size, complexity, number of contributors, age, current number of maintainers...), we could (should?) just copy the stack (I would be the only one needing to "adapt" to it, and maybe @peterbe, but I reckon he has way more experience than I do in frontend dev).