You are currently looking at the < v8.2.0 docs (Reason v3.6 syntax edition). You can find the latest manual page here.
(These docs cover all versions between v3 to v8 and are equivalent to the old BuckleScript docs before the rebrand)
ReScript looks like JS, acts like JS, and compiles to the highest quality of clean, readable and performant JS, directly runnable in browsers and Node.
Consequently, TypeScript's type system is necessarily complex, pitfalls-ridden, potentially requires tweaking, sometime slow, and requires quite a bit of noisy annotations that often feel like manual bookkeeping rather than clear documentation. In contrast, ReScript's type system:
Is deliberately curated to be a simple subset most folks will have an easier time to use.
Has no pitfalls, aka the type system is "sound" (the types will always be correct). E.g. If a type isn't marked as nullable, its value will never lie and let through some
undefinedvalue silently. ReScript code has no null/undefined errors.
Is the same for everyone. No knobs, no bikeshedding opportunity.
Doesn't need type annotations. Annotate as much or as little as you'd like. The types are inferred by the language (and, again, are guaranteed correct).
Migrating to TypeScript is done "breadth-first", whereas migrating to ReScript is done "depth-first". You can convert your codebase to TypeScript by "turning it on" for all files and annotate here and there; but how much type safety did you gain? How do you measure it? Type errors can still slip in and out of the converted pieces. For ReScript, our interop features draws clear boundaries: there's pure ReScript code, and there's JS interop code. Every piece of converted ReScript code is 100% clean. You'd convert file by file and each conversion increases your safety monotonically.
Aside from the aforementioned simple, robust and fast type system, ReScript presents a few more advantages.
Function and module level code elimination is facilitated by the well-engineered type system and purity analysis.
At the global level, ReScript generates code that are naturally friendly to dead code elimination done by bundling tools such as Rollup and Closure Compiler, after its own sophisticated elimination pass.
The same applies for ReScript's own tiny runtime (which is written in ReScript itself).
Hello world ReScript program generates 20 bytes JS code. Additionally, the standard library pieces you require in are only include when needed.
ReScript's build time is one or two orders of magnitude faster than alternatives. In its watcher mode, the build system usually finishes before you switch screen from the editor to the terminal tab (two digits of milliseconds). A fast iteration cycle reduces need of keeping one's mental state around longer; this in turns allows one to stay in the flow longer and more often.
Hard to debug (cryptic stack trace, mangled variable names)
Hard to learn from (non-straightforward mapping of concepts from one language to another)
Hard to profile for performance (unclear what runtime performance cost there is)
Hard to integrate with existing hand-written JS code
ReScript's JS output is very readable. This is especially important while learning, where users might want to understand how the code's compiled, and to audit for bugs.
We hope the above gave you enough of an idea of ReScript and its differentiators. Feel free to try it online to get a feel!