Judging from the rest of your post, that sounds like a severe case of stockholm syndrome ;)
Hah. But seriously functional MVU is amazing. I've done front end projects in a sampling of the standard technologies (component-based or just vanilla) and they have real issues with regard to maintenance and the kinds of designs they tend to encourage. I did research before choosing Elm, and a test project.
We have been using Elm since 0.16 (edit: actually it might have been 0.17), and releases (including 0.19) had an upgrade guide and even an upgrade tool to resolve most breaking changes. So there hasn't been a lot of risk so far even though each release breaks some things typically.
Also the author works for a company which uses Elm for the basis of their own product. So one would think that would be a stabilizing force.
I expected that it was getting to a point of solidity. So imagine my surprise when this release dropped with breaking changes and a "too bad, so sad" mindset. Sometimes when projects do that, they will issue service releases to the old product so people can keep using it. But I doubt that will be the case here.
I agree, and the pattern and amongst them supporting libraries has risen to stellar popularity in many other web frontend ecosystems as well (redux, mobx, ngrx) - for good reason.
I never looked very deep into Elm. From my superfical and cursory exposure to it I got the impression that the language was quite opinionated (which is not everyone's cup of tea, but since it tend to agree with the opinion, it would certainly not be a dealbreaker for myself) and that previous Haskell knowledge helps to a not so small degree.
I'm also willing to cut everything with a version number, that starts with 0, some slack - but I understand your frustration. Out of curiosity: could you give a ballpark figure how much manual work adapting your codebase to the 0.19 release would be? Or do you consider it to be rather unfeasible (maybe due to business reasons, deadlines etc)?
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.
Hah. But seriously functional MVU is amazing. I've done front end projects in a sampling of the standard technologies (component-based or just vanilla) and they have real issues with regard to maintenance and the kinds of designs they tend to encourage. I did research before choosing Elm, and a test project.
We have been using Elm since 0.16 (edit: actually it might have been 0.17), and releases (including 0.19) had an upgrade guide and even an upgrade tool to resolve most breaking changes. So there hasn't been a lot of risk so far even though each release breaks some things typically.
Also the author works for a company which uses Elm for the basis of their own product. So one would think that would be a stabilizing force.
I expected that it was getting to a point of solidity. So imagine my surprise when this release dropped with breaking changes and a "too bad, so sad" mindset. Sometimes when projects do that, they will issue service releases to the old product so people can keep using it. But I doubt that will be the case here.
I agree, and the pattern and amongst them supporting libraries has risen to stellar popularity in many other web frontend ecosystems as well (redux, mobx, ngrx) - for good reason.
I never looked very deep into Elm. From my superfical and cursory exposure to it I got the impression that the language was quite opinionated (which is not everyone's cup of tea, but since it tend to agree with the opinion, it would certainly not be a dealbreaker for myself) and that previous Haskell knowledge helps to a not so small degree.
I'm also willing to cut everything with a version number, that starts with 0, some slack - but I understand your frustration. Out of curiosity: could you give a ballpark figure how much manual work adapting your codebase to the 0.19 release would be? Or do you consider it to be rather unfeasible (maybe due to business reasons, deadlines etc)?
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...