A ReasonReact Tutorial | Hacker News Reader

A ReasonReact Tutorial

jaredforsyth.com

161 pointskcorbitt28 comments

Reason/OCaml has brought back my love of programming. It is functional, statically typed, and extremely pragmatic. You can program it just like an imperative language and write mutating code without any ceremony, or you can write purely functional code and get the benefits of equational reasoning.

The pragmatism comes from the fact that you can use it today on the browser. Unlike most other compile-to-js languages which are fairly new, OCaml is a mature language with a stable ecosystem. Its history dates back to the 80s when Robin Milner et al started building a theorem prover which evolved into a language that can be used for general purpose programming with strong compile-time guarantees thanks to the Hindley-Milner type system.

Reason is a new syntax for OCaml, and it is being lead by Jordan Walke and Cheng Lou. Jordan prototyped the first versions of React in OCaml, and React has planted nubs of FP ideas like immutability, and introduced a functional approach to building composable UIs which has so far been dominated by object-oriented mutation-heavy paradigms. The team is taking it one step further by bringing the entire FP paradigm to the browser.

The Reason syntax is currently functional just like OCaml and Haskell:

  let sum a b => a + b;
  print_int (sum 1 2);

The Reason team is considering changing it to a syntax that ALGOL-style programmers are familiar with. There are more details here: https://github.com/facebook/reason/pull/1299. So it'd become:

  let sum(a, b) => a + b;
  print_int(sum(1,2));

So in essence Reason can be considered a super-set of Javascript that adds powerful static typing, immutable values, and almost-first-class modules. This will greatly remove a source of friction for programmers new to FP, and in turn should help in the mainstream adoption of a strongly typed functional programming language. I think this would be a wonderful thing for practicing programmers in that more of us will be able to enjoy statically typed FP, and for the industry in general because we can now expect better programming practices and more robust systems.

One of the things I dislike most about JavaScript is the syntax. I always thought the Javaesque syntax hid the some of the nice semantics underneath. CoffeeScript and LiveScript help reveal that language.

I really hope Reason doesn't make the same mistake and go for a more ALGOL-like syntax. My hope would be that they go for an even cleaner syntax than the current, more like Standard ML and Elm. The semicolons and the curly braces will not be missed.

It's not ALGOL-like syntax that's a problem with JS, it's the fact that for decades the JS syntax was frozen, without any significant additions to the initial, very minimal, syntax. The same is true for JS standard library: it's almost non-existent compared to Python or Ruby, and even Lua has more builtins (IIRC).

In other words, you can have good looking FP support with braces and semicolons. It's just that you need to build such support into the language, and for JS it was impossible for a long time.

I'm not complaining that JS isn't Haskell. Underneath the C/Java syntax JS is a small, simle, Lispy, dynamic language — if you like that kind of thing. JS' syntax hide that. CoffeeScript helped reveal it.

> In other words, you can have good looking FP support with braces and semicolons.

Of course. But why would you?

I love braces and semicolons and my biggest gripe with CoffeeScript and HAML and Python was that they used space to delimit blocks. The good thing about braces is that moving code around is easy and it makes auto-formatting possible. refmt, prettier etc. are all amazing to have.

But in terms of syntactic preferences, it is quite subjective and I wouldn't claim there is one true answer.

I agree. I wish the Reason team would just use BuckleScript and pure OCaml syntax. I really don't like the addition of syntactic noise that Reason has introduced.

You already have that option. Reason's syntax is for the vast majority of developers that do not prefer OCaml's syntax, the majority of them not being OCaml programmers.

FYI, this has been around for a long time ;)

I was the creator of the Opa project, cf. http://opalang.org which did almost that since 2009...

> The pragmatism comes from the fact that you can use it today on the browser.

Part of that pragmatism was already available in OCaml since it's inception.

> The Reason syntax is currently functional just like OCaml and Haskell:

