Ellie, the Elm Live Editor, lets you use the Elm platform in your browser. I released it in February of 2017 as a way to make it easier for the Elm community to share code. Despite it's popularity within the still small and growing Elm community it remains a side project so I need to be judicious about how I spend my time working on it. Its popularity also portends its importance to the community and I believe that comes with a responsibility to develop it in a way that meets the needs of the community.

Ellie isn't just a tool for sharing Elm code; it's becoming a centerpiece for online, interactive discussion of Elm. I get a push notification whenever someone shares an Ellie link in the Elm Slack. A typical weekday includes at least one conversation where participants share Ellie links back-and-forth to help someone arrive at a better understanding of an Elm concept. At Oslo Elm Day this year I claimed that in order to write good software we need to understand how people use it. Several months later at Elm Conf US I shared that conclusion about Ellie specifically: Ellie enables conversations about Elm.

This discovered identity guides Ellie's mission and will inform all of my decisions about features and UX going forward. This led to the planned addition of real-time collaboration. It may also lead to the addition of more ways to personalize the Ellie UI, including the addition of more familiar editor keymaps like Emacs and a light color theme. Beyond positive additions, though, it also informs the decision not to include certain features even in the face of user requests.

Of course I'm talking about including multiple files in an Ellie project. This is among the most requested features. But, like Elm itself, the development of Ellie is not driven by direct democracy. I don't believe that allowing the inclusion of multiple files meets the criterion of enabling better conversations about Elm online.

Here's why: if you ask me a question about a specific concept under a broad topic, you probably won't appreciate it if I send you a link to a 4000 word Medium post. That would end the conversation! I want to respond with brevity so that you can consider what I said and build on it so we can keep moving. A chat application is a much better analogy for understanding Ellie's primary use case. In both cases you can type as much as you want, but the medium encourages you to be brief because you are in a dialogue.

I've heard a counterpoint that some concepts can't even be explained briefly in Ellie because they depend on having multiple files. Examples include the Elm module system itself and opaque types. My response to this is is just that the number of concepts in this category is pretty small and I'd rather Ellie be unusable in this small set of cases than split the focus of Ellie between concise conversation and large projects, making it worse at both.

Perhaps someone else will build software that allows people to build and run large Elm examples online. It may even one day be a project related to Ellie, just as CodePen introduced CodePen Projects. However, the core focus of Ellie is conversation and optimizing for that is more important to me than making it a catchall for every code-sharing need.