Growing a language’s ecosystem: Elm, a case study


In this blog post, we’re going to explore what it takes to grow the ecosystem of a language. An ecosystem can be considered a combination of tooling, packages, and documentation. In particular, we’re going to look at approaches for helping a community grow an ecosystem without needing a single person to do everything. We’ll explore a range of packages and tools that exist in the Elm ecosystem, and discuss briefly how I helped them come about.

Every package and tool in this list is awesome and so are the authors, and there are many many more examples just like them out there, these were the ones that fit this post the best. We’ll mainly look at packages and tools that I had only helped by a small amount. Perhaps there will be another on those I helped more with, but the point of this blog post is to examine how little you need to do personally to go a long way.

Why not do it all yourself?

No one person has all the time in the world. You might be able to keep on top of one or two projects, but the more projects you have, the less attention you can give to each. A healthy ecosystem contains well designed packages that have had a lot of thought put into them.

In the world of academia, this work is usually split over a research group. Each individual researcher might have a particular topic or subsection of work they’re looking into, and each week, they’ll meet just to chat about how it’s going. There’s usually a mentor who leads the sessions, but that’s not always the case. The role of the mentor is to be able to identify what resources people need, or who can help with certain problems. The basic idea is that the mentor can get more work done by helping 6 other people to do work rather than do it themselves. The role of the mentor isn’t to know more about each individual topic, but rather to have a good understanding of the area as a whole.

In the world of open source, this also applies. One of the great things about open source is community — and in the rest of this blog post, we’ll examine ways you can help out the community in the role of a mentor.

Unblocking pull requests: elm-native-ui

Elm Native UI is a project intended to provide a way to work with React Native via Elm. Ossi created the project to explore the world of making Elm work for mobile applications. When it was first created, the idea was to use a alternate form of Program as opposed to a pure JS or Html version. This would use ReactNative views instead of Html, while running Elm normally on a JS thread.

There is a limitation on the types that were a valid main function in Elm, and the type used by elm-native-ui would not work with the Elm compiler. Ossi had spoken with Evan about this, and I met up with Ossi in Stockholm at a meetup. He explained to me what Evan had said needed to be changed, and when I got home, I submitted the PR to enable using elm-make in the way needed. The whole PR was roughly two lines, if that. elm-native-ui also used some Elm kernel code in order to render the ReactNative components. I had also created a tool for trying out kernel code locally.

To this day, I’ve run a ReactNative app maybe 4 or 5 times. I have a general idea of how it works, but I’ve never used it extensively. Ossi did however, and the important part of elm-native-ui is all about ReactNative.

Take away

It’s not important for _you_ to fully understand the project nor the tool. If someone knows what they need help with, then you can take care of that in order to let them focus on the important part. If it’s not a pivotal part of their application, then a PR is just as good as understanding.

Prior experience: elm-array-exploration

elm-array-exploration is an alternate library by Robin to Elm’s core Array implementation. For a while, there had been numerous issues with the Array implementation in Elm’s core package, something I had been looking into for a while. Robin had previously been working on implementing all sorts of alternate data structures in Elm.

When Robin was implementing this project, we discussed a lot on the elm-dev channel on Slack. From my previous experiments looking into fixing the Array implementation, I had decided the ideal structure is to have a pure Elm implementation of the complex immutable-array data structure, and use a low-level wrapper around a fixed-size JS array implementation. This would allow for code to be fast and maintainable at the same time. A pure Elm implementation would be too slow and complex, a pure JS implementation is what we had originally.

This advice, along with a code-review, helped elm-array-exploration become the recommended Array implementation for use with Elm. Robin did all the hard work — all I did along the way was have a conversation with them and provide some helpful info based on previous experiments.

Take away

If someone starts a project in an area you have previous started a similar project, sometimes the best way to be productive is to help them achieve the shared goal. Don’t make them do things your way, but discuss and explain the choices you made previously. If they’re in a better position to finish the work, help them do that!

In-depth knowledge: ellie

Ellie is an application like js-bin, designed for sharing Elm code snippets with a preview of the compiled version. Luke Westby created it with a co-worker, intending to help the community out as we needed some way of sharing snippets. Since then, it’s become the most popular way of showing off demos in the world of Elm.

Luke came onto the elm-dev channel and asked a bunch of questions. A couple of them were ones how elm-package works, as they wanted to only download packages once, and share them across every ellie-app, to save on disk space and bandwidth costs. Luckily, I have in depth knowledge of how elm-package works, due to various issues with it in the past. I was able to point them in the direction of package listings.

Once they had a good beta site, they invited us to try it out. I left a whole bunch of feedback, roughly around 20 different points or thoughts. Among the things I found, a couple of them were weird visual bugs.

Take away

Sometimes all you need to do to help is to answer questions or test something out. This can be more helpful than code sometimes — it’s faster to answer the question of someone in the middle of a context than it is to fully bring you in to the context.

Context-aware pull requests: elm-css

Elm-css is a way of writing CSS in pure Elm. It lets you use Elm functions in order to construct CSS for your web apps. Richard Feldman came up with the idea and implemented a version of it for a lightning talk. The idea’s gone from being a prototype into something that is used in production by multiple Elm web apps.

When I met Richard at the ReactiveConf that year and they told me about it, the original demo was just text output of CSS. He’d managed to get Elm-CSS up with an API, but it was just producing a string. Having played with Elm’s virtual-dom a lot at the time, I knew it’d be trivial to implement. I actually created this tag of style : String -> Attribute, which you can see here. That tiny bit of help helped turn the live demo into something that people could really see visually.

Take away

A small amount of help can have a big impact; the context in which you give help is important. If someone is working on a demo, think about what will aid their presentation. If someone is designing an API, think about the long term. The right help at the wrong time is the same as the wrong help.

Code reviews: elm-benchmark

elm-benchmark is a library by Brian Hicks for benchmarking Elm code. Who would’ve thought it? For a while, there was no “de-facto” way to benchmark individual functions in Elm, and elm-benchmark seeks to fix that problem. Before Brian was ready to publish, he came to the elm-dev channel to ask for a code review. I took a look through the code, and gave some recommendations. Nothing big, mostly just checking for possible causes of runtime errors in the kernel code it needed to use.

Take away

A code review in the world of open source is useful for a few things. In this case, we were vetting potentially harmful code in order to ensure it would function as expected. Reviewing code is also helpful to ensure someone else understands your code. When your library is published as a package, it has the potential to be consumed by thousands of users. If you disappear from the community, someone else will need to carry on the work of the library. In Elm, we have a group dedicated to just that.


The most of the help I give is just advice and knowledge. Being able to unblock people is vital to let them do what they’re amazing at. An ecosystem is healthy when many people are creating packages and tooling. People who are blocked are unable to share those tools.

Even the smallest code input can have a big impact. Don’t be afraid to read other people’s code when you need to, but also be aware of the times when the most effective thing you can do is to not read the code and instead simply answer questions.

You don’t need to have in depth knowledge of every project to help, you don’t even have to have used it before. You simply need to hear what people need, understand why they need that particular thing, and help them get it.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.