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

71–80 of 190 posts

Re: ReasonML – React as first intended

#71

Post by Scarbutt »

scns wrote: post #70
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…

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?

Re: ReasonML – React as first intended

#72

Post by hellofunk »

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.

Clojure, on any platform (JVM, JS, .Net) has a fundamental language-level philosophy of easy interop with the host.

Re: ReasonML – React as first intended

#73

Post by boyswan »

burger_moon wrote: post #67
boyswan wrote: post #38

Earlier quoted context omitted.

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

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

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

Re: ReasonML – React as first intended

#74

Post by Can_Not »

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 love JavaScript, but also recognize when some other things are better (in the useful, pragmatic, non-edgy, non-trendy sense). Bucklescript/reasonML seem to be a way to use something better and keep what I like about JS without starting at zero in the job market or ecosystem. Specific example: if reasonML gets big enough then all react jobs are potentially reasonML jobs. In the bigger picture, purescript/elm/bucklescript/reasonML/clojurescript all have one problem. There's a lot of hype about how much better they are, but also the job market for them is nearly empty. This makes it difficult to justify spending a lot of time evaluating them before the jobs exist. I end up using flow or typescript in the short run.

Re: ReasonML – React as first intended

#75

Post by desireco42 »

simplify wrote: post #15
desireco42 wrote: post #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.

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

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

Thanks.

Re: ReasonML – React as first intended

#76

Post by 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

Re: ReasonML – React as first intended

#77

Post by RussianCow »

Kiro wrote: post #60
RussianCow wrote: post #49

Earlier quoted context omitted.

> 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."

Reducers are only one (and IMO the least important) part of using Redux with React; the other part is `connect`, which lets you pass global state directly into a deeply nested component without passing it all the way down the tree via props. Unless I'm mistaken, ReactReason doesn't offer an alternative to that.

Re: ReasonML – React as first intended

#78

Post by zodiac »

tonyhb wrote: post #42
maxiepoo wrote: post #41

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

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.

do you happen to have code online?

Re: ReasonML – React as first intended

#79

Post by lsadam0 »

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

Re: ReasonML – React as first intended

#80

Post by rdrey »

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…

Thanks for this. I was looking for a thorough comparison with Elm. If you had to start a brand new project, which would you choose? Do you believe that struggling through the learning curve is worth it?
Post reply on HN