Elm 0.19 was released yesterday. There were a significant number of breaking changes at every level: configuration, tooling, library, language. But those are not what this post is primarily about (edit: and Elm provides an upgrade tool to autofix many of these things). For my team, this release broke our hearts.
Two changes that placed the proverbial "straw that broke the camel's back": Removal of custom operators and native modules. At first I only saw the removal of custom operators, and I posted my reaction to that here. The removal of native modules was not mentioned in the 0.19 release notes so I didn't find out about it until today. I just happened to think of it, and a search turned up this post.
The post on native modules was back in March, so how did I not know about it?
Community
I disconnected from participating in the Elm community a little while back. I didn't say much about it at the time, but I'll share the reasons. I love the Elm platform and use it, but decided that the way the community is managed is too frustrating. The tone is firmly set by the way the Elm Github issues are managed. Many of them are locked to prevent disagreeable feedback, or because they are personal items only for the blessed few contributors, even though they are in public. If you post an issue, you are likely to get smacked on the hand for not doing things "properly". Properly means a rigorous SSCCE for bugs, or participating in the gladiator arena of public forums for ideas/requests/suggestions, or you can forget both of those things if you went the extra, extra miles to be trusted as a contributor. I say gladiator arena, but the Elm community is really very nice in general, especially for helping newcomers. However there are more than a few people who have their rulers out and ready to smack that hand to enforce whatever Evan (the creator of Elm) has said or not said. So chances are high that posting "ideas" or "feedback" on the forum will result in being chided. This, in turn, justifies that there was no "agreement" on your post among the community so it can be ignored. So the "go post on the forum first" rule is an effective way to ignore feedback.
Apparently since Elm forums have moved to (edit: Reddit and) Discourse, threads there can be locked too. When mods know Evan doesn't want to hear your disagreement on a particular issue, they may preemptively lock posts where it might surface. In the end, it feels like the D in BDFL is taken a little too seriously over there. So I appreciated the product but mostly stayed away from the community, and didn't happen to catch the posts telegraphing changes.
To be fair, I did have a bad experience myself, and have fault in that. But I have observed this pattern of unwelcomeness in Elm's old github and google group many times as an onlooker. And it isn't this way in other projects I've worked with.
Control
The removal of custom operators was ostensibly for the good of Elm. However, in the post explaining the reasoning behind their removal, an estimated 5% of users have them. And several of the reasons for using them are in common with other languages (task chaining, parsing). In the end, specific custom operators were blessed by Evan and were allowed to remain as exceptions to the rule. But whatever ordinary Elm users think is a valid custom operator for their use cases is "bad" for Elm. Okay...
Theoretically I can still inject native modules through monkey patching in 0.19. (Javascript, right!) However with dead code elimination, monkey patching could be a bit difficult unless you turn off optimizations. But the real kicker is that native modules are still there. They are just reserved for a few Elm contributors only. The rest of us should not have access to this expert feature. Apparently the 40 total lines of native code that I use will completely break the Elm community. Even though there is no other reasonable way to do what I need. Okay...
Minor but indicative: Evan has posted many times telling users to change the way they talk or think about Elm. (Fair point: he's nice about it and there are valid points. But still... indicative.) Examples: Don't use the word Components. Don't say "native"; say "kernel" instead. Union types should now be called Custom Types. But don't you dare respond to one of his posts -- there is always a closing section instructing you of the only few acceptable replies or to just not reply at all. Okay...
Considering all of the above, a picture is forming for us: we can expect to be overbearingly micromanaged as Elm users. And feedback (well, disagreement) is not welcome or considered even when it is decisive and voluminous, like on native modules. Evan decides he just doesn't like something he sees Elm users doing (even if it has credibility from similar languages, like custom operators), it gets disabled in the next release. My way or the highway. Despite all the amazing things Elm has been to us, that's intense behavior for a toolchain. And not really a situation my team wants to be in.
What now?
The way I see it, we have a few options.
Keep using 0.18
I have not had any major issues with 0.18. We could avoid the broken things that have been pointed out in the changelog (like Arrays). However, this is not a long term strategy. It seems unlikely that 0.18 will ever see another bugfix. Old versions of tools (like Create Elm App) eventually stop being maintained. Meanwhile Computer Science and the web advances on.
Monkey patch 0.19
Because of the dead code elimination, putting the formerly "native" code in through monkey patching has some unknowns. But the deeper issue is that by moving to 0.19 we are still in a place of feeling unstable with the future of our toolchain.
Wait for an Elm fork
Lots of tree names are probably still available (i.e. acacia, poplar, etc). Unfortunately we do not have the resources to maintain a fork. But it seems likely that somebody will draw similar conclusions to us and be in a place where they want to create one. Even then, this path has a lot of unknowns.
Wait for Elm to solidify
Most projects reach a phase where they solidify. Meaning there is some effort to maintain backward compatibility. If Elm decides to do this at some point, we could evaluate where the latest version is. Maybe by then there legitimately won't be a need to have the freedoms which were taken away, so it will be a moot issue. However, probably as long as Encoders and Decoders are the only official way to deal with JSON, we will need native code. 20 lines of native code saves us hundreds of lines of encoders and decoders.
Switch to something else
The only other Model-View-Update platform I'm aware of is Fable-Elmish. It uses F#, which we already use for APIs anyway. The unfortunate bit about that is that F# is not a pure language. So it takes discipline to write pure functions. Whereas Elm has been taking purity too far with some of these recent changes, F# is not quite far enough IMO for the front end. But F# is great for APIs since they are about integrating external systems (e.g. UI, database, email, files, etc). F# would be harder to use there if it had a lot of overhead to perform side effects. Striking the right balance for the use case is important. Anyway, it is still an option on the table.
There could also arise an alternative MVU platform at some point. I believe ClojureScript has a library which works similar to MVU. I don't really want to go back to a component-based system. (Yes, pure function MVU is that good.)
Conclusion
The team has all agreed that sticking with 0.18 is the best choice for us right now. We have some apps coming up that we will create with 0.18, ignoring 0.19. We will experiment with Fable. We will see if another MVU style platform is around. Eventually 0.18 will start to rot and we will need to switch to something else going forward.
We find this situation really disheartening. We love Elm and never wanted to use anything else. But we have begun to feel that our relationship with Elm is unstable. 💔
Latest comments (83)
Thank you for sharing your experience. I am curious if you have anything to add to this after a few months, or if this is also your current assessment. Thank you!
Thanks for the comment. I haven't been following Elm news so I don't know if there have been any recent developments. However, I did watch Evan's recent video on the hard parts of open source. It reinforces my assessment that there is a top-down authoritarian perspective on managing the community, and it isn't the place for us.
Analysis of the video: Evan brings up Orwell's 1984 as cultural shift to a distrust of authority. The context of his talk seems to imply that mistrusting authority is part of the problem. The communication patterns he brings up at the end are very controlling of the end user, ostensibly for the good of the community. This makes the intention seem deeper than just controlling the destiny of the Elm product. It means also controlling a collectivism-based Elm community using authoritarian strategies. This agrees with my own experiences and observations. For me, this is a bit too intense of a requirement from a technology.
I have started a project in F# using Fable-Elmish libraries, and it is equivalent (and syntactically similar) to Elm but with a lot more freedoms. In fact I can go a step further now and test that the update function produces not only the correct model, but also the correct declared effects. TBH we don't do unit testing of Elm UIs, because we haven't had the need. But I appreciate being able to declare my own effects and write their implementations in F# off in its own corner, rather than having to go across ports and switch to JS. Also auto-JSON decoders.
I really appreciate you sharing your experiences, feelings, and continuing the discussing in the comments.
In a way, it does appeal to me to have an efficient way to close out issues that are redundant, given that a link to the existing issue is given and the original user is given a friendly (could be canned) message explaining the duplication, and to redirect the conversation - but affirm they were heard. This could be worded like:
As long as it isn't just marked as a dupe like SO posts >.> - It seems like evan is inerested in redirection over closing - although those examples are just redirecting the "help me with X" type of questions to the discourse.
I'm going to speculate a little here, but one of things I hear a lot from my peers (18-30 age range) is this idea of emotional and social currency. That it can be draining to engage with people who disagree with them, and even more so if it is a harsh disagreement.
I think my peers have taken this to justify convenient disengagement. It's a trend that I see happening a lot in establishing small echo chambers that results in a community that can turn nasty fast.
This is very disheartening to me. I understand differing energy levels, and how social anxiety can play into that, but if people aren't exposing themselves to new ideas and people that make them uncomfortable, that is a bad thing.
I'm not saying that there are not times to disengage, but I'd rather err on the side of letting people talk too much than closing and locking too much. It's definitely a line/spectrum deal.
I agree with everything you mentioned. It seems harmless to me to let people vent a little. Even if it is just misunderstanding how to use the tools and you've heard it 1000 times and you just link them to another thread. Because sometimes people have legitimate issues. But you will never know if you just shut them down because they mentioned some keyword like "native". I don't often do this, but storytime. (Skip the next paragraph if you don't feel like a story.)
I used to play a game called EverQuest2. The mods on the EQ2 official forums were known to be heavy handed. One example was people requesting the Beastlord class which was a favorite in EQ1. They got so tired of redirecting and eventually locking posts which requested this class that they added it to the banned word filter. Eventually they even started banning people for referencing it at all. The community was essentially being told 1) "shut up" and 2) "we don't care." Because the community's voice was squelched (in general, not just about that), another site rose to prominence called EQ2Flames. Except it was like the darkest corners of reddit (before reddit existed). Yet, it was the only place players could go to speak freely (just before being ridiculed). Eventually, the official forums were mostly dead, and even the game devs had EQ2Flames accounts. (And eventually they even added the beastlord to the game.) But in the mean time it was a lot of unnecessary drama and stress on everyone. And for what? To enforce arbitrary rules?
I think we get so focused on marching orders (actual or perceived) that sometimes we don't consider how our actions play out in the bigger-picture human context. This Sandi Metz video really opened my eyes to some interesting things in that regard. One of the experiments she mentions was also the subject of a 2015 movie called Experimenter. It is also a fascinating watch.
I've ordered a book (the most freshest, released on 22th. August 2018). But now it's not actual at all. Very sad.
I liked your article, sorry to hear about your difficulties.
I also loved elm, but switched away because of exactly the issues you mention: native calls not being supported. I'm a person who wants to experiment and monkey patch, and while I got a solution using ports working it was extremely painful.
So I switched... to rust. github.com/vitiral/artifact is my project and it has both the front and back end written in rust+yew, which allows sharing of types and (eventually...) extremely high performance.
Is rust webdev ready for production use yet? ... probably not. WASM itself (which you should probably be compiling for) is only supported on the latest browsers -- and I'm sure there are lots of features missing. But if you were using Elm before, you might like rust+yew.
You summed up how I feel - I moved to Mint - mint-lang.com
The comparison to using native in core I feel is quite a fair one. If native is so egregious, why don't the core packages also use ports? Elm's design could totally include a system port, and it could use an API like what Elm users are told to use. (Send Value out of the port and decode its operation and data in JS, and likewise when it comes back into Elm.) Then, aside from what needs to be compiled in Haskell, core packages would not have to use the evil native code either. Win-win, right?
No. The reason is because such a thing is impractical for many core use cases, even if possible. And being that Elm's existing API doesn't even come close to covering all web capabilities, some of the ones that we ordinary Elm users face in our apps are also impractical to do over ports. I've seen several use cases mentioned, such as web sockets, or using popular JS libraries which do not work well with the asynchronous nature of ports. But I'll give my specific use case as an example. The next paragraph is mostly copied from another thread under this post.
The primary thing Elm fails to do for us right now is type-based JSON de/serialization. Elm's built-in encoding and decoding is great for fuzzy APIs. However, that is not a situation we find ourselves in. In 99+% of our internal API types, the server and client types line up exactly 1-to-1. (There is only 1 case where we need to use a decoder.) We adjust these types regularly as we implement new or update existing features. So for us, using encoders and decoders creates hundreds of lines of redundant/difficult code that we have to touch regularly. So maintaining co/decs has only downsides, and there is no non-native way to handle this in Elm. Instead, we define a port (never used), and call the 20 lines of referentially transparent native code to extract the auto-generated encoder or decoder from the port.
My case may be different from most other users, so I don't expect Elm to have this feature right now. Nor a lot of others that people might need. But I would generally expect users are able to reasonably cover their needs. And for that reason native usage in app code compares fairly to native in core code... because in both, it is otherwise impractical (even if still possible) to accomplish some use cases without it. At least for now.
Its eventual removal seems like a good idea. But its removal at this time seems whimsical or even punitive based on Evan's post. This kind of decision raises the risk meter for us on using Elm going forward. Because now we're wondering how much more divergent from today's practical realities subsequent releases will get.
Props to the OP, I would not have kept my cool replying to all these comments. Despite the disagreement of some of the replies, they seem to embody the described behaviour 😞 Eg not a single reply about how they are trying to listen to the users, just more "no, you're wrong, shush"
I am so thankful to Kasey for helping me avoid investment into eventual disappointment.
I started Elm over the weekend and was already singing its praise to my colleagues seeing how easy and quick it was to be productive in it. I am not interested in being a part of this community or this technology that wants to treat users as infants incapable of deciding for themselves. Everything Kasey said about the Elm contributors is in full display on this single post.
Elm is not the only fish in the pond. Thanks but no thanks.
Elm is the product of Evan. It is Open Source, yes.
But it's still his product. :)
When apple decided to remove CD players from their laptops, they just did.
Community contribution and even usage of the "Elm product" has no strings attached.
I think this is better in the long run. It's better for Elm to have ownership (Evan).
When too many people decide on product features, we get Outlook like products.
This doesn't mean you cannot express your opinion about things. But they're just that, opinions and discussions.
Analogies are only worth so much, but please note that Apple still sells optical drives. They didn't leave the optical market out in the cold. Another example: Apple stubbornly refused to accept right click as a mouse feature for many years, because a single click was more elegant, and their elegant design did not "need" right click. Totally their call as it's their product. But people just used other mice or means of right-click until they came around to what the market wanted.
It means exactly that on Elm’s forums, which is symptomatic of what I tried to convey in the post. (I did not post on reddit, link was shared by another.)
Otherwise what you said is on point. It will also be better for us to have less risk with unstable decisions. But we like Elm so much, that this is all very unfortunate.
What is SCCE?
I made a typo. The correct acronym is SSCCE. Meaning Short, Self-Contained, Correct Example.
I agree that elm core developers have good intentions, but too often too strict.
I had a similar experience with elm format and cookie support.