Reason vs JavaScript

The need to write statically typed code with fewer bugs and easier refactoring birthed the language we all know today as Reason. Although Reason was created to improve how frontend developers write code by avoiding lots of bugs caused by JavaScript for not having a static type system, it’s still necessary to evaluate both languages to compare the ease of integration into our workflow and what using them feels like in general. In this post, we’ll study both languages and compare features such as tooling, documentation, and ecosystem.

Tooling

JavaScript

To write basic JavaScript modern code, there are a lot of tools to choose from for the newbie developer. While this could sound exiting, it could also be very confusing eventually. The confusion begins when you come across a myriad of transpilers, module bundlers, task runners, test frameworks and even linters. Names like Webpack, Mocha, Gulp, ESLint, and Babel are often thrown around when discussing JavaScript. While most tools have alternatives, one major problem remains knowing what to use and how to configure it. As a result, JavaScript developers arguably spend quite an amount of time deciding what tools to use and learning how to use them.

Verdict: Awesome language but just be prepared to spend a lot of time learning about tools instead of writing actual code. This also goes both ways as it’s an advantage – for everyone who works with JavaScript, there’s something to suit you.

Reason

Tooling in Reason is kept as basic and simplistic as possible. This is done by Merlin – Reason’s solution to editor integration that provides awesome support for type information, auto-completion, and general linting. When working with Merlin, you’ll require a .merlin file in the project that describes the locations of your code but not to worry because BuckleScript (a Reason to JavaScript compiler) generates this file for you.

Verdict: Quick and straight to the point. Tools get out of your way and let you focus on what’s more important – actually writing code. However the lack of alternatives to choose from could also prove to be detrimental sometimes.

Ecosystem and documentation

JavaScript

JavaScript’s vast ecosystem can be successfully broken down into five segments:

1. Frontend development
2. Command line interface (CLI) applications
3. Desktop (GUI) applications
4. Mobile applications
5. Backend development

The exciting thing about JavaScript’s ecosystem is that the possibilities are endless and will remain so for a long period of time. JavaScript’s ecosystem keeps on coming up with new techniques, frameworks, modules and even language specs being defined all the time. Developers should refrain from trying out every single tool out there just to feel smarter. Always remember that if it works for you, it’s the right stack.

As for JavaScript’s documentation, there are tons of literally inexhaustible materials for a lot of frameworks, tools, and resources that you can get your hands dirty with.

Verdict: It’s got a robust and vibrant community where you can get all the resources you need.

Reason

ReasonML’s ecosystem is still young but growing. Most of the information gotten on it is derived from OCaml due to the fact that it is written in that language. Reason’s two forefront libraries right now are BuckleScript and ReasonReact – a library that leverages the features of Reason and combines them with React.

Although over 50% of Facebook Messenger is written in Reason, there’s still much work to be done. The Reason team just released version 3.2.0 which includes features like whitespace tuning, semicolon relaxation, and Unicode string printing. Other sources of information on the Reason ecosystem include:

• Reason’s community page points to chat rooms, Twitter accounts, etc.
• Awesome ReasonML is a page with Reason resources.

Reason’s documentation is well written and concise, so is OCaml’s, which complements Reason’s documentation.

Verdict: Still young thus it’s ideal for small and medium sized projects. Companies that want to migrate a large codebase might need to “wait it out” for a while.

Static Typing

The reason is not a totally different language but a statically typed syntax that maps over to JavaScript while placing emphasis on simplicity, performance, and pragmatism. The key limitations to be discussed here are the pros and cons of what makes Reason different from normal JavaScript code – static typing.

Pros of static typing

• Earlier detection of programming mistakes – you’re more likely to prevent adding an integer to a boolean when working with static typing.
• One can refactor with greater confidence since a large class of errors introduced during refactoring will end up as type errors. Let’s say you’ve got a function that currently returns a single number, and wish to modify it to return a list of numbers. In a static language, updating the declared type signature and fixing any compile errors will catch most, if not all places that need updating.
• Using static types can ease the mental burden of writing programs, by automatically tracking information that you would otherwise have to track mentally in some fashion. Let’s say you’re writing a tricky function, and have two values in scope, x and y. The xyou pulled out of a dictionary, the y was the result of calling foo(23). Is it safe to call x(y)? Types provide an automated, precise answer to this question.
• Performance-wise, it’s easier to efficiently execute programs that are statically typed. Dynamic languages executed naively will have much more dynamic dispatch and runtime checks happening. And while it’s possible to execute dynamic languages efficiently, it’s more complicated.

Cons of static typing

• Types require some investment up front to become fluent in thus static typing takes time to learn.
• It is an additional layer of complexity. You are basically writing the code again, on a different level.
• Some tasks, especially around generic programming, can be very easily expressed in a dynamic language but require more machinery in a static language. For instance, a generic serialization library can be written in a dynamic language, without anything fancy, but providing the same thing in a static language requires more machinery (an example is Haskell’s generics support), and is sometimes more complicated to use.
• You lose some interactivity and compiling takes time. On the other hand, it’s become almost impossible to avoid compilation in the JavaScript ecosystem.

Summary

The JavaScript radar right now is bigger than ever and can only get bigger with time. The reason right now feels like a blip on that radar but don’t expect it to remain the same, its amazing features and support from the Facebook team could see it branch out sooner than we expect. Static typing remains awesome for those who know how to use it well. Although it’s recommended to implement static typing once your project grows to a certain size, always be prudent enough to remember one important rule when trying to choose – use whatever enhances your productivity.