When I suggested using ReScript for a new project, rather than the current TypeScript/React stack, I was asked to write my reasoning for why I think ReScript would be a better fit for us, I thought it would be a good idea to write the reasons here (no pun intended).
It’s easy to migrate to and from:
ReScript compiles down to readable JavaScript, and it has an option to export its type to the Typescript world using genType, and this feature it’s very easy and convenient to integrate to a normal TypeScript codebase this way.
Compared to other functional language it generates tiny output, as an example a simple Hello world in elm produces a 92K index.html file, of which the HTML is not the problem.
In comparison ReScript produces just console.log(“Hello, world”);
(plus a bunch of comments).
In general, ReScript produces quite readable JavaScript.
It’s also quite fast compared to the other languages, notice the difference with PureScript (a Haskell dialect) in both code generation and speed.
It comes with batteries attached, with the very good Belt and a core library that in the next major version will be part of the language.
It has zero cost abstractions in the form of types: all types are stripped out of the final output but used during development to allow us to make the code safer.
It’s still potentially possible to share code with Native OCaml, allowing executing tests with Rely, a Jest inspired native test runner which is extremely fast compared to any JS test runners.
Talking about OCaml, as I previously said somewhere else Reason is OCaml. ReScript was Reason, so it retains the robust Hindley-Milner type inference that powers languages such OCaml and Haskell, but what does this means to us is that you’d rarely need to type your parameters or return types and your code will still be strongly typed.
ReScript comes with JSX as a part of the language, and works well with React
The syntax is similar to JavaScript with some OCaml influences, but nothing too difficult to learn.
The language is immutable by default, no need to use immutable libraries (although I don’t dislike immer) in my JavaScript.
Compilation time is fast, it’s build with performance in mind, and seems consistent in large codebase where a cold build could take around 10s for 40k lines, and almost instant in watch mode.
It’s very easy to integrate existing JS/TS libraries.
In summary, I think ReScript stays out of the way of the developer while still doing its job of being a safeguard thanks to its strong type system, its superpower is type inference, which means no more has implicit type any
messages in loops, forcing you to type a function parameter used in a single place.
Cons to adopt ReScript are that the language is being developed by a small team and there’s not much adoption yet, plus a need to learn a new language, and the cost to update to future versions is unknown.
I think those are a reasonable challenge for some team, but I think in my case it’s not a big of a deal;
as I mentioned previously, ReScript is easy to migrate from, so worst-case scenario we’ll have an exit route.
I used to be quite contrary to use a different language that compiles to JavaScript for a reason or another in the past, but we live in a world where compilation steps are mandatory and as crazy as it sounds it can take many minutes to build a client application.
I come from a time where building an egregious UI application would take seconds as we would just append different files together and pipe them to a linter/minifier, now it’s super easy to produce huge bundle where 90% of the code is not even running.
Oppose this to something like ReScript that produce small code by default, cuts out what’s unused and makes tree-shakable libraries and then it’s easy to see results like this.
I’m not as opposed to different languages as I used to be, after all we extended JavaScript to support types and to add a lot more features to the language, with the availability of a vast user library now we now need those tools.
But first and foremost is the User Experience, I think ReScript improves the developer experience without negatively affecting users.