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

61–70 of 190 posts

Re: ReasonML – React as first intended

#61

Post by boyswan »

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?

Since moving from javascript to reason/ocaml, i'm genuinely nervous about refactoring Js now. Helpful compiler errors are literally life changing, and being able to handle options with Some/None means no more nasty undefined bugs.

You can do a lot of funky things with javascript, and it's easy to convince yourself that because you can do it, you should do it. With reason I've found I can achieve pretty much anything with a far more concise set of tools, and I can't hack my way around problems - I'm forced to deal with them the correct way.

Being forced to do things in a certain way has a massive benefit, and encourages consistency. You can look at 5 different javascript projects and each one of them will most likely be completely different.

Re: ReasonML – React as first intended

#62

Post by cies »

boyswan wrote: post #38
dmitriid wrote: post #14

I'm always confused by statements like "You don't need Redux, you have reducer components". Reducer components don't solve the problem of a centralized/shared/common state and interactions between components.

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…

> The only danger of writing in reasonml is spoiling javascript for yourself

Curing yourself :)

Re: ReasonML – React as first intended

#63

Post by bratsche »

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?

I commented before reading the article, just going by memory of reading about this before. Perhaps I was wrong about it not making sense in the language, but more that it isn't necessary when using ReactReason because the concept is built into that binding.

Re: ReasonML – React as first intended

#64

Post by lilactown »

Scarbutt wrote: post #39
grayrest wrote: post #28

Earlier quoted context omitted.

Om isn't so much a take on React as it is a take on the state management layer and it uses React under the covers. I believe it's been largely superseded by re-frame [1], which follows the Redux / TEA model. There is an Om Next and that's basically a take on Falcor / Relay using the Datomic pull syntax but I haven't heard that much about it outside the talks where he was announcing it. [1] https://github.com/Day8/re-…

Why doesn't Clojurescript eliminates the need for something like Redux where Reason does? as mentioned in the article.

IME using ClojureScript, you don't really need something like Redux/re-frame all that often either.

Once you've handled local state and remote data dependencies, you have like 10% of your app state left. That can easily be solved with a global atom (a la re-frame) or something like the new React context API.

Our understanding of how to handle state, remote data fetching, etc. has grown a lot over the last few years. Both the React & ClojureScript ecosystem went all-in on global state stores like Redux because, at the time, we thought we needed it. It felt like, if we needed a global state store for one thing, that it made more sense to just put everything in there for cohesiveness. It also was hard to determine up-front what was needed globally (mostly data IME) and what was only needed locally.

It turns out that local state and something like apollo/relay/"suspense" for remote data solve the 80-90% case, and now we're getting better tools like React context to handle the last 10%. I don't think that Redux/re-frame is going away, but the number of apps that I would implement with them has gone way down over the years.

Re: ReasonML – React as first intended

#65

Post by boyswan »

skosch wrote: post #57
boyswan wrote: post #55

Earlier quoted context omitted.

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

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

Re: ReasonML – React as first intended

#66

Post by posterboy »

seanwilson wrote: post #21
bastawhiz wrote: post #5

As a bit of a meta point, I find it really distracting when authors make random sentences bold. What you believe to be important is not necessarily what I'll find important, and the added emphasis breaks my flow.

I'm assuming it's more to help with skim reading.

This is best done using the first sentence of a paragraph. Make a statement first and support it with the rest of the paragraph. At least that's a style judges use on verdicts. That way I can skim a long text easily enough.

The opposite is having a conclusion at the end. That's used for opinions. A severe disagreement (not to say error) can be found faster if building an argument from the ground up.

If your conclusion is somewhere in the middle and scattered all over the place, you might want to highlight that indeed. I prefer stream of conscioussness for quick notes, but bringing it into a proper format can help to refine the argument.

Re: ReasonML – React as first intended

#67

Post by burger_moon »

boyswan wrote: post #38
dmitriid wrote: post #14

I'm always confused by statements like "You don't need Redux, you have reducer components". Reducer components don't solve the problem of a centralized/shared/common state and interactions between components.

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?

Re: ReasonML – React as first intended

#68

Post by komuW »

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

This reminds me that all those points would apply to dartlang

Re: ReasonML – React as first intended

#70

Post by scns »

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.
Post reply on HN