
ReasonML – React as first intended - spking
https://www.imaginarycloud.com/blog/reasonml-react-as-first-intended/amp/
======
amenod
Honest question: why would someone use this instead of React?

From my point of view, React solved a real problem. JS before React (at least
old-skool, with jQuery & co.) was simply unmaintainable. It was often easier
to thow old projects away and start anew than to maintain what inevitably
became a tangled mess of callbacks and global variables. Not because of
incompetency of developers (at least I hope so ;) but because there were no
standard of encapsulation, separation of concerns and similar.

Why would someone who knows React want to switch to ReasonML?

~~~
simplify
ReasonML has more potential. Aside from its excellent type system (one of the
best), it can also compile to native code. This has several benefits:

\- Frontend: Your tools are fast. The ReasonML-to-JS compiler is already an
order of magnitude faster that TypeScript, etc. Fastpack is a native bundler
in the works that aims to bundle your project in under a second (and faster
for incremental builds).

\- Mobile & Desktop: Some are experimenting right now with writing a version
of React in pure Reason that compiles to native code, bypassing the JavaScript
runtime entirely.

\- Backend: You'll be able to use the Node.js ecosystem but compile certain
modules to native code when you need critical performance.

 _Edit:_ I should add, the Node.js backend story is currently the least
developed part of the ecosystem (I'm personally working on getting that up to
speed).

~~~
christophilus
Yeah. The OCaml compiler is just crazy fast. It's like Go, but with a super
nice functional language. The compiler seems to be doing a heck of a lot of
heavy-lifting in such a small amount of time. I'd be interested in a talk
about how it manages that, if anyone knows of one.

~~~
Aeolus98
A lot of the tooling speed comes from a couple places:

1\. The compiler optimizations being applied to code \- Things like GADT's are
able to be allocated very efficiently \- Can generate code that doesn't box at
runtime (smash it into a pointer is done as well) \- Pointers are word-aligned

2\. The OCaml runtime \- No JIT \- No warmup \- Can emit native code

3\. The HM type system \- Typecheckers for HM are really simple [1]

