ReScript 11 can seriously eat TypeScript's lunch

I am a TypeScript developer by day. My work consist of 80% frontend, 20% backend. I work in a private trading firm. We (believe it or not) use TypeScript for our GUI (and not C++), and yes JavaScript frontend is fast enough for our use case. We use a multi language monorepo, and are heavily invested in React and the TypeScript ecosystem. I migrated my company’s TypeScript code to use Bazel, bespoke builds using various stuffs of CRA, esbuild, swc, etc.

I know the JS ecosystem and the pain around it. My day to day work consists of developing features, writing new build rules, fixing broken/buggy builds. Anything related to JS/TS tooling, I’m the guy. No one else wants to do this.

I am aware of stuffs like:

  • Tooling incompatibility hell
  • Configuration hell
  • JS fatigue
  • Slowness of TypeScript compiler
  • Runtime errors (because TypeScript is not sound enough)

Anyway, that’s my background.

I was always intrigued by ReScript, and have known ReScript since about 2 years ago (started from knowing the buzz around ReasonML). Although I wanted to try it, at that time the ecosystem and the developer experience wasn’t too great for me. The fact that I have to know the whole OCaml ecosystem and the convention around it didn’t help me at all to consider ReasonML/ReScript at that time. So I left and looked on the sideline.

This year, I am revisiting ReScript and I’ve to say, I am very surprised, delightfully surprised. I think the decision from the ReScript team to move away from the OCaml ecosystem hits the nail on the head. Bullseye. I know this was a constant source of hot debate in this forum, but I’m glad that the ReScript team decided on this favor. I’m a happy customer.

Things that I really really like in ReScript today:

  • Easy JavaScript interop. With ReScript 11 around the corner, it is even better. Writing your own binding can’t get any easier than this.
  • Compile to readable JS. I like uncurried by default.
  • The decision to use data first approach, thus making it closer to JS
  • Very fast compiler. Also another bullseye from ReScript team to take performance seriously

I really think with ReScript 11, the momentum for ReScript to finally be another contender worthy to challenge TypeScript is there. I am not considering PureScript, Elm, CoffeScript, Kotlin, Js_of_ocaml and other compile to JS languages. ReScript beats all of those compile to JS languages by a mile. ReScript 11 is very, delightfully usable today. It is already 99% feature complete (at least from me coming from TypeScript). I really like the ReScript today I decided to make some content on YouTube about ReScript!

Therefore I think it is not far fetched to say, that in terms of development effort, I think it is a great strategy to focus around the tooling. Make the developer experience to be really polished, and ReScript seriously can eat TypeScript’s lunch.

Take for example, source maps. I know we can just read our generated JS, but that’s another friction in our development experience. For example, I can write bindings for Jest, but when the test fails, I still need to read my generated JS to know where it is failing. I don’t want to keep reading my generated JS code (on top of also reading resi files as well). I want to read and think in ReScript.

As far as I know, today the compiler API is still not open, we as end user can’t access ReScript’s AST. Please correct me if I am wrong.

But I think once we can access the compiler API easily, the tooling around ReScript could experience some type of Cambrian explosion. From documentation, to linting, to bundling, etc.

I am aware that there are improvements on ReScript formatter and also happy that there is a new build system for monorepo called rewatch.

One thing that I’m on the fence is regarding having official standard bindings in the JS ecosystem, like for Dom/Web API, and for NodeJS API, pretty much just like official standard binding that we have for React. It’s not a deal breaker though, since I think everyone should learn how to write their own bindings anyway, but I thought it is one of the friction in terms of development experience for me.

I don’t feel the need for AI or any other fancy tooling, just the most standard, boring ones are good enough for me. Make those BoringlyRockSolid™.

Sorry for the long post, just thought I want to share my 2cs.

22 Likes