For over a year now, I’ve been using ReScript for a side project. Prior to that, I spent around 7 years working as a JavaScript developer. Additionally, I have experience working with ActionScript and TypeScript from earlier stages in my career.
In this article, I will share my reflections on using ReScript to write a React Native app and compare some of the main differences between ReScript and JavaScript.
#1: Type System
ReScript easily wins here.
In a dynamically typed system (like JavaScript) variables are not bound to a specific type at compile time.
This can lead to a range of issues related to type mismatches, null pointer exceptions and other runtime errors.
In contrast, Rescript is a statically-typed language, which means that every variable and function is bound to a specific data type at compile time.
This allows the compiler to detect type mismatches and other errors before the code is executed, and to provide more informative error messages that can lead you to diagnose and fix issues more quickly.
In my experience I would say using ReScript would reduce bugs being introduced into a large scale production codebase by about 30% to 40%.
This percentage of course is a made up number, but I’m fairly convinced at this point the gains would be fairly substantial.
At the end of the day a large reason for why I think this number is so big is the result of ReScript being strongly and statically typed.
#2: Control Structures
ReScript easily wins here.
Since I had not worked with a language that leveraged the Option type before, I was pleasantly surprised how useful and enjoyable it is to work with.
When Option is paired with switch, they combine to offer superior pattern matching capabilities, allowing for concise control structures that are easy to read and ensure that all possible edge cases are accounted for.
When I return to JavaScript, the if/else and switch control structures feel outdated, more error prone and not as expressive.
Despite its simple appearance, the switch control structure in ReScript is undeniably one of the language’s most valuable features. It’s difficult to understand why this control structure isn’t a staple in all modern programming languages, as opposed to if/else, which seems to be the default.
#3: CLI, Compiler and Build System
ReScript easily wins here.
I can’t calculate the amount of time I’ve spent setting up Webpack (or back in the day GulpJS), or troubleshooting some type of problem with a JavaScript compiler.
This is still somewhat of a major problem in JavaScript.
Without a “standard compiler” but desperately needing one for all kinds of reasons, the building of JavaScript has always been a bit of a wild, wild west.
When you have been a JavaScript developer for a long time and you try something like Rust or ReScript, you can’t help but think, “why aren’t all programming languages complied like this”?
JavaScript is a de facto “bring your own compiler” language, and it’s a bit ridiculous at this point, even given its historical roots as a language that was never compiled or had modules to begin with.
It’s conception was as a very basic “Scripting Language”; and only by back filling functionality is the language usable in large scale projects.
With JavaScript compilers one can easily tweak the language and although I appreciate the freedom and innovation that experimenting with language syntax can bring, I believe that in production environments, most programmers would opt for a more conventional compiler and build system if only it were available out of the box with JavaScript.
I’ve spent all of 2 minutes setting up ReScript and over the last year of working on a project never had to think twice about.
I have great confidence in the compiler and build system and the fact that I don’t have to muck about with configuration is a big advantage.
#4: Library Ecosystem
JavaScript easily wins here.
Javascript has the largest open source community of any programming language on earth ever.
“npm —install-any-library-in-entire-universe” and you are up and running with any type of external library you will ever need.
The one caveat is that ReScript does have a robust interop to import JavaScript libraries.
But word of warning for us JavaScript minded individuals there does seem to be a steep learning curve.
In retrospect, as I reflect on my experience of grappling with ReScript’s interop, I realize that the steep learning curve may be attributed to the fact that ReScript is a more opinionated language. In contrast, JavaScript is an extremely expressive language that can emulate nearly any design pattern.
This naturally causes the design of any interop to to be a bit more nuanced and complicated than one would expect.
The long evolving and many module systems of JavaScript are probably an additional factor.
I can confirm that given a bit of time and patience if you intend to learn ReScript you will eventually wrap your head around ReScript’s interop to the point where it becomes intuitive.
One beneficial side effect to having to write an interop every time you want to import a library is it forces you to review the 3rd party or open source code of the library before utilizing the API in ReScript.
From the above practice I’ve often abandoned libraries after reviewing them, opting instead to either write the functionality that I needed or search for a better alternative.
In general we as developers should be doing this every time we import a library anyways, but I’m grateful that ReScript’s interop, by default, enforces this practice.
Furthermore, given that it’s unlikely for ReScript to ever develop a library ecosystem as extensive and diverse as JavaScript’s, learning the interop is an essential aspect of mastering the language.
#4: React Support
Mostly a tie.
ReScript provides first-class bindings to ReactJS, making it a little simpler to configure a working environment from scratch.
However, JavaScript boasts superior documentation for ReactJs and a much larger repository of examples available on the internet.
Apart from the notable observation that ReactJs in ReScript feels like a native part of the language, this aspect is not a significant factor.
#5: Refactoring
ReScript easily wins here.
Refactoring in JavaScript can be a tedious and error-prone task, often leading to unforeseen consequences.
In contrast, refactoring in ReScript is straightforward and simple. Being a statically typed language, it catches a variety of errors that could go unnoticed in JavaScript.
Refactoring in ReScript allows you to confidently rename, remove, or alter code with ease, even in complex scenarios. As a result, you can move swiftly, knowing that you haven’t introduced any errors into your code.
#6: Bugs
ReScript easily wins here.
Bugs are an inevitable part of writing code in any codebase. In fact, there’s a study that states there can be as many as 16 bugs per 1,000 lines of code in well-maintained and updated products.
I often find that bug reporting in a JavaScript console is imprecise and unsatisfactory. However, with ReScript’s compiler, very little slips through the cracks.
The static type system employed by ReScript allows for catching issues at compile time, leading to significant time savings. This results in fewer bugs and less time spent troubleshooting and tracking them down.
#7: Learning Curve
JavaScript easily wins here.
ReScript is a language that requires some self-guided exploration, as there are relatively limited resources available for learning. In addition, its stricter syntax may pose a challenge for beginners compared to the more forgiving and expressive nature of JavaScript.
However, if you come from a JavaScript background, much of ReScript’s syntax should be familiar. It’s important to learn ReScript’s type system as it’s a really what sets it apart from JavaScript.
The interop system can be challenging at first but becomes clearer with practice. While the documentation on the ReScript website is well-written, it may not always provide in-depth explanations or concrete examples, making it challenging for learners to get started.
To improve the learning experience, it would be helpful to have a more comprehensive bootcamp-type course that walks beginners through building a simple ReScript App. An experienced JavaScript developer would likely need about two weeks of self-learning to start being productive with the language. This timeframe could be reduced to one week with an expert teacher or bootcamp course.
Of course, these numbers are estimates and depend greatly on the learner’s commitment, experience, and expertise.
#8: Community
JavaScript easily wins here.
JavaScript wins solely through its age, massive scale, and widespread adoption.
I wouldn’t be surprised if, for every developer who can write ReScript, there were one million who could write some amount of JavaScript.
That being said, the ReScript community is full of extremely helpful, knowledgeable, talented and experienced people who will go out of their way to help you if you get stuck.
Threads in the community forum can sometimes go sideways down esoteric functional rabbit holes, but, to be honest, this doesn’t bother me as much as it would bother other more pragmatic types.
You are likely to have more success learning this language if you have a more “can-do” attitude or independent streak.
#9: Jobs
JavaScript easily wins here.
Once again, this is primarily due to the widespread adoption of JavaScript by large and profitable companies. As of now, there are not a large amount of job opportunities available specifically for ReScript developers.
On the other hand, if you have strong skills in JavaScript, it’s relatively easy to find positions with great companies that offer six-figure salaries.
In Conclusion
Overall, in my experience of learning and using ReScript I found it to be a more efficient and stricter option with a steeper learning curve in comparison to JavaScript.
In an era where Frontends have become increasingly complex I think there is room for more industrial strength options like this.
Note: If you’d like to checkout the app I built with ReScript, it is an interval timer and you can download it from timerlabs.com