The original address: medium.freecodecamp.org/psst-heres-…

Do you use React to build the user interface? Well, me too. Next you’ll see why ReasonML is used to write React applications.

React is a cool way to build user interfaces. How can we make it even cooler?

To answer this question, what are the main problems with React as a JavaScript library?

React wasn’t originally developed for JavaScript

If you read React, some of its main principles are new to JavaScript, so let’s talk about immutability, functional programming principles, and especially the type system.

  • Immutability is a core principle of React, and you definitely don’t want to change props or state because if you do, you’ll face unpredictable consequences. In JavaScript, there is no immutability out of the box, we keep data immutable by convention, or use libraries like immutableJS to help us do this.
  • React is based on the principles of functional programming, because the React application is a combination of functions. JavaScript is not a functional programming language, although it has some features of functional programming, such as first-class functions (where functions are treated as first-class citizens in a programming language). We need libraries like Lodash/ FP or Ramda when we want to write elegant declarative code.
  • What about the type system? We use PropTypes in React to contract data types because JavaScript itself is not a statically typed language. To use robust static type checking, we still need libraries like Flow and TypeScript.

Is there a better language for React than JavaScript?

Luckily, we have ReasonML.

Because ReasonML is based on a functional programming language like OCaml, language features like immutability are built into ReasonML, and it makes sense that we have immutability out of the box. Reason also provides us with a powerful type system.

Reason

Reason is not a new language. It is another javascript-like syntax and toolchain for OCaml, a functional programming language that has been around for over 20 years. Reason was created (Flow, Infer) by Facebook developers who had already used OCaml in their projects.

Reason, with its C-like syntax, makes OCaml more acceptable to users of mainstream languages such as JavaScript or Java. It gives you better documentation (compared to OCaml) and a growing community. It also makes it easier to integrate with existing JavaScript code bases.

The Reason language is based on the OCaml language, and Reason has the same semantics as OCaml – only the syntax is different. This means that you can write OCaml using Reason’s javascript-like syntax. Therefore, you can take advantage of the power of OCaml, such as a powerful type system and pattern matching.

Let’s look at an example syntax for Reason.

let fizzbuzz = (i) = >
  switch (i mod 3, i mod 5) {|(0.0) = > "FizzBuzz"
  | (0, _) = > "Fizz"
  | (_, 0) = > "Buzz"
  | _= > string_of_int(i)
  };
for (i in 1 to 100) {
  Js.log(fizzbuzz(i))
};
Copy the code

Although we used pattern matching in this example, it’s still very similar to JavaScript, right? However, the only language available to the browser is still JavaScript, which means we need to compile it.

BuckleScript

One of Reason’s most powerful features is the BuckleScript compiler, which takes your Reason code and compiles it into readable and high-performance JavaScript, eliminating huge amounts of code. If you work on a team where not everyone is familiar with Reason, you’ll appreciate readability because they can still read the compiled JavaScript code. Because Reason is so similar to JavaScript, some Reason code doesn’t need to be changed by the compiler at all. As a result, you can enjoy the benefits of statically typed languages without having to change any code.

let add = (a, b) = > a + b;
add(6.9);
Copy the code

The above code works both in Reason and JavaScript.

BuckleScript ships with four libraries: a standard library called Belt (the OCaml standard library is lacking), and bindings to JavaScript, Node.js, and DOM apis.

Because BuckleScript is based on the OCaml compiler, you will get a much faster compile than Babel and several times faster than TypeScript.

Let’s compile the FizzBuzz algorithm we wrote in Reason.

As you can see, the generated JavaScript code is very readable, as if it had been written by a JavaScript developer. Reason compiles not only to JavaScript, but also to native languages and bytecodes. As a result, you can write a single application using Reason syntax and be able to run it in a browser on MacOS, Android, and iOS phones. Jared Forsyth has a game called Gravitron written in Reason that works on all of the platforms I just mentioned.

JavaScript interoperability

BuckleScript also gives us JavaScript interoperability. Not only can you paste your own running JavaScript code into the Reason code base, you can also interact with the Reason code with the JavaScript code. This means that you can easily integrate Reason code into your existing JavaScript code base. In addition, you can use all the JavaScript packages in the NPM ecosystem in your Reason code. For example, you can combine Flow, TypeScript, and Reason in a single project.

However, things are not that simple. To use JavaScript libraries or code in Reason, you need to first port it to Reason via the Reason binding. In other words, you need your untyped JavaScript code to be able to take advantage of Reason’s strong typing system.

