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:
- 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.