I'm trying to decide between Elm and React/Reflux for the js part of a side project. I'm concerned about learning curve and awkwardness of adoption if the project ever turns into something someone else is coding on. I know they are very different technologies, but I think others must be choosing between them. Any thoughts from those who have tried both?
Making Elm faster and friendlier in 0.16
11–20 of 92 posts
Re: Making Elm faster and friendlier in 0.16
#12I'm trying to decide between Elm and React/Reflux for the js part of a side project. I'm concerned about learning curve and awkwardness of adoption if the project ever turns into something someone else is coding on. I know they are very different technologies, but I think others must be choosing between them. Any thoughts from those who have tried both?
The learning curve is not terribly steep, compared to Haskell. There are a lot of good resources, and many friendly people on the mailing list to help you if you decide to learn Elm!
Re: Making Elm faster and friendlier in 0.16
#13I'm trying to decide between Elm and React/Reflux for the js part of a side project. I'm concerned about learning curve and awkwardness of adoption if the project ever turns into something someone else is coding on. I know they are very different technologies, but I think others must be choosing between them. Any thoughts from those who have tried both?
Elm is a much, much smaller community than React. You won’t find as many libraries and ready-made components in Elm as you would in React. On the other hand, when there is an Elm library for something, it’s often of very high quality.
Re: Making Elm faster and friendlier in 0.16
#14I find the Elm language quite fun and I think it has potential.
However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so.
React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when necessary. I like functional programming a lot but I think this is a case where good old object oriented encapsulation provides a more pragmatic solution.
There are all sorts of transient states that a parent's component shouldn't have to care about (Whether I currently have focus, a transient list of changes not yet committed that should be thrown away should I navigate away, is the calendar drop-down opened?, etc, etc) Elm makes it hard to have truly rich and reusable components for that reason as all that transient state must leak to the parent components.
But that's still doable at least, if cumbersome; some other things simply appear impossible, like coding a ReactTransitionGroup equivalent. This React component encapsulates the concept of a changing-over-time list of children and animate in/out the children that changed across two redraws. It needs to know about the previous list of children to diff it with the new. It needs to manipulate the actual Virtual nodes passed to it so that it temporarily leaves the exiting nodes till their animation finished, etc. This thing has tons of state and it needs it to do its job; and it's fine. How would you do this in Elm without leaking the abstraction at every call site ? (I'm looking for a pragmatic, easy-to reuse by everybody solution, not some convoluted sliding Signal of component lists ;-) )
I'm wondering whether performance tweaks should be the focus right now; Elm already had good performances. The issue is adoption, and if it's too convoluted to write (non trivial) reusable components, I don't see how it can succeed. Right now I would never start a complex project with it in fear of getting stuck with a medium-complexity task because the architecture didn't foresee my problem.
Maybe the architecture provide some escape hatches I didn't see, and I would love to be proven wrong.
Re: Making Elm faster and friendlier in 0.16
#15I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…
I have been contemplating the same issue. Unfortunately I haven't yet had enough of a chance to write a large complex application to verify whether or not the Elm Architecture works in practice. In particular the potential for actions and effects of subcomponents to pollute the code of parent components concerns me. If you have some further insight I would love to see a blog post comparing React and Elm that demonstrates where the issues are. Also, the Elm community could potentially make suggestions or take those issues into account for the future.
Re: Making Elm faster and friendlier in 0.16
#16I'm trying to decide between Elm and React/Reflux for the js part of a side project. I'm concerned about learning curve and awkwardness of adoption if the project ever turns into something someone else is coding on. I know they are very different technologies, but I think others must be choosing between them. Any thoughts from those who have tried both?
I personally like React + Immutable.js (for the store) + Redux (https://github.com/rackt/redux) which is more similar to Om and apparently Elm. It's actually the first Fluxlike implementation I willingly use.
Re: Making Elm faster and friendlier in 0.16
#17I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…
It seems to work for NoRedInk and CircuitHub...
Re: Making Elm faster and friendlier in 0.16
#18My first thought on seeing this post was "Oh wow, people are still using the elm email client". I guess I'm getting old.
Re: Making Elm faster and friendlier in 0.16
#19I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…
I think there simply needs to be more exploration in the area. I only know of one person who tried something truly different than the Elm Architecture who wrote about it on the mailing list. Anyone interested and with time to spend should just try different things, be critical of their attempt's ease of use and ease of abuse and see what works.
I think eventually there might be a performance problem with scaling, and yes each components seems to have a bit of boilerplate. But overall the pattern is very reusable and predictable, so if it really becomes the standard (instead of the experiment that it is now!) there could be compiler support for less boilerplate/ better performance.
For now I haven't seen enough people with actual experience using this architecture to really buy any complaints. I've seen more unintuitive things come around in Elm that seem weird (perhaps even wrong) at first, but by really trying it out, I've found that more of those things work really well!
Re: Making Elm faster and friendlier in 0.16
#20My first thought on seeing this post was "Oh wow, people are still using the elm email client". I guess I'm getting old.
hehe, I see this every time on an HN post about a new Elm release. At some point I'll have to look into that old email client, I'm curious what people are talking about.