I think not. Because JS has a lot of areas of application already. NodeJS, React Native, Vanilla and etc. JS is really flexible. ReScript has good chance to support it with strong types and fp features.
ReScript: Come back to using promises.
5 Likes
For reference, Elm’s slogan is this:
A delightful language for reliable web applications.
Talks about developer experience, the safety, and the main target in a succinct way.
Here is Elixir:
Elixir is a dynamic, functional language for building scalable and maintainable applications.
A bit more explicit in terms of technology, but mentioning the desirable traits of the applications.
Here is Gleam (which targets JS too with its latest release):
Gleam is a fast, friendly, and functional language for building type-safe, scalable systems!
And here is Typescript:
Typed JavaScript at Any Scale.
Lots of scalability words and other buzzy words thrown around. Personally, I think Typescript’s and Elm’s are the best slogans, with the least tech buzzwords on it, catchy and to the point.
Cramming everything in a slogan isn’t necessary, that’s why the rest of the main page has other headings and info. It should catch the attention of the reader to read more basically.
My 2 cents, I think yawaramin’s suggestion is good,
To provide another option, maybe we can swap some words around:
A solid and performant language for JavaScript applications
Reliable ~= Solid ~= Dependable ~= Trustworthy, etc. This speaks to the type system given reliability.
Performant speaks to how fast your code will run. No confusion with fast compiler, which is awesome but maybe not worth putting in the slogan. The optimizations rescript does to the output JS are very cool.
And what people write is applications, either in the client, server, or else, to me it sounds better than platforms.
In the end this is a subject prone to tremendous bikeshedding so make a call and run it through native speakers and move on 
As long as it isn’t something like “Cybernetically enhanced web apps”* it will be alright 
4 Likes
I took a leaf out of Elm’s book can came up with this:
ReScript: Reliable JavaScript applications made fast and easy.
I think it signals that, ReScript can help you build applications from data models
- fast (since you can refactor and iterate fast without worrying, with a speedy build system) and
- easily (because the language syntax looks simple and is similar to JS; helpful APIs are batteries included as well).
Also the term “JavaScript applications” takes it beyond the React audience.
Avoiding the term “language” would help market it to people other than developers.
What do you think?
2 Likes
lighting fast builds of virtually exception free React applications
no exceptions, no waiting, just build
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.
7 Likes
without \any\ baggage lol
I have to say that was number one for me.
I had to pick rescript so my team would not fall into any-thing.
Having done this I can barely imagine getting a team of varied skills to manage the EXTRA complexity of Typescript typing.
A
1 Like
Rescript is essentially what I imagine JS from the future would look like. The source code is not riddled with type declarations everywhere, option, result.t is just awesome, combined with pattern matching it is just the best thing when dealing with complex data structures. I can’t express how pleasant it is to use. I think it should be reflected in the slogan, so @yawaramin’s will get my vote:
Simple, fast, type-safe language for JavaScript platforms
I also can suggest something like
Rescript: Create complex type-safe JS apps with zero mental overhead
Re: My multi-threading concern.
Seems like Ocaml just got multicore support
Plus there is a library domainslib that utilizes “parallel programming over multicore Ocaml”. It seems to have Channels, like in Golang, so it looks pretty promising! Anyone know if OCaml features like this are downstreamed into ReScript?
I think there’s been a misunderstanding here. Multicore/multithreading are irrelevant for ReScript. ReScript compiles to JS and targets only JS. All JS target platforms as of today, are single-threaded, with no multi-threading capability on the horizon (that I know of).
1 Like
@yawaramin Do you think the rescript compiler will benefit if it starts to use the multicore Ocaml? To remain competitive with swc’s type checking (that was discussed in the other rescript thread) that’s in the works.
1 Like
That’s an interesting question, I think it remains to be seen how parallelizable the compiler itself is.
One approach would be to wait and see if and how the upstream OCaml compiler itself takes advantage of multicore, and then try to rebase ReScript on top of the upstream. Or alternatively, to cherry-pick and apply or implement similar optimizations in ReScript.
However from what I can tell, the main approach to parallelizing the compiler workflow is in the build system, and that is already heavily optimized, e.g. by using Ninja to do the actual builds, and having a smart scheduler to optimize the separate compilation plan.
Hongbo has blogged about this before, unfortunately the posts are archived and difficult to find. This is the relevant one: https://github.com/rescript-association/rescript-lang.org/blob/master/_blogposts/archive/2019-01-11-scalable.mdx
EDIT: btw, comparing to swc’s typechecking that is ‘in the works’ is I think a red herring. Let’s see swc’s typechecking performance vs its correctness, under real-world conditions once it actually ships. Until then it’s premature to talk about swc.
5 Likes
oh yeah, of course, you’re right! I was assuming ReScript compiled to OCaml for a moment there 
But maybe the multicore support would come to ReasonML?
If so, then one could have ReScript on the front-end, and ReasonML on the back-end…! <3
If so, and if ReasonML’s concurrency story is as good as or better than Golang, then it would be a dream come true…!
Current:
My favorite suggested slogan:
It pretty much sums up the value proposition**, and evokes some feels and curiosity instead of trying to say it all at once.
** see justification under “#7 slogan alternative”, in my previous post.
1 Like
The nut graph below should also clearly differentiate it from TypeScript, since “but we could already use TS?” will be top-of-mind for most people coming to the page.
I don’t see a reason for the reasonml in this chain tho. Why not to use ocaml without additional abstraction in this case?
1 Like
I assume you mean in the full stack case I mentioned. True, preferring ReasonML over OCaml for the back-end would just be for syntax similarity to ReScript.
1 Like
I’m a complete newcomer, so may not have seen all nuances. I’m also only an amateur programmer.
I came to ReScript as a “competent” c++ programmer. I struggle to build large programs with javascript being “dynamic, weak, duck”. I tried flow for a while and I tried typescript for a while; neither really worked for me and I looked for alternatives. Scala.js and ReScript both seemed to be what I wanted. I’ve landed in the ReScript camp.
What ReScript has that Scala.js does not have might be a point to raise in a slogan.
A slogan for ReScript in my view needs to make it clear that it is (1) soundly-typed, (2) compiles fast, and (3) has minimal overhead (over JS).
The Js.Array2 vs Belt.Array discussion I have read about might have an impact on (3).
1 Like
That’s a good point. “Minimal overhead” is often mentioned by @ryyppy as well.
The slogan can summarise: “a fast toolchain”, “minimum overhead” and “safety”.
1 Like
ReScript–the better language Doug Crockford is looking for (see: Doug Crockford–The Better Parts) 
4 Likes