This should be possible with something like bsb-native (https://github.com/bsansouci/bsb-native)
I haven't tried this because I don't have a pure Reason project
A webserver in native OCaml that's going to beat Node.js (it seems popular cohttp server in OCaml was not cutting it).
edit: actually I became a downvoter just now.
"my language can beat up your language" is like "my dad can beat up your dad."
1) A native web server, or
Because Reason can compile to JS, you can use with Node just like any other compiles-to-JS language. The claim here (which I have no opinion on either way) is that using a particular native OCaml web server with ReasonML is faster than compiling ReasonML to JS and using it with Node.
Faster considering the resources used (mem/cpu). Yups. Exactly that was my claim. Cohttp cannot beat Node, while a natively compiled OCaml server should be able to beat node.
Why not just use the real OCaml/Reason compiler ... ?
I use a `patch.sh` as the ENTRYPOINT, which says something like
echo $API_URL >> /usr/local/nginx/html/config.js
echo $OTHER_CONFIG > /usr/local/nginx/html/config.js
But to be honest, it's not very useful to do checklist-style comparisons — writing OCaml/Reason code is a completely different experience.
For me it results in less worry about how my code would sustain under refactorings — this is one of the reasons I feel more productive with it rather than with TypeScript or Flow or (of course!) plain JS. I can start writing code and don't worry about getting everything right upfront — refactorings are cheap.
In a large application you will need a lot of features, which are provided by default in ReasonML: strict types, runtime validation if you encode/decode JSON, fast compilation time, immutable data.
In TypeScript you will have to add:
1. ImmutableJS + its typings.
2. Runtime validators like json-schema + its typings. Then you will have to write types in TypeScript, and also defined a schema in json-schemas. They can become out of sync very soon.
3. Some crazy hacks to tell the difference if variable is of specific type (like in official docs of TS: https://www.typescriptlang.org/docs/handbook/advanced-types...., Paragraph "User-Defined Type Guards"). This checks are done using side effects like a.swim !== undefined. In 6 months this 'if' statement will contain more and more checks.
4. You are lucky if a package you use has official and maintained type definitions. Or you will end up with custom typings.
5. If you develop hybrid app in JS + TS, then TS Compiler cannot create a bundled final d.ts file which you can import in other parts of your project. You will have to write separate d.ts files, which are bundled by tools like dts-bundle. If you have everything in TS, then this issue is not applicable.
6. Large apps take a lot of time to be compiled by TypeScript.
1. Immutable data is in the language.
2. Runtime validators are present (bs-json has them by default).
3. Pattern matching saves you from these crazy checks.
4. You are lucky if npm package you want to use has BuckleScript bindings.
6. ReasonML compilation is very fast.
One can get some of the same benefits of sum types in TypeScript using discriminated unions - but the syntax is cumbersome and requires boilerplate as compared to Reason.
It promises zero compatibility code wise, but very easy interop (FFI) with JS land!
Typescript values can be null. A pure reason program will never have null bugs.
This is also a bit of a pain point on Android with Java @NonNull annotations or when using Kotlin.
I do quite a bit of TypeScript for the server though(less context switching and is mostly GoodEnough™) so still handy.