1. 3

  2. 1

    Hummm… It’s hard to agree with reasonml being elm done right… Elm is pure with managed effects… That makes it very very different

    1. 1

      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.

      I’m a little unclear from the article what about React is “done right” only by ReasonReact. If it’s not needing Redux, well, you never needed to use Redux. There are lots of state management libraries for React. Most of them are a lot simpler than Redux (to make my bias clear: I am not a fan of Redux, having used it extensively). You don’t need to use ReasonReact to get away from Redux.

      Being pedantic, you also don’t need to use React if you’re using ReasonML. You could ignore ReasonReact, it’s just a library for ReasonML.

      Also, from following ReasonML for the past year or more, I gather that typing support for third-party libraries is tiny (non existant?) compared to, say, TypeScript. And writing your own types and interop for JS libraries seems tedious, syntactically ugly (to my eyes) and error prone. And likely you’ll be maintaining those forever yourself, for all your dependencies. Maybe there’ll end up being enough community-supported typings that you can draw on, but that seems like a gamble at this point. So you could be in for a lot of maintenance work.

      I’m not trying to rip on ReasonML or ReasonReact, I think they’re exciting, but I think there are a lot of hurdles to jump when using them.