Whenever you need to use JavaScript libraries in Reason code, check to see if the libraries have been ported to Reason by browsing the Reason Package Index (Redex) database. It is a website that uses the Reason binding to aggregate different libraries and tools written using Reason and JavaScript libraries.

If you find the library there, you can install it as a dependency and use it in the Reason application. However, if you don’t find your library, you’ll need to write the Reason binding yourself. If you’re new to Reason, keep in mind that writing bindings is not something you want to start, as it is one of the more challenging things in the Reason ecosystem.

Luckily, I’m writing a post about writing Reason bindings, so stay tuned! When you need some functionality in the JavaScript library, you don’t need to write the Reason binding for the entire library. You can only do this for functions or components that you want to use.

ReasonReact

This article is about React in Reason, thanks to the ReasonReact library.

Now you might be thinking “I still don’t know why I should use React in Reason.” We’ve already mentioned the main Reason for this – Reason is more React compatible than JavaScript.

Why is it more compatible? Because React was developed for Reason, or more accurately, OCaml.

The first prototype of React was developed by Facebook and written in StandardML, OCaml’s cousin. It is then transferred to OCaml. React is also transcribed as JavaScript.

This is because the entire web is using JavaScript, and saying “now we’ll build the UI in OCaml” isn’t very smart. It works –React in JavaScript is widely adopted.

Hence, React is used as a JavaScript library. React with other libraries and languages – Elm, Redux, Recompose, Ramda and PureScript – popular functional programming in JavaScript. With the rise of Flow and TypeScript, static typing has become popular. As a result, functional programming paradigms with static typing became dominant in the front-end world.

In 2016, Bloomberg developed and open-source BuckleScript, a compiler that converts OCaml into JavaScript.

This enabled them to write secure code on the front end using OCaml’s strong typing system. They take the optimized and extremely fast OCaml compiler and swap the backend to generate native code for JavaScript generation.

The spread of functional programming and the release of BuckleScript provided an ideal environment for Facebook to go back to the original ideas of React written in ML.

They took OCaml semantics and JavaScript syntax and created Reason. They also created a Reason wrapper around the React-ReasonReact library, among other features, such as encapsulating the Redux principle in stateful components. By doing so, they returned React to its original roots.

React in Reason energy

When React came into JavaScript, we adapted JavaScript to meet the needs of React by introducing various libraries and tools.

This also means that our project is more dependent. Not to mention that these libraries are still under development and regularly introduce major changes. Therefore, you need to be careful to maintain these dependencies in your project. This adds another layer of complexity to JavaScript development. Your typical React application has at least the following dependencies:

  • Static type – Flow/TypeScript
  • Immutability – immutableJS
  • Routing – ReactRouter
  • Format – Prettier
  • linting – ESLint
  • Auxiliary functions – Ramda/Lodash

Now let’s use ReasonReact instead of JavaScript React. Do we still need all these dependencies?

  • Static typing – built-in
  • Immutability – built-in
  • Routing – Built in
  • Format – Built in
  • Linting – built-in
  • Accessibility – built in

You can learn more about these built-in features in my other posts.

In the ReasonReact application, you don’t need these and many other dependencies because many of the key features that make your development easier are already included in the language itself. As a result, it becomes easier to maintain your packages, and you don’t add complexity over time. This is thanks to OCaml, which is more than 20 years old. It is a mature language with all its core principles in place and stable.

Wrap-up

At first, the creators of Reason had two choices. Take JavaScript and make it better in some way. By doing so, they also need to deal with their historical burden. But they took a different approach. They took OCaml as a mature language with excellent performance and modified it to look like JavaScript. React is also based on OCaml principles. That’s why you get a better developer experience when you use it in Reason. React in Reason represents a safer way to build React components, because the strong typing system has been answered and you don’t have to deal with most JavaScript (legacy) issues.

What ‘s next?

If you’re from the JavaScript world, you can start using Reason more easily because of its syntactic similarity to JavaScript.

It’s easier if you’ve been programming in React because you can use all your React knowledge because ReasonReact has the same mental model and a very similar workflow as React.

This means you don’t have to start from scratch.

As you develop, you will learn reason.

The best way to start using Reason in a project is gradually.

I already mentioned that you can use Reason code and use it in JavaScript, and vice versa.

You can do the same with ReasonReact. You can use the ReasonReact component and use it in your React JavaScript application and vice versa.

This incremental approach has been chosen by Facebook developers who use Reason extensively when developing Facebook Messenger applications.

If you want to build an application using React in Reason and learn the basics of Reason in a practical way, check out my other articles where we’ll build a Tic Tac Toe game together.

If you have any questions, criticisms, observations or improvement tips, please feel free to comment below or contact me via Twitter or my blog.