Roadmap for Elm

Hi, I’m curious if there is any kind of Roadmap for Elm. I’m pretty sure people would like to know what is being worked on and what we could potentially expect in Elm in the upcoming months/years.

A lot of projects out there have roadmaps (TypeScript, Ember, React, Rust) and regularly post a blog posts with updates what has been improved. Even though Roadmaps might change, they provide transparency and build (to a certain degree) trust.

I’m sure that folks around Elm work hard to improve all kinds of aspects of Elm, but without properly communicating what is being worked on, it is easy to feel like there is no progress at all.


I’m going to quote a comment made by Richard a few years ago on a similar question:

I think Elm doesn’t have a concrete roadmap because Evan adapts his plans based on what he learns from the community. If you ask him “what will you be working on 6 months from now?” the answer will probably be “depends on what happens in the next 6 months.” He does post periodic status updates on the elm-dev mailing list, if you’re wondering what he’s working on and how it’s going.

Replace “elm-dev mailing list” with here, and Slack.

Honestly it’s a question that is asked regularly. We had this transparency in the past. It wasn’t productive.


Go on… at least give us some ideas of likely priorities beyond 0.19.1.

Runtime performance: Improving the Elm compiler output ?
Server side rendering?
Expanding web API support, websockets etc.?


I don’t think server side rendering should be solved by Elm community, since puppeteer and others tools can already solve it. I am almost sure after 19.1 the focus will be in expanding web API support.


You can always sneak a peek on GitHub at least :wink:

1 Like

What about rehydration? But I can see there is a way of doing that if you serialize the model and send that over to the client too.


How do you see this view in GitHub? I’m a fan of occasionally checking out commits to see what’s changing (maybe learn a little along the way) and this looks like a nice way to see where change is happening at a glance.

It’s on Evan’s profile:

1 Like

I was always quite skeptical about SSR. What if you need access to window size or other data that is only available in the user’s browser and not on the server? Like if you make your UI responsive by checking window size in the view instead of using media queries. That’s what you do with elm-ui for example.

And why do we need it at all? Google can index dynamically generated content nowadays, and I think performance benefits from using SSR are not that noticeable.

1 Like

Unfortunately, as @rupert said, SSR is currently an issue with Elm because of rehydration. It was discussed in this thread.

One of the signs of healthy communities is that they communicate progress, what is being worked on and what has been done.

TypeScript roadmap is a great example. Even though it is simple, it communicates what will they try to tackle in the future and what has been done - that is also very important.

If the answer to “what is being worked on/has been done” is “find on your own” then we should improve on that. It is not very welcoming nor helpful.


But it will rank your site lower because of the time it takes for something significant to appear without SSR.
Wix improved their sites performance quite noticeablely with SSR:
Main benefit of SSR is performance thus user experience thus SEO, but also social network visibility as Facebook or Tweeter crawlers do not support JS, so you need plain HTML to have nice links previews.

Guys, you’re slipping of the topic of this discussion. Please create a dedicated one if you want to discuss SSR. Thank you for understanding.


Going back to the roadmap subject, there is this document:


That’s doesn’t look bad. In any case, it would deserve an update.


Relevant talk by Evan on the Hard Parts of Open Source

1 Like

To get a sense of the progress of the Elm community and project I…

And occasionally stumble across this document:

I recognize the fact that we have a small close knit community growing steadily over the years. This slow steady growth is ok with me. The future is uncertain. Here is an excerpt from one of my favorite articles on the internet,

Two practical notes. The first is in the arena of time management. I really like what I call logarithmic time planning , in which events that are close at hand are scheduled with finer resolution than events that are far off. For example, things that happen tomorrow should be scheduled down to the minute, things that happen next week should be scheduled down to the hour, and things that happen next year should be scheduled down to the day. Why do all calendar programs force you to pick the exact minute something happens when you are trying to schedule it a year out? I just use a word processor to schedule all my events, tasks, and commitments, with resolution fading away the farther I look into the future. (It would be nice, though, to have a software tool that would gently help you make the schedule higher-resolution as time passes…)



1 Like

When people say ‘web apis’ do they mean localStorage and websockets?

List of web APIs here: