Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ReasonML – React as first intended

imaginarycloud.com

Post reply on HN
Print view View original

81–90 of 190 posts

Re: ReasonML – React as first intended

#81

Post by specialp »

Scarbutt wrote: post #33
hellofunk wrote: post #19

Earlier quoted context omitted.

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.

How's Clojurescript interop story? what always holds me from using these compile to JS langs is the fear that the gains you get from using a better/nicer language are completely destroyed by all the interop churn.

Clojurescript has very easy JS interopt (clj->js), (js->clj) plus easy ways to export external js library functions. There's been nothing I can't do in CLJS.

Re: ReasonML – React as first intended

#82

Post by tfranco »

JoshMnem wrote: post #31

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.

Interesting... we covered ELM a few weeks ago: https://www.imaginarycloud.com/blog/elm-javascript-reinvente...

Re: ReasonML – React as first intended

#83

Post by adamkl »

Scarbutt wrote: post #71
scns wrote: post #70

Earlier quoted context omitted.

Facebook rewrote Messenger in Reason. Before they had hundreds of bugreports in a year. Afterwards? Less then ten.

Is there some official analysis of this?

Note, the ReasonML rewrite refers to the Web version of Messenger only (at the time of this blog post):

https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...

Re: ReasonML – React as first intended

#84

Post by tfranco »

actsasbuffoon wrote: post #44
yashafromrussia wrote: post #20

Earlier quoted context omitted.

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.

Typescript, Redux, and Immutable.js work together as a pretty compelling stack, but they involve a fair bit of boilerplate compared to Elm or ReasonML. Elm provides type safety, immutable data structures, and state management in a very compact but readable way. In fact, Redux was strongly inspired by Elm's state management. All of these stacks are perfectly acceptable choices, so it comes down to a matter of personal…

Interesting. We covered ELM a few weeks ago: https://www.imaginarycloud.com/blog/elm-javascript-reinvente...

Re: ReasonML – React as first intended

#85

Post by baddox »

yashafromrussia wrote: post #20
amenod wrote: 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.

The jump from Typescript/Flow to ReasonML is as significant (or more so) than the jump from plain JavaScript to Typescript/Flow.

Re: ReasonML – React as first intended

#86

Post by Rotareti »

amenod wrote: 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…

The last ReactJS project I was working on ended up with libraries such as Ramda, ImmubtableJS, recompose, etc, in order to make the codebase more functional... We also switched to TypeScript for the type-system. While these libs improved the overall experience, it never came close to what you get from a proper functional language. I'm currently working on a frontend that uses ReasonReact and it feels much smoother.

> Honest question: why would someone use this instead of React?

The libraries I mentioned have __a_lot__ of stars on github, I'm sure many people using them, those might be better off with ReasonML.

I hope ReasonML will succeed and the ecosystem catches up. ReasonML is the fucntional general purpose language I always wanted. If they get the concurrency story right it might become a nice functional alternative to Golang as well.

Re: ReasonML – React as first intended

#87

Post by JoshMnem »

scottmf wrote: post #53
JoshMnem wrote: post #31

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.

We can always fork these things if it comes down to it.

If it were going to be forked, then it would already have been forked. The unethical nature of Facebook is not well-hidden.

Re: ReasonML – React as first intended

#88

Post by bam365 »

boyswan wrote: post #65
skosch wrote: post #57

Earlier quoted context omitted.

True! I suppose I'm comparing to Elm mainly.

Also for your issue with deeply nested options, have a look at this https://medium.com/w3reality/working-with-option-using-maybe...

And if you don't want to implement the option monad yourself, there's the bs-abstract library, which contains a bunch of category theory definitions and implementations. I have gotten a lot of mileage out of it even in the small amount of ReasonML I have written. That plus ppx_let offers a pretty good monadic programming experience.

Re: ReasonML – React as first intended

#89

Post by skosch »

lsadam0 wrote: post #79
skosch wrote: post #47

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. E…

> shouldComponentUpdate is hard-coded to `true` As in you can't override it? `shouldComponentUpdate` resolving to true in the absence of a custom method or PureComponent usage is standard React behavior: https://github.com/facebook/react/blob/7350358374036c0834ea6...

Well, you can (it's called `shouldUpdate` in ReasonML) but it doesn't work. You have to make it a reducerComponent, manually keep track of the previous props as if they were mutable state, and then do the comparison explicitly. This is from a conversation I had just a few days ago on the offical Discord chat.

Re: ReasonML – React as first intended

#90

Post by hknd »

senoroink wrote: post #76

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…

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... 2: https://guides.emberjs.com/release/ 3: https://github.com/facebook/react vs https://github.com/emberjs/ember.js 4: https://gist.github.com/Restuta/cda69e50a853aa64912d

Post reply on HN