Does ReasonML have ML's nice module/functor system? That would be a huge advantage over elm.
ReasonML – React as first intended
41–50 of 190 posts
Re: ReasonML – React as first intended
#42Does 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.
Re: ReasonML – React as first intended
#43I'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 think this is a valid point. I can't imagine effectively managing side effects without global state like in Redux.
Re: ReasonML – React as first intended
#44Honest 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.
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 preference. I'd encourage everyone to spend some time with Elm and ReasonML. I find them to be productive and very enjoyable tools.
Re: ReasonML – React as first intended
#45Throwaway 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?
Re: ReasonML – React as first intended
#46I'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.
Exactly my thought. It seems to me that it's just internal component state.. not application state
I think that Redux provides two things that people like:
1. A pattern to organize their state in that was testable and repeatable
2. A way to maintain global app state without prop drilling
I think that (1) is actually the reason that many people pick Redux in the first place. The amount of global, app-wide state in /most/ applications is fairly small IME. I think that the ReasonML team (which works semi-closely with the React team) is banking on things like Apollo, "suspense", the new context API and other things to further reduce the need for a global state store like Redux.
The ReasonReact devs are trying to follow the principal of least power in providing something that solves (1) for component-level state, which solves the 80%, and wait for the rest of the ecosystem to shake out for the rest.
Re: ReasonML – React as first intended
#47Currently 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. Elm, on the other hand, is sloooow.
* Type inference works really well. 9/10 times I don't even need to annotate anything and the compiler just knows. The only runtime errors I've ever run into were related to JS externals; the peace of mind knowing "if it compiles, it really works" is a game-changer even compared to TS.
* Error messages are (for the most part) fantastic and really helpful.
* Editor integration is solid, if a bit painful to set up at times.
* The ability to drop in the occasional chunk of dirty `[%bs.raw {...}]` is nice, and a clear advantage over Elm.
Cons:
* JSX support is a joke. You have to wrap every string in `(ReasonReact.String("bla"))`. You have to wrap arrays in `(ReasonReact.array(...))`. Passing children to components is supposed to be easy but will make you rip your hair out for sure. Etc., etc. But I'm sure it'll get there eventually.
* Refmt (the autoformatter) works pretty well but has lots of rough edges still. For instance, it removes all empty lines.
* State management isn't the greatest. Passing down props works alright but often it's just easier to keep things in a central Redux-ish store, especially because every. little. thing. needs to be passed down explicitly for the type checker to work.
* shouldComponentUpdate is hard-coded to `true` right now; there is no shallow comparison by default so everything always re-renders. Will be fixed medium- to long-term, I've been told. Workarounds exist but are pretty gnarly. Elm is much better at this.
* The standard library is a mess. ReasonML has its own, but forget about it; you'll fall back on Belt (the BuckleScript one), which 8/10 times has what you need but then is split into "Belt" parts and "Js" parts for unknown reasons and isn't always complete (e.g. I constantly need to convert from lists to arrays and back, because some utility functions only exist for one of the two, also for no real reason). There is piping syntax (|> and |.) but it's never clear which one to use; sometimes the data goes in first, sometimes it goes in last. You get used to it eventually, but Elm is a land of milk and honey in comparison.
* Lack of sugar: For instance, you'll end up making heavy use of option types, which are great obviously. Unfortunately there's no easy access syntax, so you end up with deeper and deeper levels of nested `Js.Option.getWithDefault()` and/or pattern matching.
* Documentation is meh overall. ReasonML is well documented, but it's only a very thin layer on top of BuckleScript. It took me hours of trial and error to figure out JS interop in practice, setting up "comparators" just to create a `set(int)` etc. You're effectively required to grok all of JS, Reason, Bucklescript, and OCaml at once, and draw from all of them to piece together your code. I think this will take another year or two to iron out.
Overall, I haven't found an option yet that truly works well. Elm is beautiful but slow and will drown you in boilerplate. ReasonML is fast and mighty but the UX isn't there yet. React+Redux+Typescript+Babel+Webpack have everything you need but it's a pain to set up and maintain, it's slow, and you can never trust it 100%.
(Edit: I should note that both Elm and ReasonML have amazing communities with very active, friendly and responsive dev teams that really and truly want the best for their languages. I have huge respect for both and I would encourage anyone to give them a try, just don't expect a perfectly polished experience yet.)
Re: ReasonML – React as first intended
#48Using 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.
One reason I don't use Elm and Purescript is that enforcing the purity of functions can be a pain. While pure functions are great in theory, sometimes having a non-pure function is much easier, and I'm okay with my codebase being 99% pure functions.
PureScript has a lenient FFI so you can choose to use 99% pure functions if you like (at your own risk).
Re: ReasonML – React as first intended
#49Honest 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…
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?
Re: ReasonML – React as first intended
#50Using 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.
One reason I don't use Elm and Purescript is that enforcing the purity of functions can be a pain. While pure functions are great in theory, sometimes having a non-pure function is much easier, and I'm okay with my codebase being 99% pure functions.
My point is more about ethics in tech than a specific language. I expected downvotes, but wish that the industry were different.