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

51–60 of 190 posts

Re: ReasonML – React as first intended

#51

Post by amenod »

simplify wrote: post #34
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…

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

Thanks (to the others too), that does sound good.

Re: ReasonML – React as first intended

#52

Post by lilactown »

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.

As someone who's done a bunch of interop in ReasonML & ClojureScript, ClojureScript interop blows ReasonML away (in terms of ease) at the language level.

The current problem with ClojureScript interop is the Google Closure compiler's support for stuff on npm. I switched our team to using shadow-cljs[0] and it solved all of those problems. Would highly recommend.

[0] http://shadow-cljs.org/

Re: ReasonML – React as first intended

#53

Post by scottmf »

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.

Re: ReasonML – React as first intended

#54

Post by cies »

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…

> compared to Elm or ReasonML

PureScript deserves a mention in this list as well. More full-featured and general purpose than Elm, cleaner design than ReasonML. Prolly the smallest community of the 3.

Re: ReasonML – React as first intended

#55

Post by boyswan »

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…

You forgot the best bit... variants and pattern matching!

Re: ReasonML – React as first intended

#56

Post by cies »

mLuby wrote: post #23
ch4s3 wrote: post #18

Earlier quoted context omitted.

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.

Those are all good things, but they aren't really the same reason. Parent describes JQuery to React as spaghetti code -> reasonable code, whereas React to ReasonML sounds like reasonable code -> reasonable code (with better tooling).

JS code can be a pain to maintain (in the membrane... joke, sorry, I'll stop). And FB knows this. That's why they developed ReasonML: great JS interop, but much better maintenance story (than both JS and TS) because of the stronger typing discipline.

On a large code base, increased maintainability can be a huge commercial advantage.

Re: ReasonML – React as first intended

#57

Post by skosch »

boyswan wrote: post #55
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…

You forgot the best bit... variants and pattern matching!

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

Re: ReasonML – React as first intended

#58

Post by cies »

Scarbutt wrote: post #24
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…

Some developers believe (and prefer) in that good type systems help for large software projects.

A company like FB believes so too, judging from how much resources they throw at it.

Re: ReasonML – React as first intended

#59

Post by cies »

ocaml201627 wrote: post #45

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?

I tend to disagree with: darn solid and elegant.

It is easy to write flaky code in JS and rarely the language helps you to go for the elegant solution. On this front ReasonML brings huge value to the table.

Re: ReasonML – React as first intended

#60

Post by Kiro »

RussianCow wrote: post #49
bratsche wrote: post #32

Earlier quoted context omitted.

You wouldn't necessarily use ReasonML instead of React, you can use them together. You would use ReasonML instead of whatever Babel/es6/es7/typescript/whatever. Here is the official React binding (or whatever you call it) for ReasonML: https://reasonml.github.io/reason-react/ Using this you would still be using React, just in a different language. But my understanding is that you would not be using redux (if you are…

> But my understanding is that you would not be using redux (if you are now) because it doesn't make sense in a language like ReasonML. Why would using Redux not make sense? It's not like the problem of sharing state between components goes away with a functional language?

It's covered in the article:

"When using ReasonML, we don't need Redux anymore. ReactReason stateless components already come with the concept of a build in reducer, which is meant to take care of the problems Redux used to address."

Post reply on HN