Question about Facebook's strategy with Reason & Flow

#1

Hello folks, first post.
I’m an avid (and happy) user of Flow and I’m just trying out Reason now, experiences are positive, good work.

My question is this: Facebook has made significant investment into Flow and now seems to be the main investor in Reason, but using it for the same things that Flow was being used for ; so why ?

  1. Is there some flaw with the Flow technique which lead to the need for a new, more strict approach to writing javascript ?
  2. Is it imagined that Reason can be eventually compiled to WebAssembly which will out-perform Flow/Javascript ?
  3. Does BuckleScript compiled Reason perform significantly better than hand written JS (with Flow) ?
  4. Something else I didn’t think of ?

I don’t want to be pushy but I think it is reasonable for the Flow and Reason communities to know whether the Facebook wants to develop frontend more in Flow/JS or more in Reason as time goes on, and also why.

Thanks for your time and your great software.
Caleb

#2

Flow helps catch a lot of errors in JavaScript if you fully utilize it. However, the ML type system is really really good once you dive into what it can do. It’s like a deluxe version of Flow. When used properly it does way more than making sure you don’t pass in an int when you should have passed in a string. Facebook cut bug reports down dramatically after switching the codebase to Reason (i’m assuming they were using Flow before too).

There isn’t a flaw with Flow or Typescript but it’s a very bolt on experience. If you use other libraries without flow types you’ll lose type safety across your app. Flow is good but Reason is like Flow on steroids.

The ML type system has a LOT more power than type systems like Java/Flow/Typescript. You can actually get the compiler to eliminate invalid states in your program at compile time. I posted a video here that goes into detail with a great example (think about how this would change your React State if you had some kind of a connection status view for example: Showcase where type is extremely useful in your program?)

They do have OCaml compiling to WebAssembly but I think the whole ecosystem is waiting on a built in garbage collector before anything can realistically be used. However, in React Native there’s a possibility to run native OCaml there instead of JS.


Some of the things that I didn’t realize going in:

  • Type inference - this is a huge help for me… you can get really far without writing any types annotations. You can lock down the interface later in an interface file or by manually adding the type annotations in the source code. Using Flow feels like your back in Java, having to type a lot more.

  • 100% type safety - When I was writing Flow types I had a hard time getting 100% coverage across my code… this left holes in the program and promoted more laziness as I can’t get 100% coverage anyway.

  • Stable language - OCaml has been around for decades so the type system won’t need to be constantly changed (as opposed to a new flow type version coming out). Reason’s syntax may change as it’s newer, but a lot of those breaking changes have code mods.

. There’s also work going on to make it easier for JS apps to interact with Reason component by providing flow and typescript type definitions automatically. I would checkout this interview with the creator to learn why Facebook chose to back this project:

and

Hope this helps! :beers: