Why I'm Stepping Away from Elm

UPDATE: adding a sentence for clarity after feedback from someone: I don’t think the issue is kernel code. I think the issue is that the Web platform support is small currently, and there’s a large barrier for community contribution to it, and this causes hurt feelings on all sides, and those hurt feelings are legitimate on both sides.

I have found myself unexpectedly emotional at last week’s infamous article. I was angry at how unfair it was, upset by how some of my colleagues who didn’t have proper context parroted it’s points, but

I was also hurt by it.

I wanted to honestly express the complex emotions I’m feeling. It frequently feels like things like this go unheard or at least unacknowledged, and so hurt people, lacking any real outlet internal to the community, lash out in a public forum. I’m not trying to do that.

I made the same mistake that the author of the other article made: /I tried to contribute to the core libraries./

I’ve tried to be as good a citizen as I could in that pursuits, learning along the way and trying not to become jaded and angry.

Elm Explorations were supposed to help cover the browser APIs that we needed by enlisting domain experts who were willing to commit their time and expertise to designing great APIs that could make those APIs work. I thought, great, this is a place I can contribute.

And I thought it was a good match for the criteria laid out for this contribution: it was an important and often-requested browser api; it was a built-in set of APIs, not a third-party library; and I was a domain expert with a passion for it.

After over a year spent on it, after several years of working on it before the announcement, I was frustrated, but also I felt bad about myself. I felt stupid, I felt unvalued, I felt like these APIs which I cared deeply about were not considered important by the powers that be.

I also watched friends who had been able to make Elm-explorations rejoice as unbelievably cool abstractions were built on top of it by others, and I was very jealous.

A large number of Elm people, including core team members, helped me enormously in this pursuit, technically, procedurally, and emotionally. I deeply value the friendships I’ve made in this community.

At the end of the day, Evan is a strong gate-keeper in this community. I think I frustrated him with my communication style, which is often long letters like this. He has a million concerns on his mind and mine wasn’t his top priority, which is totally understandable.

The result was that it felt like I was constantly hitting my head on something hard and it slowly made me lose my passion for the project.

I know that discussions like this make Evan and the core team lose some of the passion they have for elm, despite all they’ve sacrificed for Elm. But the closed development process has also caused me to lose my passion for it, despite the time and energy and sense of self I’ve put into it.

Reading last week’s article brought those feelings back to the surface.

Elm is a slowly developed, closed-development language and framework. It’s tightly controlled, pure, and those are wonderful design goals that make it the thing we love.

That leads to some very real human distress in some people who are just trying to contribute. There are times when my frustration rose to the level of resentment for those decisions. I believe we can grow Elm incrementally, involve the community more, and get more of the underlying platform functionality accessible directly without abandoning what makes it great.

I was upset by a feeling that we were making technical arguments in response to someone who was feeling hurt, excluded and censored. And it often felt as if we were denying the validity of those feelings in defense of Elm.

I don’t think I’ve been a bad actor in this community, but I’ve sometimes felt the same way the author did. I think it’s a natural outgrowth of Elm’s development process, I think the feelings are valid, and I think we need to understand that those choices sometimes hurt people.

I think we should consider trying to achieve three goals as a community:

1.) Elm is unusually closed to extension and contribution, which offers numerous benefits, but this also causes great distress to some people who are trying in good faith to contribute. We should acknowledge those stressors and lament them, even if we don’t change them.

2.) It’s our responsibility to find ways to make them feel included, valued, and like they can make decent contributions that match their interests and expertise.

3.) We need to make people feel heard, here in the community.

If we can’t find ways to make all our passionate community members feel valued, included, and heard, the same “Why I’m Leaving Elm” chaos is going to occur over and over again.

Anyway, I’m not leaving Elm, but I am stepping away for a bit. I want to work on some cool backend stuff to try to make online conferences better, so I probably won’t be writing frontend for a while.

If you’re like me, and sometimes hurt and frustrated in this community, you’re not alone. It’s great that you want to contribute and it’s not you and it’s not them, it’s the system by which Elm is developed that makes you feel that way, even though the reason it’s so great it because it’s developed that way.


Despite having attempted very little contribution to Elm over the years, I can recognize those feelings too. I’ve mostly followed the language and community from the sidelines for a few years, until I started working professionally with Elm a year ago.

So I’ve seen a few of the turns that have been taken, and I can fully emphasize with the process the core team has settled on; I would probably have done something similar if it had been me in Evan’s position.

