I very nearly went with React/Redux before researching Elm. I still think Elm has a much better way to work with side effects. Redux is sort of a "pick your plugin poison" situation there. I'm not familiar with mobx or ngrx.
Aside from the two things I griped about, there is one major API change that I believe the upgrade tool will not do for us. And that is the new Navigation API. My gut feeling is that the effort to adapt this will be more difficult than average. It might take a person-week or more to get familiar with it and get a large project converted over. Subsequent projects should go more quickly, no more than a few days.
For the removal of native modules, I don't think I would monkey patch what we currently use native for (see response to Robin for details on that). I probably would develop an external tool, then get the team accustomed to using it. Probably a few person-days for the dev effort. And inestimable cost for having to be familiar with, integrate, and use yet another tool.
We could likely fix whatever else was broken that the upgrade tool would not catch in a day. Including custom operators, since we didn't use them that much.
However, we aren't planning to upgrade to 0.19. The breaking changes are worse than usual, but we generally don't have a problem with them. Elm compiler surfaces breaking changes pretty well, and we like API improvements. For example, we feel the effects of wonky navigation in 0.18. The bigger issue with 0.19 is the instability we now feel with the platform.
The breaking changes aren't that big (Signals->Tasks was waaaaay bigger). I've ported several of my projects over, most of them taking less than 4 hours (I've got a bunch of 5-15k apps). Porting the Navigation code to 0.19 was done within one hour (depends on your implementation of course).
I wasn't around for Signals, and I bet that was a much larger breaking change. :)
Our largest SPA is about 44k lines of Elm code, and we have about 130k lines of Elm code across all our apps. At some point navigation was in pretty bad shape on the big one. So those were my best guesses.
I very nearly went with React/Redux before researching Elm. I still think Elm has a much better way to work with side effects. Redux is sort of a "pick your plugin poison" situation there. I'm not familiar with mobx or ngrx.
Aside from the two things I griped about, there is one major API change that I believe the upgrade tool will not do for us. And that is the new Navigation API. My gut feeling is that the effort to adapt this will be more difficult than average. It might take a person-week or more to get familiar with it and get a large project converted over. Subsequent projects should go more quickly, no more than a few days.
For the removal of native modules, I don't think I would monkey patch what we currently use native for (see response to Robin for details on that). I probably would develop an external tool, then get the team accustomed to using it. Probably a few person-days for the dev effort. And inestimable cost for having to be familiar with, integrate, and use yet another tool.
We could likely fix whatever else was broken that the upgrade tool would not catch in a day. Including custom operators, since we didn't use them that much.
However, we aren't planning to upgrade to 0.19. The breaking changes are worse than usual, but we generally don't have a problem with them. Elm compiler surfaces breaking changes pretty well, and we like API improvements. For example, we feel the effects of wonky navigation in 0.18. The bigger issue with 0.19 is the instability we now feel with the platform.
The breaking changes aren't that big (Signals->Tasks was waaaaay bigger). I've ported several of my projects over, most of them taking less than 4 hours (I've got a bunch of 5-15k apps). Porting the
Navigationcode to 0.19 was done within one hour (depends on your implementation of course).I wasn't around for Signals, and I bet that was a much larger breaking change. :)
Our largest SPA is about 44k lines of Elm code, and we have about 130k lines of Elm code across all our apps. At some point navigation was in pretty bad shape on the big one. So those were my best guesses.
I just wanted to let you know that a possible alternative to React/Redux that would be far more FP oriented is Mithril/Meiosis
mithril.js.org - vdom lib - for the V
meiosis.js.org - state pattern in conjunction with streams to give you the M/U
Check out the gitter chatrooms, the communities for both are very FP oriented, and working on making it easier to do FP all the time.
this guy came from elm: github.com/pakx/the-mithril-diarie...