Careswitch embraces ReScript

Careswitch embraces ReScript

We're really excited to announce that Careswitch is embracing the ReScript programming language and community to build out its next generation platform of home care products and applications. If working with a new programming language and paradigm to improve the lives of family members and caregivers sounds interesting to you, we are hiring.

One of the most difficult decisions to make as an early-stage startup is committing to a particular tech stack and ecosystem to build products that will last longer than you anticipate—the fear of lock-in is palpable, not to mention all the risks associated with stepping outside the comfort zone of mainstream development. Erik Meijer visualized this well by describing two extremes of programming languages: those that are unsafe and pragmatic and make companies lots of money and those that are luxurious and pure and find themselves often relegated to ivory tower, academic circles. If a language like JavaScript is at the pragmatic end of the spectrum, then a language like PureScript is often on the other end. Of course there are many alternatives along this spectrum (including TypeScript), and we believe ReScript is making some of the most attractive tradeoffs between embracing the existing JavaScript ecosystem and not shying away from functional programming and strong typing.

As a company that has previously embraced TypeScript React across web and native development, we felt it was important to clearly understand the differences and tradeoffs between TypeScript and ReScript. Going into the evaluation we had convictions around a couple of items:

  • Long-term maintainability was at least just as important as short-term productivity and velocity—we couldn’t easily justify another major refactor or rewrite: the only way to go fast, is to go well.
  • We wanted to continue to leverage React across web and native to tap into the rich ecosystem of libraries and tools, as well as conserve most of our runtime intuitions around component hierarchies, flow of state, and the React rendering model in general. (You can make an argument that React is based on other, possibly superior architectures. Ultimately, we decided that the greatest improvements we could make were to the static build-time aspect of development, not so much the runtime).

At the end of our evaluation, we ended up making the decision to go with ReScript based on 2 main reasons:

  • By being explicitly designed as a superset of JavaScript, TypeScript will always find itself beholden to the idiosyncrasies, nuances, and constraints of the underlying JavaScript language. It’s a valiant effort that will continue to improve, be a good fit for many codebases, and provide just the right amount of guardrails those teams require, but at the end of the day you’re still writing JavaScript with type annotations and all the gotchas that come with it. Take a peek through the looking glass at a TypeScript declarations file (`.d.ts`) for your favorite libraries. The common argument that functional programming syntax is strictly harder to understand may lose some of its weight.
  • At the end of the day, ReScript compiles to human-readable JavaScript. When the code runs in the browser, it may be hard to tell that ReScript was used at all. Using a language that has first-class support for React while providing much stronger guarantees during build-time around types and the flow of your state with fantastic ergonomics like exhaustive pattern matching and first-class algebraic data types like records and variants was, for us, worth the tradeoff of the functional programming learning curve and having to put in the additional upfront cost of writing bindings for our favorite JS libraries.

We will dedicate another blog post in the future that will dive into the details of ReScript and how we’re adopting it at Careswitch to build and ship products. We will also discuss our plans to contribute back to the community, starting off with maintaining and publishing bindings that will allow other ReScript engineers to interop with existing JS libraries we use such as Headless UI, Luxon, and Next.js. We’re thrilled to be joining a fantastic community of companies and engineers working to build functional yet pragmatic applications that dare to have your cake and eat it too.