Live data from Hacker News

ReasonML – React as first intended

imaginarycloud.com

11–20 of 190 posts

Re: ReasonML – React as first intended

#11
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.

Re: ReasonML – React as first intended

#12
post #2

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?

bs.raw is actually really easy to use, but it's not encouraged since it's mostly a stepping stone to "real" bindings.

There is definitely a learning curve to JS bindings, but it pays off as you only have to learn them once.

Re: ReasonML – React as first intended

#13
post #9

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... Interested to take this for a spin.

> ClojureScript's take on React, Om

His take on React in ClojureScript would probably be a better qualifier, there have been others. Reagent is a popular alternative take on a cljs React interface.

Re: ReasonML – React as first intended

#15

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.

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... [1] https://reasonml.github.io/docs/en/global-installation.html

Re: ReasonML – React as first intended

#16
post #2

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?

The reason I found JS interop confusing in Bucklescript is there are multiple ways to do it, so it wasn't obvious which was the right way. I think a lot of that is due to the fact that Js is ultimately a very different language from OCaml, and so to get the two to work together there were quite a large number of different scenarios to cater for.

Once I got over that hump, it was all fairly simple.

Re: ReasonML – React as first intended

#17
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?

Re: ReasonML – React as first intended

#18
post #17

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 bec…

For the same/similar reasons, more or less. You get a great type system, merlin(a great analysis tool), faster compilation, all kinds of great compile time checks, and you can still use react.

Re: ReasonML – React as first intended

#19
post #17

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 bec…

Because React is a very natural fit for a functional language of which JS really isn’t. Which is also why it is so lovely to use React from Clojurescript.

Re: ReasonML – React as first intended

#20
post #17

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 bec…

Someone who knows React can easily be using ReasonML. So to me, the question is, why not? You can get most of the features of ReasonML with 3rd party libs - TypeScript for type safety, Redux for state management, and Immutable. However, when I look at the build time comparison, I doubt you'd get something as fast with JavaScript, at least not today.
Post reply on HN