
25 Days of ReasonML - based2
https://medium.com/@lilactown/25-days-of-reasonml-a4b20a7e8c6
======
simplify
I've been learning ReasonML for React Native these past few weeks. I love the
static typing. I can work on my editor for minutes at a time, and when things
compile I see it "just work" on my phone. This is important since reloading a
native app is not nearly as fast as reloading a web page.

The best part is how FAST the compiler is! It blows me away how fast the
reason/ocaml compiler is, considering it spits out JavaScript AND type checks
at the same time. Babel, TypeScript, Flow, etc. are all slow as dogs by
comparison :)

~~~
girvo
How are you handling navigation?

~~~
simplify
I haven't gotten that far yet, but I'm planning to use their minimal built-in
one: [https://reasonml.github.io/reason-
react/docs/en/router.html](https://reasonml.github.io/reason-
react/docs/en/router.html)

~~~
thangngoc89
ReasonReact currently only handle browser routing (it hooks directly into
window.location API. So for ReactNative, it could do it the way you used to do
with Javascript.

------
Rapzid
I find ReasonML a VERY HARD sell when F# is sitting there waiting. If I could
get people onboard with an ML, why wouldn't I use F# with it's massive backing
ecosystem and fantastic server side runtime(node has come a long way, but it's
no CLR)?

~~~
chickenfries
I tried getting into F# and for someone not running on Windows without
knowledge of the CLR and .NET ecosystem its a hard sell.

~~~
Rapzid
Was this recently? Things change really fast, within the last year or so we
got ionide and core clr support. I've read of people preferring the experience
of F# in VSCode these days.

Just a few weeks ago I got an F# project with TensorFlowSharp up and running
on OSX in VSCode with the ionide extension. It JustWorked™.

In any case, I'd suggest you give it a crack again if you are interested. The
experience has improved greatly and the tooling seems pretty great now on
Linux/OSX. I've been following it for 3-4 years though, so I certainly
understand how it would seem like a non-starter in the recent past.

------
vemv
I'm interested in Reason/Buckle, coming myself from the ClojureScript.

The seemingly tinier minified compilation size would be a huge plus. But what
are the actual sizes emitted for large scale projects (arguably the ones that
matter most for static typing)? Anyone could share real-world experiences?

For reference: I know of cases where 60K lines of clojurescript (arguably
equivalent to 150K lines JS) compile down to 5MB under advanced optimization
mode.

(in case that scares you: well it's an actually large app. We should do route-
based code splitting soon - easy/robust with clojurescript apparently)

~~~
yawaramin
That's a very interesting question. We could ask some Messenger and Instagram
people, since they are heavily using BuckleScript. In general output JS is
already fairly spartan, because BuckleScript uses a few tricks here and there,
like encoding modules and records as arrays instead of objects; and completely
inlining functions whenever it can.

BuckleScript also emits ES6 modules, with imports and exports, and it marks
its output as either pure or impure at the module level. So potentially
there's a lot of room for bundlers to do tree-shaking.

Bob Zhang, the BuckleScript team lead, is working on a new typesafe standard
library for BuckleScript, which takes advantage of compile-time checks to
compile to extremely minimal and idiomatic JS. Exciting times up ahead!

~~~
Hurtak
I have heard about the Messenger where they have 25-50% of the web client
codebase in Reason, but I have not heard about the Instagram story. Can you
share more info or some links about that?

~~~
yawaramin
Hi, about Instagram, I was mistaken about 'heavy' use. As far as I know there
is one guy using Reason in Insta and from what he's said, he's found it pretty
straightforward. I don't have a direct link, but if you search for 'instagram'
in the ReasonML Discord chat you will find the discussion.

------
sfilargi
A weak point of ReasonML for me, last time I tried it, were the Promises; you
have to remember to resolve them, with the compiler not providing any help.
It's very easy to miss/forget to resolve them.

While it is definitely improvement over JS, it's a step back from the sense of
safety you get with TS.

~~~
yawaramin
I would say it's the other way round. In ReasonML, if you forget to resolve a
promise, the compiler tells you the types don't match up. This is better and
more reliable than the best linting rules you can get today for JavaScript.

With TS, to be honest I'm not sure how safe it can be since it must play nice
with the JavaScript rules that promises can be automagically resolved.

------
petetnt
Nice article! I was also doing Advent Of Code[0] with ReasonML but sadly due
to time constraints I didn't get any far. Still learned a lot about ReasonML,
even if the solutions weren't really idiosyncratic! Definitely going to dive
into ReasonML later again.

[0] [https://github.com/petetnt/advent-of-
code-2017-reasonml](https://github.com/petetnt/advent-of-code-2017-reasonml)

------
sp33der89
How does ReasonML/Bucklescript stack up against F#/Fable. Is the only
difference that F# has the .NET environment?

~~~
yawaramin
Good question. I would say the differences are:

\- BuckleScript targets ES5 (+ES6 modules) directly, while Fable targets
ES2015 (and beyond) and relies on Babel to transpile its result to ES5

\- BuckleScript/ReasonML needs only NodeJS/npm to work for JavaScript compiles
(but you can get the opam compiler/package manager if you want to do native
development)

\- BuckleScript/ReasonML has a more powerful traditional OCaml type system
with higher-level abstraction features like functors and generalised algebraic
data types, while Fable relies more on OOP for abstraction

\- At the moment at least, BuckleScript's JS output is far more minimal than
Fable's–try defining a simple record type like `type person = {id: int}` in
both their online playgrounds to see the difference–it's pretty striking

\- But Fable does have an open GitHub issue talking about minimising their
output to be more BuckleScript-like, so it might catch up

\- BuckleScript's JavaScript interop is just as powerful if not more, but does
require a shift in thinking because its premise is to convert JavaScript
idioms into OCaml idioms

~~~
sp33der89
Thanks for this, great explanation(and as a F# looks fair). I'll try out
ReasonML one of these weekends, thank you.

------
joobus
I like the idea of Reason, but I currently do much more server coding than
front end. The native compiler is currently classified as work-in-progress
([https://reasonml.github.io/docs/en/native.html](https://reasonml.github.io/docs/en/native.html)).
I also wonder about how the community evolves if javascript-targeted reason
libraries aren't compatible with native reason libraries. For instance, would
a wrapper for a js promise library be able to work in server code? I'm
interested in the language, but currently not investing time in it.

~~~
hurricaneSlider
It's fully compatible with nodejs, so super feasible to do backend dev

~~~
santoriv
Has anyone actually done this in a real app? The last time I looked for nodejs
examples, I could only find small POCs. The vast majority of ReasonML material
seems focused on the front-end.

~~~
lilactown
I ran all of my Advent of Code[0] solutions in Node.js - there's nothing
specific really about running a ReasonML app in Node.js vs the browser. Except
you don't need a module bundler for the former. :)

I've also been slowly working on a small CLI app using ReasonML, ReasonReact
and react-blessed.

There definitely is a dearth of ReasonML server-side examples, libraries and
frameworks, though - especially compared to all the front-end chatter. bs-
express[1] is actually quite nice, but hasn't seen much attention from the
larger community. I would highly recommend it if it's something you're
interested in pursuing.

[0]:
[https://github.com/Lokeh/advent-2017](https://github.com/Lokeh/advent-2017)

[1]: [https://github.com/reasonml-community/bs-
express](https://github.com/reasonml-community/bs-express)

------
bajablast
Whoa, I was just looking at some examples of this library and it seriously
looks just like JS, only give away is the patten matching(which is a feature I
wish JS had)

