The State of JS^H^HElm

The new State of JavaScript has a couple of things to say about Elm. Still the best of the rest, but how can it remain relevant?


I may be unusual here, I’m not sure, but I don’t feel super concerned about numbers like this. I like using Elm, and it seems like a fair number of other people do, too, and I don’t feel a strong need to have the community get really big. I would like it to be more diverse, but that’s a separate conversation.

In general, I’m happy for new people to use Elm, but it doesn’t feel alarming to me that some people don’t feel like it. I still like it just fine.


Agreed, for the most part. The language is fantastic, the community is fine. It doesn’t need to be popular to be good.

1 Like

Evan has made bold and controversial decisions such as restricting kernel code, which makes Elm more unpopular, but makes me love Elm. It’s still good to grow the community and introduce more people to Elm, though.


However Job postings for Elm in Europe are rather low. I guess it comes down to personal preference. Adoption is still important.


One thing to notice in this survey is that most people who answered are not interested in or never heard about functional programming alternatives to JS in general. :sheep: :sheep: :sheep:


Higher numbers are usually better: more potential for useful libraries and tools, maintainers for existing ones, articles, and so on.

Those 4111 people who “Heard of it > Would like to learn” are an opportunity.


(TL;DR: It is difficult to convince decision makers to use Elm; They don’t care about technology that much; There are things the community leaders can do; There are things that everyone can do)

It’s more complicated than personal preference. As a consultant and an employ in a consultancy, I need to sell the technology that will be using, and in my experience “Everyone is using it!” sells much better than “I really like” or “it has some significant technological advantages.”
I just had this same conversation again over a small project that will probably see very few developers in it’s existence: the fact the Elm is simpler and easier to learn (IMO) than Javascript or Typescript is difficult to argue for when there are tons of Javascript developers and packages out there, but only a few Elm developers.
And then Evan made decisions that are making it even more difficult to sell. A language which doesn’t have fully open and transparent development cycle, with one central developer, and being considered by its own community as experimental do not spark confidence in the people who need to approve the decision to use a technology.
Since I would like to use Elm in my work in the future, I need to sell it to decision makers who are not programmers (or worse, are no longer programmers). Some of the things that would help me:

  • A large and hyped community
  • Endorsement from “Big Players”
  • Extremely good and slightly over selling education program (“Learn Elm in 3 Hours” kinda stuff)
  • b. because I’m also working in academia, an education program aimed for complete beginners, similar to what Arduino or Unity3D are doing.
  • A clear, long-term roadmap, not just for the language but also to its leadership. How and when features are added and deprecated? How and when people become core developers?
  • Support for emerging (or already emerged) technologies such as cross-platform á la React-Native, AR, VR, etc.

I think that Elm is on the right track on most things, but there’s still a long way to go. Remember that Python needed 20 years to graduate from this weird-academic language to a programming language that dominates the ML field. Erlang has a similar story.

I do have some operative suggestions to the community:

  • Workshops for complete beginners modelled after Django Girls can help us both diversify the community and introduce beginners before they get hooked-up by JavaScript.
  • I’ve heard that them youngsters :older_man: are programming on Twitch and watch videos of people live program, are there Elm streamers? Seems like a powerful way to both teach and to show the strengths of Elm, its compiler and its community.
  • Talk about Elm in meetups and conferences that are not about Elm. Better yet, show, don’t tell. Elm is perfect for doing live programming demo because the compilation errors are our friends. I’ve tried it once, and it was OK but I should have used a simpler example. You can also bring people on stage to show them how the compiler can teach them.
  • If you’re in academia, maybe try and teach an Elm based course? I don’t know who you’ll need to convince.
  • Maybe create resources for non-developers? Like, Elm for web designers, for children, for pensioners who want a website.

Hell, that came out to be very long, and not addressed just to you. To summarise: I think Elm is awesome and I would like to use it more, but I am not the one making the shots. We can be awesome and popular enough to make the on-boarding of managers easier.


Your contribution is actually very precise, true and I couldn’t have said it any better. Broad adoption is key for success. Python proved this. Thank you for this well expressed and valuable input !

1 Like

For what it’s worth, I did start streaming some Elm late last year but had to take a break for family reasons. I stream @wolfadex and I know there are others who stream Elm sometimes such as @avh4 and @klazuka44. I know there are others too but I don’t follow them on Twitch.

I know @lucamug has been posting for a while now about Elm at Rakuten, such as the one they just posted on the 24th Elm at Rakuten - DEV Community.

I know there are some schools that use Elm as their language of choice for teaching students programming, though I’m having difficulty finding which ones. Elm does tend to be a hard word to search for since it brings up furniture, trees, and other acronyms. As far as things like “Learn Elm in 3 hours”, that could be nice but it’s also heavily dominated by deceit IMO. For example there’s a things going around right now of “Learn ___ in 30 min” which started with a Rust blog post. That blog posts is actually a 60 min read per its own subtitle, so already we’re being mislead. Additionally it only covers a small portion of Rust. By comparison, the entirety of the Elm official guide can be read in about 3 hours. I’m not aware of any other language, except maybe Zig, which can come close to that. JS alone would probably take days to read through.

As far as the future of Elm, maybe we can get a tiny bit of insight during However I’d argue that this is misguided. How many people does anyone here know on the ECMAScript committee? How many people here are contributing in any form to ECMAScript or in some regular period check the proposals? How many people say “I can’t use JS because they declined proposal X” or “I can’t use JS because I don’t know the features of V8, SpiderMonkey, or JavaScriptCode”? I know very, very few people who even work at that level let alone know what’s going on.