[1]
[https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...](https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system#Algorithm_W)

This simplicity + the features of the compiler combine to make the OCaml
compiler very fast, and very easy to write one (some undergrad CS classes do),
and developer-time tenable to make both happen.

------
danpalmer
(Caveat, we're adopting Elm and so I'm a little biased)

I think this article's conclusion of Reason being the enterprise grade and
mainstream implementation of Elm, and Elm being a "prototype" is a little
unfair to Elm.

Elm has developed a mature ecosystem in many ways, in a relatively short space
of time, and two of the main reasons for that are the purity and the way the
JS interop works. It explicitly shields the Elm world from issues in JS. This
is one of the reasons we've decided to choose it. It is much more than a
prototype, this was something that factored into our decision making process
heavily.

I'm sure there are great things about Reason, but I can't help but feel that
the impact will be limited because it doesn't take a stronger viewpoint.

~~~
orbifold
Well Reason is really Ocaml, which has a much better type system than Elm
(functors, open variants, a class system) , powerful meta programming (the
react extension is just syntactic sugar around that) and is now backed by at
least three large corporations (Facebook, Bloomberg and JaneStreet). It has a
proven track record of handling large sophisticated projects and is not
restricted to the web front end niche because it compiles to native code
aswell. So you are able to write both the server and client code in the same
language. The fact that reason has a dsl for react is just one of the killer
arguments.

~~~
danpalmer
The type system might be more powerful, my point is more that if you can
bypass it and integrate directly with JS, then people will, and then much of
that value is lost. Elm doesn’t have that problem.

~~~
machiaweliczny
It lowers barrier to entry. You don't have - it's opt in. Not every project
needs 100% type safety.

I would also love option to have gradual type friendliness because when
prototyping I know my program is wrong in some different part, but I want to
test given component in runtime, while I haven't refactored everything yet. I
think having option like 'compileWithoutTypecheck' is very good for
prototyping.

~~~
danpalmer
You can use `Debug.crash` in Elm, or `error` or `undefined` in Haskell to
achieve this. They type check to anything, but will halt execution if reached.

------
davedx
I'm reminded of the Hacker News post that introduced me to React from David
Nolen back in 2013, where he first introduced ClojureScript's take on React,
Om:

[http://swannodette.github.io/2013/12/17/the-future-of-
javasc...](http://swannodette.github.io/2013/12/17/the-future-of-javascript-
mvcs)

Interested to take this for a spin.

~~~
grayrest
Om isn't so much a take on React as it is a take on the state management layer
and it uses React under the covers. I believe it's been largely superseded by
re-frame [1], which follows the Redux / TEA model. There is an Om Next and
that's basically a take on Falcor / Relay using the Datomic pull syntax but I
haven't heard that much about it outside the talks where he was announcing it.

[1] [https://github.com/Day8/re-frame/](https://github.com/Day8/re-frame/)

~~~
Scarbutt
Why doesn't Clojurescript eliminates the need for something like Redux where
Reason does? as mentioned in the article.

~~~
lilactown
IME using ClojureScript, you don't really need something like Redux/re-frame
all that often either.

Once you've handled local state and remote data dependencies, you have like
10% of your app state left. That can easily be solved with a global atom (a la
re-frame) or something like the new React context API.

Our understanding of how to handle state, remote data fetching, etc. has grown
a lot over the last few years. Both the React & ClojureScript ecosystem went
all-in on global state stores like Redux because, at the time, we thought we
needed it. It felt like, if we needed a global state store for one thing, that
it made more sense to just put everything in there for cohesiveness. It also
was hard to determine up-front what was needed globally (mostly data IME) and
what was only needed locally.

It turns out that local state and something like apollo/relay/"suspense" for
remote data solve the 80-90% case, and now we're getting better tools like
React context to handle the last 10%. I don't think that Redux/re-frame is
going away, but the number of apps that I would implement with them has gone
way down over the years.

------
nazka
I really want to use ReasonML in one of my next projects but I always come
back to two main questions.

How much is it easy to use JS components like the Calendar of Airbnb for
instance? And is it really easy to use BuckleScript? The "[%bs.raw ..." and
others look hard to read/use. Is it the case or just a feeling?

Is there someone who already tried it enough to know the answers?

~~~
qop
It's not any less convenient than React appears to be.

Disclaimer: I've only used it for small Todo project, I'm not a front end guy.

Disdisclaimer: I've not used React at all.

However, if you need really strong JS interop, consider something like F#'s
Fable. F# is gaining a lot of momentum and now that SAFE stack is apparently
Microsoft-blessed, I expect it to continue growing even more.

~~~
Rapzid
1k upvotes. I check in on Fable and F# semi frequently but SAFE has somehow
slipped under my radar. I wonder if the ionide project will get some extra
support..

Suave though... Nothing against Suave, but it's not the Phoenix competitor the
ecosystem is in dire need of. I was under the impression some newer frameworks
like Giraffe were going to fill that void..

~~~
qop
Are you aware of
[https://github.com/SaturnFramework/Saturn](https://github.com/SaturnFramework/Saturn)

?

It's what the S in safe is actually meant to be, not suave. It's very similar,
in heart anyways, to phoenix.

The fsharp community is fighting what is essentially an uphill battle. We have
ML but we've got to jump through dotnet hoops to get shit done.

One man's cruft is another man's feature.

I doubt ionide will support SAFE, but maybe they will have a sister plugin?
Idk how all that works.

~~~
Rapzid
So, I know this is a late reply to this but.. My reaction to the announcement
post was "YES!", but I see a few choices in current "Moons" that are part of
the same problem the project proposes to fix. Dapper is performant and good
for what it is, but entity framework is an amazing ORM IMHO. Simple.Migrations
does not have a CLI or support SQL generation?... These are too low level and
don't really provide that flash OOTB experience IMHO; same critique(valid)
made of Suave and Giraffe. To compete with rails and phoenix in velocity and
user experience those technologies are going to have to be swapped out with
more feature rich and ambitious libraries..

------
cies
You could even use ReasonML without React, and build complex web apps, by
going an even more Elm-like route with:

[https://github.com/OvermindDL1/bucklescript-
tea](https://github.com/OvermindDL1/bucklescript-tea)

Here some demo code (in ReasonML, not OCaml):

[https://github.com/feluxe/bs-tea-starter-
kit/blob/master/src...](https://github.com/feluxe/bs-tea-starter-
kit/blob/master/src/Demo.re)

------
kbenson
I think ReasonML would see _much_ faster adoption if they provided a stand-
alone binary, or at least a pre-installed environment, which could be
downloaded and installed as a whole.

ReasonML has a lot that makes it attractive to people that aren't already
entirely invested in the JS/Node ecosystem, but doing the whole dance to make
sure Node is installed correctly, and then using npm or yarn to install
bucklescript and all the dependencies and make sure paths are correct, etc is
a PITA, and a lot to ask of someone that's trying to evaluate whether it's
worth incorporating in a new/existing project.

Provide a precompiled download with Node, npm/yarn, etc, and all the modules
you need preinstalled, (just set the correct env vars to tell it to use it,
such at PATH and some lib path) and you drastically reduce the overhead to not
just trying it out, but actually using it.

~~~
pgt
As a masochist who has been willing to put up with the ecosystem pain of
Clojure & ClojureScript for the love of the language, I can corroborate that
it was a PITA to try ReasonML.

By the time I was done installing ReasonML to my machine, I was done trying
Reason - ML and OCaml seem great, but I have limited mental resources and they
are over-invested elsewhere.

This serves to inform future technology trials, because we don't assign enough
nearly credence to the cost of trialling new things when we are already
operating at our mental limits. By the time I am in a sufficiently quiet spot
to try your thing, I'm probably exhausted after a long day of work. So make it
as self-exemplary as possible. Steve Krug nailed it in "Don't Make Me Think."
([https://www.sensible.com/dmmt.html](https://www.sensible.com/dmmt.html))

I.e. What is the correct number of buttons to start/stop your microwave: one
or two? The answer is zero: your food should already be warm.

~~~
loginx
Pardon me if I'm being dense here, but can't you just try out reasonML with a
quick npm install from any platform? That's what they say in their "Quick
Start" docs here: [https://reasonml.github.io/docs/en/quickstart-
javascript.htm...](https://reasonml.github.io/docs/en/quickstart-
javascript.html)

~~~
kbenson
IIRC from when I looked into it and got it working a few months back, you npm
install bucklescript, wihch gives you a compiler to convert reason to JS, so
to do any testing that actually includes a real world equivalent experience
(such as include it in a sample webpage, maybe with React), you're talking
about using webpack or something to bundle all the dependencies and steps into
a deployment procedure.

Since it compiles to JS, and uses a JS lib and ecosystem to install the
utilities that do the cross-compile, it's sort of like if to try out Python
you had to first download and install a C compiler and C libraries used in
Python, and compile python from scratch, just to try it out, because no pre-
existing binaries, packages or installers existed. If that was the only way to
try out Python (or Ruby, or Perl, or anything), you would get a _lot_ less
people trying it out, and a lot less willing to go through all that in their
build chain (in case python updates, right?) if easier alternatives exist.

Just because your language compiles to another language, that doesn't mean to
you get to ignore the on-boarding experience to that extent. At least not if
you really want to succeed.

~~~
simplify
There's no ignoring going on. Reason exists on its own because it's not
opinionated on what sort of app you're trying to build – frontend, backend,
native, or some combination thereof.

If you're looking to build a web app with react (the subject of the article)
then you can whip one up using one of their generators
[https://reasonml.github.io/reason-
react/docs/en/installation...](https://reasonml.github.io/reason-
react/docs/en/installation.html)

~~~
kbenson
> There's no ignoring going on. Reason exists on its own because it's not
> opinionated on what sort of app you're trying to build

I think either I wasn't clear, or you completely misunderstood me. My point,
that Reason should have a standalone installer or package that gives you a
working Reason as simply as possible without a whole build infrastructure
required, is only bolstered by this statement.

I don't think it matters if it's the Reason-to-Ocaml targeted, or Reason-to-
Javascript, or one for each, or one that includes both. Having to install one
language, and then use tooling and package managing from that language to
install another, strikes me as somewhat ridiculous in this day and age. just
ship the entire tooling stack abstracted away.

~~~
simplify
I'm still not sure I understand. Are you complaining that Reason's
distribution is optimized for JavaScript developers?

~~~
kbenson
No, I'm complaining it's _not optimized_ for the person that just wants to try
it out in any way. Not everyone is using npm or already has Ocaml on their
system. Making them install that entire toolchain first to try our Reason
locally, is sort of crazy, it's just not the crazy that's easily seen when the
costs are already completely amortized because you're a Javascript or Ocaml
programmer already.

And locally is important, since they might want to try a _simple_ app with it,
and not want to set up a whole Javascript dev toolchain with webpack. Sure,
they might end up going that way eventually, especially if they choose Reason
and or React and integrate it into their project, but for a test drive,
_requiring it_ is a large hurdle and a lot more to keep track of.

Reason's current distribution method is akin to Python requiring the
installation of a C compiler toolchain so you can download the source and
compile. To be sure, that's a _wanted_ distribution method of an open source
project like that, but they've rightly recognized that as the _only_
distribution method it would hamper adoption, especially on platforms where
that toolchain is harder to get set up.

I'm not even suggesting Reason go as far as that, exactly. I'm suggesting
Reason ship a tarball/zip with a directory structure that includes Node and a
set of pre-installed packages that provide Reason/Bucklescript. Installation
instructions would include setting a few environment variables (altering PATH,
telling Node where to look for packages). Or instead of Node/npm, provide
Ocaml/OPAM with the correct packages pre-installed (although that might be
slightly harder due to an increased amount of binaries as opposed to
interpreted scripts as with JS). Or both in the same package, if it's not an
excessive amount of work.

I understand it's a lot of work, but at a certain point, expecting prospective
users to install a whole toolchain not for your language, but for the hosting
language, just so they can test it out your language ends up being limiting.
You've said that Reason isn't trying to be opinionated in what kind of app
you're trying to build, but I think it's still being _very_ opinionated in
_the exact process required to build that app_. It's just that you allow for
two opinions instead of one.

Hopefully that's clear enough, and you understand this comes from an actual
desire to make Reason better. I spent a couple weeks in my spare time earlier
this year evaluating whether Reason would work well for a new project I was
starting, and I was extremely excited by the possibility of a shared front-
end/back-end codebase that could be compiled to binaries when needed for
performance reasons. That ended up not working out because I think the
ecosystem isn't quite there yet for that exact need (e.g. a good framework and
ORM that's mostly in Reason, and doesn't require converting from Ocaml to
reason, etc), but a big takeaway I got from that was that as someone not
invested in the Node module ecosystem that much, setting that up, and in a way
that was repeatable and documented, is _painful_ , and that ended up counting
against Reason in the end because I would undoubtedly have to deal with that.
That's not to say I wouldn't with what I'm proposing, but if I'm _already_ on
the Reason cheer squad that's less of a problem, language adoption-wise.

~~~
9question1
Everything I've heard suggests ReasonML is targeted primarily at developers
currently using NPM and working in that stack. I don't think creators of a
tool have a moral obligation to make it easy to use for everything. Most
things have an intended focus, and some happen to be really good for all kinds
of other stuff too. That being said, it does sound like it would be cool for
it to be easier to install without that dependency.

FWIW, Scala and Clojure require the JVM to work at all, and both are pretty
popular.

------
senoroink
I'm still convinced that in the world of frontend development, Ember is the
only framework that hasn't screwed over its users.

My guess is that at Facebook there's too many smart people with differing
opinions. Hence, we have to do an insane amount of research to construct the
grab bag of pulling things together. And once that grab bag is complete,
Facebook says "here's the new cool way to do it".

Ember on the other hand has happily given you the grab bag and has helped you
support your production happens with the most professional, enterprise release
structure.

 _Disclosure: Used to do only frontend development with Ember but switched
jobs and now use React /Ember_

~~~
hknd
You are comparing a view library (react) with a full framework (ember). Ofc
you are supposed to pull things together with react, that's exactly what's
intended.

Compared to react, ember is: slow (1), more difficult to learn (2), has a much
smaller community (3) and, most important aspect to me, has a huge footprint
(4). (I'm not against ember, it might have some nice aspects and features. It
was really nice during the time when they released 1.0. But today I just think
their are better options available)

1: [https://auth0.com/blog/face-off-virtual-dom-vs-
incremental-d...](https://auth0.com/blog/face-off-virtual-dom-vs-incremental-
dom-vs-glimmer/) 2:
[https://guides.emberjs.com/release/](https://guides.emberjs.com/release/) 3:
[https://github.com/facebook/react](https://github.com/facebook/react) vs
[https://github.com/emberjs/ember.js](https://github.com/emberjs/ember.js) 4:
[https://gist.github.com/Restuta/cda69e50a853aa64912d](https://gist.github.com/Restuta/cda69e50a853aa64912d)

~~~
senoroink
I don't disagree with any of your points. React is faster. React has a larger
community. All of it, I agree.

But. When it comes to productivity (actually building something and
maintaining it), I can achieve way more in Ember.

~~~
boyswan
I'm only guessing that's because you have prior experience with Ember and are
only starting to use react now.

I find code written in ReasonML is 100x more maintainable than anything
written in javascript, whether it's react or ember

------
skosch
Currently using Reason. Here's what they don't tell you:

Pros:

* Compile speed is mindblowing. As in, a big project compiles within a few seconds, and incremental compiles are instantaneous. The productivity gains of this cannot be overstated; you just don't get those moments anymore when you're waiting for webpack, your mind wanders off, lets just check HN real quick, ... no, you just stay in the flow. It's great. Elm, on the other hand, is sloooow.

* Type inference works really well. 9/10 times I don't even need to annotate anything and the compiler just knows. The only runtime errors I've ever run into were related to JS externals; the peace of mind knowing "if it compiles, it really works" is a game-changer even compared to TS.

* Error messages are (for the most part) fantastic and really helpful.

* Editor integration is solid, if a bit painful to set up at times.

* The ability to drop in the occasional chunk of dirty `[%bs.raw {...}]` is nice, and a clear advantage over Elm.

Cons:

* JSX support is a joke. You have to wrap every string in `(ReasonReact.String("bla"))`. You have to wrap arrays in `(ReasonReact.array(...))`. Passing children to components is supposed to be easy but will make you rip your hair out for sure. Etc., etc. But I'm sure it'll get there eventually.

* Refmt (the autoformatter) works pretty well but has lots of rough edges still. For instance, it removes all empty lines.

* State management isn't the greatest. Passing down props works alright but often it's just easier to keep things in a central Redux-ish store, especially because every. little. thing. needs to be passed down explicitly for the type checker to work.

* shouldComponentUpdate is hard-coded to `true` right now; there is no shallow comparison by default so everything always re-renders. Will be fixed medium- to long-term, I've been told. Workarounds exist but are pretty gnarly. Elm is much better at this.

* The standard library is a mess. ReasonML has its own, but forget about it; you'll fall back on Belt (the BuckleScript one), which 8/10 times has what you need but then is split into "Belt" parts and "Js" parts for unknown reasons and isn't always complete (e.g. I constantly need to convert from lists to arrays and back, because some utility functions only exist for one of the two, also for no real reason). There is piping syntax (|> and |.) but it's never clear which one to use; sometimes the data goes in first, sometimes it goes in last. You get used to it eventually, but Elm is a land of milk and honey in comparison.

* Lack of sugar: For instance, you'll end up making heavy use of option types, which are great obviously. Unfortunately there's no easy access syntax, so you end up with deeper and deeper levels of nested `Js.Option.getWithDefault()` and/or pattern matching.

* Documentation is meh overall. ReasonML is well documented, but it's only a _very_ thin layer on top of BuckleScript. It took me hours of trial and error to figure out JS interop in practice, setting up "comparators" just to create a `set(int)` etc. You're effectively required to grok all of JS, Reason, Bucklescript, and OCaml at once, and draw from all of them to piece together your code. I think this will take another year or two to iron out.

Overall, I haven't found an option yet that truly works well. Elm is beautiful
but slow and will drown you in boilerplate. ReasonML is fast and mighty but
the UX isn't there yet. React+Redux+Typescript+Babel+Webpack have everything
you need but it's a pain to set up and maintain, it's slow, and you can never
trust it 100%.

(Edit: I should note that both Elm and ReasonML have amazing communities with
very active, friendly and responsive dev teams that really and truly want the
best for their languages. I have huge respect for both and I would encourage
anyone to give them a try, just don't expect a perfectly polished experience
yet.)

~~~
joobus
> You're effectively required to grok all of JS, Reason, Bucklescript, and
> OCaml at once, and draw from all of them to piece together your code.

This was my experience as well. Also, while it may theoretically be possible
to compile native code with reason, the core focus of reasonml is javascript
frontend development at the moment.

> On the native side, since Reason's just a syntax transform: yes, they work
> with Reason too. But the native workflow is currently work-in-progress and
> needs polish.

[https://reasonml.github.io/docs/en/faq.html](https://reasonml.github.io/docs/en/faq.html)

~~~
justincormack
Yeah the native code story has been deferred and using OCaml directly is
currently far easier. This will change.

------
bastawhiz
As a bit of a meta point, I find it really distracting when authors make
random sentences bold. What you believe to be important is not necessarily
what I'll find important, and the added emphasis breaks my flow.

~~~
jimmy1
Placing emphasis on things is commonplace. Sometimes it's in the form of a
literary device such as hyperbole and sometimes it's done typographically. You
shouldn't read it as being "random" but accept it as part of the works. The
author clearly intended to draw attention to those sentences and given it is
his or her article, it should be accepted as part of the article and the
overall message attempting to be conveyed.

~~~
bastawhiz
I'm fine with it when there's one or two. Every paragraph does not need an
emphasized sentence.

------
arvinsim
I got curious about ReasonML when I recently applied to a frontend job that
strongly preferred candidates with ReasonML along with the standard React and
Typescript requirement.

I am using the approaching the mercenary approach to my career so I am
interested if ReasonML would be a good long term bet. What do you guys think?

------
desireco42
When I wanted to try Reason, tooling was just not there, coming from Elm, I
was really put off by things being not more streamlined. I would keep an eye,
as I like Ocaml etc, but at the moment Elm provides much better experience to
me.

Oh yes, big thing is that interop with Reason is way simpler then in Elm.

~~~
simplify
The tooling has really come along since 6 months ago, FWIW. You can now get
started by installing a single npm package[0], and editor support is quite
good[1].

[0] [https://reasonml.github.io/docs/en/quickstart-
javascript.htm...](https://reasonml.github.io/docs/en/quickstart-
javascript.html) [1] [https://reasonml.github.io/docs/en/global-
installation.html](https://reasonml.github.io/docs/en/global-
installation.html)

~~~
desireco42
Let me try it again, I kind of decided to wait it out a little bit until
things are better :)

Thanks.

------
leshow
> A while ago I've written a series of articles about the Elm language and
> they are not that different from each other.

The main difference IMO is that Elm is not really a general purpose language,
you must use the Elm architecture to use it. It is only meant for frontend web
applications.

~~~
pyrale
[http://package.elm-lang.org/packages/chrilves/elm-
io/1.2.1hi...](http://package.elm-lang.org/packages/chrilves/elm-io/1.2.1hile)
elm is a frontend language, you are not forced to use tea. You can bypass the
`program` entry point and use monadic-style command chaining for instance.

~~~
leshow
Sorry on the late reply, but your URL fails and I'm not sure I follow what
you're talking about. I enjoyed Elm quite a bit @ version 0.16, then they got
rid of signals and forced everyone to use TEA. To say that they aren't forcing
you to use it isn't true. AFAIK, you can't even publish a module that
interfaces with javascript without Evan's permission.

------
dmitriid
I'm always confused by statements like "You don't need Redux, you have reducer
components".

Reducer components don't solve the problem of a centralized/shared/common
state and interactions between components.

~~~
boyswan
I thought this and was put off at first, but have come to the conclusion that
you really don't need redux (I've used it thoroughly for years).

We've been converting a large JS react app to Reason, and strongly typed props
solves a lot of problems. Passing props down multiple children is no longer a
burden, and you'll never have that "prop spreading madness". For anything that
reaaally requires some sort of global state, you can use the new react context
api.

The only danger of writing in reasonml is spoiling javascript for yourself

~~~
burger_moon
>We've been converting a large JS react app to Reason

Is the process like say converting to using Flow where you can just add it in
where you want and the application still runs fine, or by convert do you mean
write a whole new application and when it's complete then launch?

~~~
boyswan
Similar to flow. JS interop is great, so you can literally change bit by bit
and refactor from the inside out.

------
k__
I'm still waiting for the async stuff they have planned.

------
pcx
I've been a very heavy user of React with Flowtype. At some point, one would
encounter the limitations of having just a type checker instead of a full-
blown statically typed language. Also, the build story of the react ecosystem
is not that great, especially with Webpack being so slow. There certainly are
more issues that come with JS being JS. ReasonML looks like a good attempt to
solve these problems. Certainly work checking out.

------
jasim
ReasonML is a big con.

It is clothed in ALGOL's syntax, but underneath it is a LISP with functions
that can be stored, curried, passed around, and composed on top of one
another. It doesn't have a Lisp-y syntax and thus no homoiconicity nor macros,
but it does have PPX. ([https://whitequark.org/blog/2014/04/16/a-guide-to-
extension-...](https://whitequark.org/blog/2014/04/16/a-guide-to-extension-
points-in-ocaml/))

The biggest one that Reason pulls however is its syntax. ML based languages
(Hope, Haskell, Miranda, F#, Elm, Purescript etc.) have historically used the
ISWIM syntax (refer Peter Landin: The next 700 programming languages), which
was designed to be similar to mathematical notation. Reason ignores this great
tradition and brings ML to the bread-and-butter programmer with a syntax that
is more ES6 than ES6 itself.

Reason is also the first language where the four major thoughts of PL design
comes together.

It packs ML's type system, which lets you create user defined types on data,
unlike Simula/C++/Java/C# which commingle user defined types and classes.
Interestingly enough, Stroustrup had worked with Pascal the grand-old language
of commercial programming, before he went on a great rage and wrote
CFront/C++. Pascal was statically typed similar to how Reason/OCaml is. It
allows you to define new types that work simply on the shape of the data
without the ceremony of classes. But Pascal's type system at the time was
quite limited - Stroustrup referred to it as strait-jacketed in HOPL II (Prof.
Wirth had meant it only to be a language for teaching after all). Simula's
types and classes however appealed to him, and that paved way for the class-
based type system in statically typed object-oriented languages ever since.

But this doesn't mean that Reason doesn't have support for object-oriented
programming. Reason is OCaml, and the O stands for "Objective", a nod to its
object system that knowledgable people like avsm has averred to as
fantastical.

The Lispy roots of Reason/OCaml makes it functional, which in simple term
means value-based programming, primitives like fold and map defined with
recursion, and linked-lists are used for almost everything, except when it
isn't. Xavier Leroy, who is both the author of Coq and OCaml is a pragmatist -
the OCaml compiler code is choke full of mutation and OCaml has strong support
for imperative programming but tastefully cordoned with an explicit syntax.

It is a langauge that mixes imperative, procedural, object-oriented, and
functional paradigms, sitting just at the confluence of the great PL
traditions that includes ALGOL, Simula, LISP, Modula, ML, and ES6 (!). It is
functional programming for the masses, finally delivered!

------
maxiepoo
Does ReasonML have ML's nice module/functor system? That would be a huge
advantage over elm.

~~~
tonyhb
Yes it does. I had to build an autocomplete functor which generates an
Autocomplete component for arbitrary types when I used ReasonML for my
personal budgeting app.

~~~
zodiac
do you happen to have code online?

~~~
tonyhb
I just pushed to github.

Here's the functor: [https://github.com/tonyhb/reasonable-native-
budget/blob/mast...](https://github.com/tonyhb/reasonable-native-
budget/blob/master/re/Shared/Form.re#L385)

Here's the functor being applied: [https://github.com/tonyhb/reasonable-
native-budget/blob/1f69...](https://github.com/tonyhb/reasonable-native-
budget/blob/1f694c7fa173fde7588ef8a2cb74b9a156b00497/re/NewEntry/NewExpense.re#L19)

Caveats: haven't committed some time and it was my first ReasonML/React Native
app.

------
ocaml201627
Throwaway since embarrassed to ask this: What is the knock against Javascript?

Not trolling, besides lack of types it seems like a pretty darn solid,
ubiquious, elegant/straightforward language to get things done.

For people with strong opinions about this, what is so horrifying about
Javascript to you?

~~~
boyswan
Since moving from javascript to reason/ocaml, i'm genuinely nervous about
refactoring Js now. Helpful compiler errors are literally life changing, and
being able to handle options with Some/None means no more nasty undefined
bugs.

You can do a lot of funky things with javascript, and it's easy to convince
yourself that because you can do it, you should do it. With reason I've found
I can achieve pretty much anything with a far more concise set of tools, and I
can't hack my way around problems - I'm forced to deal with them the correct
way.

Being forced to do things in a certain way has a massive benefit, and
encourages consistency. You can look at 5 different javascript projects and
each one of them will most likely be completely different.

------
ioddly
Somewhat OT, but is the origin story of React written down completely
somewhere? I often see bits and pieces like how it was originally prototyped
in ML, would like to know more.

------
JoshMnem
Using Facebook's software supports Facebook. I think the industry should move
away from that instead of adopting more of their technology. Programmers
should start considering these things.

Alternatives: Elm, Purescript, etc.

Edit: I recommend stopping and thinking a bit about ethics of technology
choices before reactively downvoting.

~~~
kevmo314
One reason I don't use Elm and Purescript is that enforcing the purity of
functions can be a pain. While pure functions are great in theory, sometimes
having a non-pure function is much easier, and I'm okay with my codebase being
99% pure functions.

~~~
purescript
PureScript has a lenient FFI so you can choose to use 99% pure functions if
you like (at your own risk).

------
transfire
But can it app?

~~~
k__
Pretty much, yes.

[https://dev.to/kayis/reason--react-native](https://dev.to/kayis/reason--
react-native)