None the less, whenever I consider contributing to something related to Elm, I quickly get down hearted: what if I do it wrong, and I end placing extra work on someone who doesn’t want it? What if I step on someone unintentionally? Am I part of the problem?

I still have a hard time figuring out how to communicate in the Elm community, and my awkwardness in doing so often leads me to frustration. This then seeps into my communication, and thus a bad cycle is born, since I end frustrating others and myself when I try to express myself.

I feel for the core team, in how these discussions can whittle away at anyone’s sense of purpose and drive. But I too am not here to lash out, or demand a solution of some kind. Just giving space to emotions like these is important in itself.


I’m a bit lost here: I feel I can do anything with Elm. Yes, getting stuff published on the official repository is not always possible, but there’s always github. And if I don’t like Evan’s decisions, I can always fork.

Elm on purpose tries to do things differently. That’s the whole point.


You can see more here

So, few days ago, I’ve hit a runtime bug that’s logging Uncaught RangeError: Maximum call stack size exceeded in JS console. That bug is in the core/browser and has been given a solution description in Nov’19 (5 months ago). I would be happy to try/apply that fix, and make a PR, but the problem is, there is no HACKING.md that would help me do that. This is a very bad sign, in my opinion, since I am disincentivised from proposing a fix to a core library and/or compiler. It’s not a design change too, just a bugfix. I’m really puzzled why this is so, to be honest.


Thanks for this letter and thanks for all your work on what A/V can look like in Elm. I’ve enjoyed following your work for more than a year, and your videos from elm conferences are some of my favorites.

I hope the backend stuff is really cool, that you enjoy your time with it, and that this community grows towards one you’d be happy to engage with again.


Thank you, I just want to be clear that this community is one I 1000% would always be happy to engage with. This community is great and I deeply value my friendships here.

The combination of the current state of the framework, which isn’t finished, combined with the closed development process, and the never-ending cycle of hurt feelings that that inherently causes on both sides is what is stressing me out.


I’ve felt similarly. I was 100% in it a few years back. I stepped away and did some work in PureScript that was difficult. I came back to Elm after some time off from programming and not much had changed; I still had the same issues I raised in a retrospective in 2016 – amplified by the lack of Web Platform support and reasonable synchronous FFI moving to 0.19. There’s still security and usability bugs in the core from ages ago – many with PRs with immediate fixes for people – that have mostly been neglect. After the way my thread was shut down asking about localization without room for rebuttal, I pretty much gave up on the community and any further contributions seeing the stewardship’s actions time and time again.

Reading last weeks post made me realize how much people are afraid to mince words with frustrations for fear of community backlash and how you’ll never get anointed to the status of ‘chosen one’ where your packages can have the Kernel code or get the priority sorting in the package search. There’s a lot of careful speech about wanting to sing the praises. Even still, in the way that some people recommend Python for beginners to then graduate to something with types, I feel Elm’s current space is to learn functional programming techniques but not to build production systems. I’ve had to make too many hacks – including things like using the build tool to rewrite Kernel code with bugs in it (it’s stable though since the libraries rarely get updated :jab:). And more issues arise as Elm cannot extend custom element nodes with is (opened a year ago), despite custom elements being praised as a solution.

I’m pretty much checked out the community too and I think it important to let people know that their frustrations can be empathized with. I’m completely spent right now after having to move some code out to a Worker for performance reasons processing on the main thread it caused the UI to hang in large workloads and hooking up the port was an Italian lunch of spaghetti mess trying to manage state/caches in two place to coordinate (and you can’t just use a Web Worker from your Elm codebase). This is likely going to include the work code base as we’ve just had too many issue that can’t be solved within Elm. Following Evan’s advice, I’ll be looking to migrate more things to PureScript.


The custom elements issue, while frustrating, isn’t totally unreasonable. Safari has closed tickets, saying they won’t implement that feature. The only way to currently extend built-in elements is by means of pollyfills, but that doesn’t mean it’s a good approach. I personally feel like this is an excellent example of why Elm shouldn’t implement something just because there’s a quick fix.


Just my two cents:
I think Elm is just missing a central way of discussing, specifying and developing the language. I think I read some day that Evan sees the way python was/is developed as an ideal.

So I would propose to create the same structure as python has:
Python Enhancement Proposals and a Developer Guide for Contributers.
All that will take time, but I think it would be of great value for elm to grow up.

See: https://www.python.org/dev/peps/
And: https://www.python.org/dev/


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.