Feedback on ReScript

rescriptMarch 27, 2024Dotby Alex Fedoseev

A few months ago, I asked fellow devs to give honest feedback on their experience with ReScript, and this is what I got in replies.



  • Great type-safe language.
  • Very easy to navigate through the code.
  • Speedy compile time.
  • Easier to debug than JS.


  • Difficult to learn, and takes some time to get acquainted if someone doesn't have previous experience with the strong type system.
  • Lack of online resources. Because of it not beginner friendly.



  • Type-safe.
  • Nominal Typing.
  • Pipes.


  • No async/await, so you still have to write promises.
  • Bad DX, difficult to learn.
  • Small community & very few resources.
  • Having to bind any external library is PAIN and a waste of time 🤯
  • Weird errors would happen due to compiler (just like google-maps bug with undefined).

Comparison to TS: I think TS is way better. Using TS, you are still writing JS syntax. But in ReScript you write different syntax.

Comment from Alex:

By Weird errors would happen due to compiler, Ahmed meant the issue when the React Google Maps library was checking for the presence of an object key regardless of its value. So, even if the value was either null or undefined, it was still considered truthy by the library. I am biased, but I believe that the issue here is not with ReScript.


I miss ReScript so much 🥲

+1 to Ershadul, and additionally, I would add that ReScript forces you to use different programming patterns. Way more safe and way more clear ones. And that's the main problem for beginners imo, very different approach.



  • My positive points are basically Ershadul’s points.
  • The language reduces the amount of possible errors you might add (compared to plain JS).


  • The initial learning. It was very steep way back in ReasonML. I think that’s when I started losing hair. I’m not sure how newcomers are seeing the language today.

What I like about it:

  • The pattern matching was a game-changer for me.



  • Type-safe language - I came from JS and will never return to weakly typed language again.
  • Easy to refactor (compiler finds all usages and doesn't allow to run bad code).
  • No surprises on launching the project. If code compiles, there’s a high chance it works as expected.


  • High entry barrier (It drove me crazy when I was studying, and I still don't understand a lot so far).
  • Week documentation.
  • Misleading error description and error linting sometimes Errors (need to clear cache sometimes).

I love Variants in Rescript!


I haven't touched ReScript in a while, but I agree with Ershadul's points. What I liked the most about it was variants, as they make the code much clearer. And my biggest problem with it was the documentation (or lack thereof).


Mostly agree with Ivetta. Not sure about misleading error messages, though. I like them so far. And I never had to clear the cache.


Mostly I agree with Ivetta except the error messages point:

  • The pattern matching changed my mindset to the better.
  • Binding is a disaster 😥
  • ChatGPT3 is very confused about it and ReasonML. However, ChatGPT4 is much better.

As new one for Rescript (and front-end in general), it was really hard to learn it. The docs was good but for specific problems searching the internet or asking AI couldn’t help that much. I think that I would be much more productive if I used TS but it’s a subjective opinion.

One of our clients who adopted ReScript in their codebase - Mike Price from - was so nice to provide his extended feedback on the language as well.

Mike Price,

Best Feature: Type Safety

While our software team may be modest in size, the complexity and maintenance demands of our growing codebase are anything but. ReScript's type safety plays a pivotal role in our development process. It ensures that updates to core functions or modules are seamlessly integrated throughout our application, with the ReScript compiler identifying any discrepancies before they escalate into production issues. This efficiency in bug detection allows us to dedicate more resources to developing exciting new features for our users. Additionally, ReScript enhances our accountability regarding the data transferred from Rails to the front end, bolstering the reliability of our data and providing a dependable user experience.

Worst Feature: Writing JS Bindings

Writing ReScript bindings to JavaScript libraries can be a cumbersome process, primarily due to the inherent differences between the two languages and their respective ecosystems. ReScript, with its strong type system, stands in contrast to JavaScript's dynamic typing. This disparity means that developers must invest significant effort to accurately type JavaScript libraries in ReScript. Creating these bindings involves detailed understanding of the library's API and its usage patterns, often requiring meticulous work to ensure type safety. Given that the ReScript open-source community is small relative to the TypeScript or JavaScript communities, it can be difficult to find pre-existing libraries. Writing bindings can be fun, but it takes time away for the core objective of the project.

Several years ago, embraced ReScript, a decision that has proven to be immensely beneficial. This shift was largely influenced by Justin from ShakaCode, who presented a compelling case for the efficacy of ReScript. Coming from a background in Ruby and Rails, I initially relied on Shakacode's expertise, but as I delved into ReScript, my appreciation for its capabilities grew significantly. Now, I find myself more adept with ReScript React than with traditional React, largely due to its enhanced readability and dependability. One of the notable advantages of ReScript is its type safety system, which significantly reduces the risks associated with upgrading to newer versions, thereby streamlining the update process. This feature is particularly advantageous for projects that combine React with Rails. Integrating ReScript into such projects is straightforward, as it can operate alongside existing libraries without any issues. Furthermore, the transition from JSX to ReScript can be managed gradually, prioritizing files as needed. This flexible approach facilitates a smoother integration of ReScript into existing workflows, enhancing overall development efficiency and happiness.


And a little addition from me. I've been using ReasonML/ReScript as my primary tool for writing web front-ends since 2017. The language has come a long long way since then. It became much more friendly to JS developers without losing its strengths. The documentation became much better. Writing bindings to too JavaScript’y APIs still sucks. But in my opinion, ReScript is the best tool to date for writing React front-ends if you aim for reliable and maintainable applications.

Does it align with your experience?

Closing Remark

Could your team use some help with topics like this and others covered by ShakaCode's blog and open source? We specialize in optimizing Rails applications, especially those with advanced JavaScript frontends, like React. We can also help you optimize your CI processes with lower costs and faster, more reliable tests. Scraping web data and lowering infrastructure costs are two other areas of specialization. Feel free to reach out to ShakaCode's CEO, Justin Gordon, at [email protected] or schedule an appointment to discuss how ShakaCode can help your project!
Are you looking for a software development partner who can
develop modern, high-performance web apps and sites?
See what we've doneArrow right