We're already using immutable values in Javascript thanks to React. This takes the form of manually cloning objects before mutating them, or using immutable-helpers, or immutable.js. This lets us reason about the data flow easily, and more importantly, allows React's shouldComponentUpdate do dirty check using fast reference equality.
Functional programming - in FP languages, all functions are curried by default. So you don't need the awkward `bind` function to use it. Add extremely light weight function definition syntax and tail-call optimizations, and we have a language with first-class functions.
Types - The adoption of Flow and TypeScript has brought to light a pent up need for some structure and sanity when writing large codebases. ReasonML is OCaml, and it has a very powerful and sound type system.
Since Immutability, functional programming, and Hindley-Milner type systems are becoming ever more necessary to build complex front-ends, it makes a lot of sense to simply use a language that was designed for it. OCaml in its current form has been around for more than 20 years, and the research and other languages that influenced, is even older. It is a fun beautiful language that lets you focus on the shape and structure of your data front and center.
I'd only add a mention of algebraic data types. I learned enough Elm and Haskell to realize the benefit that they bring to a codebase by allowing an expressive way to define the valid structure of an application's data and state.
Just noting that types have been around in programming longer than 2012 (when TypeScript first came out).
* Facebook is trying to improve the frontend stack out of the goodness of their hearts.
* Facebook is trying to drag their website into the 22nd century by abandoning JavaScript.
* Facebook wants to make the whole world dependent on their software and/or their patent grant.
* The React and Reason teams got drunk together one evening and this is the outcome.
* Yeah! I know I'm pure-hearted at least
* JavaScript will be around for a long time. Our stance is more gradual improvement than world-breaking changes all over the place. I'm still trying to phrase this correctly, because sometimes when Reason gets mentioned, the immediate reaction is "wow they're gonna rewrite everything again, kids...". Our interop story is pretty damn good. Please check it out!
* See ReasonReact's license =)
* The more successful Reason is, the less we'll drink. Kidding
Our discord channel is at discord.gg/reasonml. I think we're a bunch of pragmatic and nice folks. It'll take time for people to understand our stance, but blog posts like these really help showing what we're doing.
Some things I feel are an improvement over Javascript + Flow or Typescript are:
- immutable data structures built into the language (and more conventionally used)
- real pattern matching on types, 'variant' types (like enums in Rust)
- better dead code elimination (helps to keep browser payload size down)
- you can use expressions everywhere (allowing more flexible code style than Javascript)
- currying/partial evaluation
- under the hood it's really just OCaml, which has benefitted from many years of development and improvement
I am not a react developer but I have heard that one of the common complaints about React is ... that it's not Elm, or in more explicit terms, in case you don't know anything about Elm, ... that it's very easy to write code that will break if you poke it the wrong way.
In a static typed language such as Elm (or Reason, based on skimming briefly)... when you get input that can mutate the state of the program, it comes in the form of a message. The messages are typed, so you know what values to expect.
If you write a switch/case statement that handles a message type, the compiler will balk at you if you change the values that the message type can have, without updating the case statements that operate on that type to cover them all.
tl;dr: because runtime errors are a b
I group Reason (Ocaml/Bucklescript) and Fable (F#) together because F# is OCaml's sibling language on .Net. They're very similar. The two projects have similar philosophies, specifically to bring their ML variant to the javascript ecosystem in a module-by-module mixed-language fashion instead of having the language be its own island in the browser. Neither has a particularly large community but the Reason guys have been doing a better marketing push this month, at least from my perspective.
No way. Even in its most basic, untyped form the React model simplifies things all the way down your app pipeline. Errors that used to be common tend to naturally vanish over time.
I think before I would try Reason again there would need to be some effort put into streamlining setup and managing of the developer environment.
EDIT: Downvoted? Let's hear some feedback and other opinions maybe?
While this tutorial doesn't use the official bootstrap, you can see it here: https://facebook.github.io/reason/gettingStarted.html -- It's only a few lines in your terminal!
The integration with VSCode is pretty amazing, too.
The language/compiler itself is installed as an npm package(!). The only other things to install are the CLI tools (again, just an 'npm install' away) and optionally a plugin for your editor.
I think it would do these types of projects a lot of good to do something real using third party libraries. Convince developers and companies they're real, not toys. I still haven't seen a blog post explaining Elm along with a masonry library, socket.io, bootstrap, shopify, etc.
Probably I'm not getting what's the real use case for these things. It can't be writing web apps.
Large chunks of messenger.com are written in Reason. I'm pretty sure that qualifies as a 'web app'.
As I understand it, and I'm not very familiarized with Reason, the team behind the project is working hard to have a good interop story. We've seen the same thing with React's versioning scheme [1]! Going forward there shouldn't be horrible breaking changes, and in the cases where stuff must be broken, they appear to commit to providing a clear migration path that can be adopted gradually.
There's probably plenty of good use-cases for using something like Reason. Should it be used everywhere? No, certainly not. But having worked on a reasonably sized JavaScript web app, my experience has been that it becomes increasingly difficult to maintain as it grows. Even with something like Flow or TypeScript, you have to think very carefully any changes. Luckily, the JavaScript ecosystem has modularized everything quite heavily, so you can usually contain things that end up being "bad ideas" and gradually chip away at em.
The app I worked on wasn't even that large or complicated, so I have a very hard time wrapping my head around the challenges faced by engineers working on Facebook's scale.
[0] https://github.com/rrdelaney/bs-loader
[1] https://facebook.github.io/react/blog/2016/02/19/new-version...
