I thought it might be helpful to chime in with my 2 cents, as a potential adopter, describing the value proposition of ReScript from the outside, with “fresh eyes”, before I also get the curse of knowledge. I have been thoroughly researching all the competing alternatives, and have recently been convinced about ReScript.
In general: A good way to come up with a slogan is to listen to how customers describe one’s product, and then feeding back their own words, to new customers. The actual reality of a product, and ones own informed perception of it, matters less than the benefits as perceived by potential adopters.
So here are my suggestions for slogans, summarizing the ReScript value proposition, as I see it:
#1 slogan alternative:
ReScript: Type safe JS without all the typing, plus FP without the OOP.
Taking into account that most of the audience will be coming from JavaScript/TypeScript.
#2 slogan alternative:
ReScript: Full FP & type safety for JS, without ‘any’ baggage.
See what I did there… 
an easter egg reference for the TS exposed. But more importantly: Baggage refers to OOP, having to write out all the types (cluttering the syntax, like in TS), slow tsc compiler, being a subset of JS etc.
#3 slogan alternative:
ReScript: Scalable JS, without ‘any’ baggage.
Similar to TS slogan, but TS cannot say it doesn’t have baggage (see my previous point).
In general, a good rule for a marketing slogan is: Say something your competitor couldn’t possibly say. Because generally, everyone tends to say the same things, making differentiation hard for the consumer. Case in point: The slogans referenced in the posts by @kevanstannard and @Hongbo .
#4 slogan alternative:
ReScript: Ease into FP and get null-safe JS.
Everyone must have encountered a null error, so it’s playing on that. Everyone wants to get into FP, but most people find it hard.
#5 slogan alternative:
ReScript: Awesome type inference and FP goodies for JS.
Communicating on the end-user benefits, sprinkled with some emotional appeal.
#6 slogan alternative:
ReScript: Null-safe, fully type inferred, FP, for JavaScript.
#7 slogan alternative:
ReScript: Scalable but convenient JavaScript.
Scalable sums up: Null-safety, FP, type safe, etc. Scalability is the reason people do FP, type safety etc. It also jives with the origins of Reason, being invented at Facebook for scaling React to large teams.
“But convenient” is a jab to the inconvenience of typing in TS. Scalability often comes at the expense of convenience (e.g. static vs. dynamic typing debate, enforcing a bunch of code conventions to avoid the “bad parts” of JS, etc.).
(BTW: the main JS example on the front page doesn’t do ReScript justice. I also fell off quite quickly during the feature videos.)
ReScript used to be marketed as a functional language, or JS with types. This is nice, but there are some problems with such marketing
Functional programming is not a turnoff, it is quite the rage these days! All languages are aspiring to be more functionally oriented, and it is something a lot of people are talking about and would like to get more into. ReScript looks to me like the gateway drug.
The major selling points of ReScript to me:
-
Type inference: I’d get full and sound type inference, without annoyingly having to write out all types. (Since I’m coming from dynamic languages like JS and Ruby, this is a big win compared to TS)
-
FP: I could commit to FP without a bunch of libraries like I would have to in JS/TS: ts-belt, ts-pattern, etc. Immutable data structures and Result types are baked in. I also love data-first.
-
JS interop: I could still use JS ecosystem.
-
Eject / No lock-in: If I change my mind later on, then it looks like I wouldn’t be locked in, and could eject to TS if need be, due to genType. Whereas going from TS to ReScript would be more painful.
-
Constraints, easing into FP: I would be guided by the FP constraints of the language, and new developers on the project would also be nudged in the right direction, and, moreso than in JS/TS, prevented from introducing antipatterns (OOP, ‘any’ types, ‘ts-ignore’, mutable data structures everywhere etc.).
The actual current ReScript slogan:
ReScript: Fast, Simple, Fully Typed JavaScript from the Future
But it uses these advertised selling points, which to me are in fact not initially selling points of ReScript (although they are true):
-
Fast. It looks like with Vite (with HMR & esbuild) then development iteration cycle would be fast enough with JS/TS. People even rush to NextJS (which uses Webpack), because problems with compilation speed are not felt until wayy later in a project. So a fast compiler is not people’s primary concern, given the state of the market. Unless they are coming from very large TS codebases that have experienced that problem. But the long tail of people arguably aren’t.
-
Simple: Really, at first sight ReScript doesn’t look that simple: new syntax, new toolchain, bindings to JS… JS would be the simplest. In fact, have strongly considered just using plain JS with types in JSDoc (verified by TS compiler in strict mode), and just suffer having some bugs not caught by TS. To avoid the toolchain hassle (and syntax imposition of types). Preact went this route.
-
Typed: Coming from a dynamic language (JS / Ruby), I initially view typing as a burden, not as a benefit (“now I need to add types everywhere!”). Types are a cost I have to pay to get the benefit, which is: Safety which in practise translates to Less time chasing silly bugs. The major and exceptional benefit of ReScript is I could in fact get this benefit without having to add types everywhere.
Largest concerns about ReScript, to me:
-
Bindings: Having to write bindings for all the JS/TS libraries I plan to use. It’s confusing that @ryyppy says that “No, a monorepo like definitelyTyped doesn’t work with ReScript. … it’s hard (or even impossible) to generalize bindings that work for everyone”, but at the same time seeing binding libraries such as rescript-react, rescript-react-native, rescript-material-ui, rescript-relay, and rescript-urql. Do they do the impossible? What is the approach I’m supposed to take here? I’d love to not have to write extensive bindings for all the libraries I would use. It is almost a non-starter. For some I’m sure it will be a non-starter for adopting ReScript.
-
Eject / No lock-in? A video guide showing how simple & fast it would be to migrate the rescript-react-realworld-example-app from ReScript to TypeScript would ease my concerns. If ejection is demonstrated to be really as simple as it is portrayed, then there is no cost to adoption.
-
Multi-threading: Should I just use Golang on the backend, sooner rather than later? Though I don’t like its imperativeness, it is typed, seems easy to learn, has awesome profiling tools, and has goroutines which is the optimal way of dealing with concurrency. Which is important for squeezing out performance and budget from serverless cloud containers like Google Cloud Run, as opposed to Node. For one or two reasons.
Minor (mostly aesthetical) concerns to adoption:
- I really, really, don’t like decorators. I stay away from everything Angular (or angular inspired, like NestJS) just because of it. Call me silly, but I feel that decorators are “magic” that make the runtime control-flow unobvious. I don’t like macro-expansions (I don’t want to talk/instruct the compiler. I want the compiler to understand how I write my program. Even if that limits the ways in which I can write my program. Rather than allowing a wide range of styles, and then having to decorate certain styles ad-hoc, to disambiguate them). I don’t like the aesthetics of decorators either.
- I don’t like the ~ operator. It makes long lists of variable names harder to visually scan. I would have preferred _ or something similar, or even putting the ~ after the variable name, so the starting characters of names become immediately clear and discernable, instead of unhelpfully uniform.
But I would be willing to swallow these aesthetical preferences (although initially off-putting), for the other benefits ReScript provides.
Hiring could also be a concern. But being niche could also be an advantage/attraction. Not a biggie, as long as JS/TS devs can come up to speed quickly, and use the libraries they’re used to.
All in all, ReScript looks like a great projects and useful tool. I hope my suggestions and criticism is taken in the best spirit: I would like ReScript to succeed. I also hope it gives some insight into the mind of a potential adopter, just as he is on the threshold of converting.