Reason does not prohibit --thus "allows-- OO, just as it is available in OCaml. Though both communities prefer FP style. I'd say OCaml (and therefor Reason) is FP first and OO on top of that. Contrary to Ruby's OO first and FP on top of that. Some say OCaml's OO is in there to sell it to mgmt :)

> So in essence Reason can be considered a super-set of Javascript

I do not think that's strictly true, but I get what you're trying to say.

> The Reason team is considering changing it to a syntax that ALGOL-style programmers are familiar with.

I really like the syntax as it is, and kind of hope "for my own sake" they keep it in line with OCaml and Haskell. But if this kind of syntax is needed to bring together a critical mass and start an FP revolution, then it is "just syntax" and I easily compromise on that!

> OCaml (and therefor Reason) is FP first and OO on top of that

That's a general opinion, which I find quite sad. The object system in OCaml (the 'O' in the name stands for something...) is actually very well designed and is very different from what you may be used to from languages like Java (or even Ruby). It uses structural instead of nominal typing and separates class definition and object construction, while still being statically typed. Actually, lack of this particular OO system in F# is my biggest complaint against it.

I would love to learn more about this. I've been programming in OCaml for a few months now and have stuck to records and immutable updates and modules for grouping behaviour. I really like this style compared to the object-oriented programming I was doing in Ruby.

Real World OCaml has a chapter on objects and I'll give it one more read. But are there any other articles/links that expands on OCaml's object system and how it compares to conventional OO?

Excellent post, Jared. Thanks for making it.

I figured I should share a project I made as well with ReasonReact. I'm a noob to React and frontend programming in general, but I was surprised by how easily it was to pick it up. I created a simple game of Snake over a weekend just to test it out. Great programming experience, great first impression.

edit: live demo: (warning: not mobile friendly) http://192.241.133.216/projects/websnake/index.html

For people who want to look at some Reason code, here are some more projects:

https://github.com/jsdf/reason-react-hacker-news (rather unimaginatively, a hacker news app)

https://github.com/jsdf/lisp.re (native, the start of a lisp in Reason)

This is a really nice tutorial, and the interactive elements showing type info are great!

Reason is an awesome project. It's still early, but I could even see this having the power to mainstream an ML (given the fact it's picking up steam in the enormous JS community)

It's syntax fixes pretty much every issue I ever had with OCaml as well (and feels pretty nice to write if you're coming from a JS background)

This is cool stuff! Awesome to see OCaml as a platform moving forward with Reason/Bucklescript/React.

Loving Reasonml so far - super good tooling/ecosystem and good interpolation with JS.

Are you running on node or some other backend?

Currently just playing around with the frontend(React) only. But the development experience (especially with VSCode + merlin) has been awesome so far. If I were to build a backend I would probably go for Elixir :P

Oh cool, I just posted about that on the Elixir Forum https://elixirforum.com/t/reasonml-with-phoenix/6643

It would be awesome if Reason/OCaml had a backend for the Erlang BEAM VM -- could make things like Nuxt.js in OCaml possible. Full-stack type safety benefits would be awesome!

Being able to use React is great and all but What if you want to use service workers? Web workers? Canvas? Websockets? Type defining or writing wrappers around every web specific API I need to use is a non-starter for me.

Is there any ongoing or planned effort to integrate web technologies into ReasonML (as in provide up to date and comprehensive typings)?

There are actually a ton of binding already defined here: https://github.com/BuckleTypes

Further, anything already typed with Flow or Typescript can be converted with this. https://github.com/rrdelaney/ReasonablyTyped

Beyond that, defining js types and interop with Reason/BS has probably been the most pleasant experience in a compile-to lang that I've used.

thanks for the post, great job. i'm using react with clojurescript (reagent). i also would love to see a react tutorial with js_of_ocaml.

I'd say BuckleScript (BS) has already overtaken js_of_ocaml. If I'm not mistaken BS even forked some code of it.

Comparison with Clojurescript?

Advanced type system, language level pattern matching, ML syntax, compiles to clean and readable JS in comparison to what is emitted by the Clojurescript compiler

SUPA HOT FIREEEE

Reply on news.ycombinator.com