I’m all for giving critiques where they’re deserved, and maybe I’m way off base here, but I don’t see people applying the same critiques to all of the languages they use. A lot of the comparisons are Elm to React or similar, where it should be Elm to JavaScript and elm-ui to React. I’d bet you could get a roadmap and such from elm-ui, as well as contribute and do everything else that people are requesting.

Also, something like Django Girls would be amazing. I don’t think it’d be appropriate for someone like me to lead that effort. Totally happy to contribute, but there’s a huge difference between a woman leading something like Elm Girls and a man leading it.

1 Like

I kinda feel like these are the wrong ways to sell something, though maybe I’m wrong? I wouldn’t sell Elm as a technological advantage but a social and financial one. I.e. Elm isn’t inherently more powerful than JS or PureScript or ClojureScript. What it does have is an excellent story around maintenance, on-boarding, payload delivered to the end user, and bugs produced. If I’m shipping fewer bugs, I’m saving by boss money by not having to go back and fix things. If I’m shipping a smaller payload I’m saving my end user time/money. If maintenance is easier, then it takes me less time to add features or fix the few existing bugs which saves my employer money. If it takes less time to on-board, then I’m saving my employer money.

My employer doesn’t care if I like Elm more than JS. They don’t care if it’s fast (at least I’ve never actually encountered that). They don’t care if it’s cool. They want to know if they can ship their product today, and tomorrow, and next year. They want it to not run over budget. They want to be able to continue work if you leave, get hit by a bus (god forbid), or anything else happens. That last one might be a little more difficult to guarantee with Elm than JS.


I do agree with your analysis, but my experience (and as we know, experiences can vary quite a lot) was that bringing up these exact same points just weren’t enough. I’ve tried bringing up the less bugs and easier maintenance arguments, or even being faster to on-board, but I never managed to convince anyone, and I always got the same reply that “but everyone knows/uses JS”. I would like to have the tools to challenge this assumption, maybe if I read more stories on how people convinced their boss/client and on-boarded them on Elm?


You have good points, and I do agree with most of them. I am less involved with Elm nowadays than I was 2 years ago, so I take your criticism to heart.

I’m happy to hear that you stream and that are other streamers, and I hope that you’ll get the time to return to it. I wasn’t aware of @lucamug’s posts, I will read them and keep them in mind when the discussion around Elm comes again.

[…] I don’t see people applying the same critiques to all of the languages they use.

I argue that is a key point in the discussion. People do not apply the same critiques to all languages and frameworks (and I think that Elm the language and Elm the framework are a bit more complicated to separate than React and JavaScript, for example). Elm is coming up against the default, which JavaScript, and even though it has many significant advantages, as you pointed out in your other post, it is still judged differently than JavaScript or any of the leading frameworks. And when a decision maker makes a decision, Elm is put up against frameworks, not other languages, because the Elm language and TEA are very closely coupled, you can’t use one without the other.

I actually do follow features and occasionally contribute to EMCAScript (by commenting on proposals, nothing fancy) and I know other people who do that, and I suspect that one of them is actually on the committee although we never talked about it. I know that some of my colleagues do, also, and I know decisions makers that follow similar things in the technologies they use. Yes, only rarely it is actually an issue, but I believe it is a kind of assurance for decision makers.

I do think that there’s space to investigate how decision making regarding web technologies happens. It is outside my research area, but I will ask around. I want Elm to be as attractive to decision makers as it is to me and I just don’t know how to make it happen.

1 Like

If it helps in your research. At my previous employer I wasn’t able to convince my manager to let me use Elm, but I did manage to convince my CTO who overrode my manager. It was a small enough company that I had to present using Elm to the 8 top engineering people (CTO, couple managers, few of the most senior devs). This was about 6 months of work and also included building a prototype of our actual app in my spare time. I also wrote a 12 page proposal for it, without being asked to. I think, more than anything, my unprompted dedication to the project (not Elm) was what allowed Elm.

Another short anecdote. I now work at Square where Ember is the most common framework used. The reason it’s used is because the earliest devs chose to use SproutCore/Ember alpha. I think a lot of the reasons for a technology being popular/accepted are fear of change. Maybe only the devs willing to work at startups are the ones willing to try new things? And new things become popular because one of those startups becomes the next Google, Facebook, etc?


I’ve asked my partner what she thinks are the main considerations when adopting new technology from her perspective as an engineering manager and as a person who isn’t as excited as me from new technology. She listed the possible hiring pool as the most important consideration. For her, if a technology doesn’t have a larger community of potential people to hire, it is too risky. She also mentioned that the willingness of existing employees to learn a new technology also plays a role, and this willingness is usually fuelled by how valuable the technology is on the market.

I actually don’t think that startups, in general, are more adventurous than large companies. Of course there are a lot of startups and some of them are more willing to use newer and (hopefully) better tech, but I think that large companies have the resources to investigate new technologies. For example, the 2019 LambdaDays keynote Don Syme, said in his talk that Microsoft investigated F# by devoting two teams, approx. 15 devs, for two years, to develop the exact same product. For startup this would be a leap of faith, for Microsoft this is just research.


Quite a few times I’ve heard this brought up, and some of the counter arguments that I recall are:

  • Anyone familiar with FP can cross train into Elm and be productive in days - that includes most computer science graduates, since FP is a common module.
  • The smaller pool who stick with it tend to bring more enthusiasm and energy to the project.
  • There is a risk of “opportunity cost” in not taking this kind of risk - will your competitors do it and gain a technology advantage over you as a result?
  • Can give your company kudos - a cool place to work.
  • Experienced people will actively seek you out because they want to work in Elm.

There is also this: Learn Elm in Y Minutes

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