
A First Reason React App for JavaScript Developers - mambodog
https://jamesfriend.com.au/a-first-reason-react-app-for-js-developers
======
JasonSage
I tried Reason out maybe half a year ago. To me, the exceptional thing which
the Reason project lacks is a polished developer experience. It feels very
much like a hacked together combination of technologies which requires the
developer to install several things just to get a working compiler.

I think before I would try Reason again there would need to be some effort put
into streamlining setup and managing of the developer environment.

EDIT: Downvoted? Let's hear some feedback and other opinions maybe?

~~~
quicksnap
There has been a lot of work in making the developer experience as awesome as
possible. I know that, for the core team, it is one of the highest priorities.

While this tutorial doesn't use the official bootstrap, you can see it here:
[https://facebook.github.io/reason/gettingStarted.html](https://facebook.github.io/reason/gettingStarted.html)
\-- It's only a few lines in your terminal!

The integration with VSCode is pretty amazing, too.

------
IX_Hispana
This, not unlike Elm, looks pristine, ivory-tower-ish to me. The examples are
always neatly self-contained or consuming a real simple json API. They're
fiddles. Fiddles always look neat.

I think it would do these types of projects a lot of good to do something real
using third party libraries. Convince developers and companies they're real,
not toys. I still haven't seen a blog post explaining Elm along with a masonry
library, socket.io, bootstrap, shopify, etc.

Probably I'm not getting what's the real use case for these things. It can't
be writing web apps.

~~~
mambodog
I don't think Reason is like Elm in this way. Whereas Elm requires you to
wholly buy in to the Elm world, Reason can easily be brought into a large
existing codebase.

Large chunks of messenger.com are written in Reason. I'm pretty sure that
qualifies as a 'web app'.

~~~
IX_Hispana
Hey, thanks for the reply. What would you say is a good opportunity in a
project to sneak some Reason in?

------
pavlakoos
Why does it exist at all?

~~~
yebyen
Static typing and compile-time checking are two very good reasons, same
reasons you'd use Elm.

I am not a react developer but I have heard that one of the common complaints
about React is ... that it's not Elm, or in more explicit terms, in case you
don't know anything about Elm, ... that it's very easy to write code that will
break if you poke it the wrong way.

In a static typed language such as Elm (or Reason, based on skimming
briefly)... when you get input that can mutate the state of the program, it
comes in the form of a message. The messages are typed, so you know what
values to expect.

If you write a switch/case statement that handles a message type, the compiler
will balk at you if you change the values that the message type can have,
without updating the case statements that operate on that type to cover them
all.

tl;dr: because runtime errors are a b _

~~~
hazza1
Another Facebook project Flow gives similar if not as comprehensive benefits
whilst staying in JavaScript.

~~~
yebyen
Does it really stay in JavaScript though?

I'm not familiar with the latest ECMA and standards updates and I suppose I
don't really know what modern JS actually looks like, but the example on this
page[1] doesn't look like syntactically valid JavaScript to me.

If you write code that has to be compiled before it turns into JavaScript,
there's another benefit though... it's that you can never accidentally promote
code to a server that hasn't already been vetted by the type-checker!

Or, even run it locally! You are guaranteed that the type checker has been run
before the code hits a runtime environment.

Looking at Flow, I'm seeing there's a tool `flow` that you run any time you
want to check the types. I think there's a background process way to run flow,
that mitigates this issue somewhat... but if Flow is in fact implemented to
always be syntactically valid JavaScript, that could be a bad thing.

[1]: [https://flow.org/en/docs/usage/](https://flow.org/en/docs/usage/)

~~~
Raphael
Babel has a bunch of extensions to JavaScript that are widely used. Sounds
like it just finds and strips out type annotations.

[https://babeljs.io/docs/plugins/syntax-
flow/](https://babeljs.io/docs/plugins/syntax-flow/)

[https://babeljs.io/docs/plugins/transform-flow-strip-
types/](https://babeljs.io/docs/plugins/transform-flow-strip-types/)

------
crucialfelix
There is an online ocaml to js converter here:
[http://bucklescript.github.io/bucklescript/js-
demo/index.htm...](http://bucklescript.github.io/bucklescript/js-
demo/index.html)

------
megamindbrian
For what reason do we need yet another dialect of JavaScript?

~~~
girvo
It's a "dialect" (sort of) of Ocaml, with all of the beauty that is its type
system and Functor (not thing.map, parameterized modules!) that can compile to
JavaScript via Bucklescript.

------
jaequery
this might be the tipping point of js fatigue for most React/JS developers. we
can only hope this doesn't catch on, fingers crossed.

~~~
TheAceOfHearts
If it's ends up being notably superior in multiple ways, and you already have
a properly configured and flexible build toolchain in place (i.e. Webpack),
adding support should be trivial. I haven't personally used it, but a quick
search landed me on the bs-loader [0] repo, which claims to work with both
OCaml and Reason files.

As I understand it, and I'm not very familiarized with Reason, the team behind
the project is working hard to have a good interop story. We've seen the same
thing with React's versioning scheme [1]! Going forward there shouldn't be
horrible breaking changes, and in the cases where stuff must be broken, they
appear to commit to providing a clear migration path that can be adopted
gradually.

There's probably plenty of good use-cases for using something like Reason.
Should it be used everywhere? No, certainly not. But having worked on a
reasonably sized JavaScript web app, my experience has been that it becomes
increasingly difficult to maintain as it grows. Even with something like Flow
or TypeScript, you have to think very carefully any changes. Luckily, the
JavaScript ecosystem has modularized everything quite heavily, so you can
usually contain things that end up being "bad ideas" and gradually chip away
at em.

The app I worked on wasn't even that large or complicated, so I have a very
hard time wrapping my head around the challenges faced by engineers working on
Facebook's scale.

[0] [https://github.com/rrdelaney/bs-loader](https://github.com/rrdelaney/bs-
loader)

[1] [https://facebook.github.io/react/blog/2016/02/19/new-
version...](https://facebook.github.io/react/blog/2016/02/19/new-versioning-
scheme.html)

