Elm - General Discussion, Blog Posts, Wiki

I’m guessing a lot of us will be interested in using Elm with Phoenix, so starting this as a general discussion thread with this first post as a Wiki - please feel free to edit/update it.

Here are some links to get us started:

Tutorials, guides, learning material


Example Apps




Blog Posts

Talks/conference vids


Not related to Phoenix but this is an interesting article about the elmification of Swift.


For which kind of apps do you see elm? Phoenix is very fast compared to other languages like php. So it almost feels realtime when you click on somethng.

For example a crm like app. Things like the number of emails, tasks can be done using channels. The rest with server side rendering.

Don´t get me wrong. I think elm has nice things, like time-traveling, syntax. But i wonder if the extra time is spend well. When new developers get on the team they first have to learn elm. And at the end it´s about money / customers. So i don´t the the huge gain using elm compared to the time we would have to invest in the language. Besides that i´m also not sure if languages like elm are here to stay.


Good point Max, Phoenix certainly is fast :003:

I would use Elm for single page apps (SPAs) / those that would otherwise require a heavy dose of JS.

One of the main benefits is reactive programming, from Learning FP the hard way: Experiences on the Elm language:

A good friend of mine convinced me about the benefits of Reactive Programming not that long ago. It almost feels wrong not to write Functional Reactive Programming – apparently the functional methodology lends itself magnificently to complement reactive programming. How, I did not know. So I decided to learn this stuff.

From The introduction to Reactive Programming you’ve been missing

"What is Reactive Programming?"

There are plenty of bad explanations and definitions out there on the internet. Wikipedia is too generic and theoretical as usual. Stackoverflow’s canonical answer is obviously not suitable for newcomers. Reactive Manifesto sounds like the kind of thing you show to your project manager or the businessmen at your company. Microsoft’s Rx terminology “Rx = Observables + LINQ + Schedulers” is so heavy and Microsoftish that most of us are left confused. Terms like “reactive” and “propagation of change” don’t convey anything specifically different to what your typical MV* and favorite language already does. Of course my framework views react to the models. Of course change is propagated. If it wouldn’t, nothing would be rendered.

So let’s cut the bullshit.

Reactive programming is programming with asynchronous data streams.

In a way, this isn’t anything new. Event buses or your typical click events are really an asynchronous event stream, on which you can observe and do some side effects. Reactive is that idea on steroids. You are able to create data streams of anything, not just from click and hover events. Streams are cheap and ubiquitous, anything can be a stream: variables, user inputs, properties, caches, data structures, etc. For example, imagine your Twitter feed would be a data stream in the same fashion that click events are. You can listen to that stream and react accordingly.

On top of that, you are given an amazing toolbox of functions to combine, create and filter any of those streams. That’s where the “functional” magic kicks in. A stream can be used as an input to another one. Even multiple streams can be used as inputs to another stream. You can merge two streams. You can filter a stream to get another one that has only those events you are interested in. You can map data values from one stream to another new one.

Hopefully @kofno and others will chime in too.


These tweets just hit my feed…

1 Like

I think that ELM backend agnostic, as same Phoenix can be as REST/websocket source so also can be fronted agnostic. More interesting integration is when you have backend and fronted written in the same language. Than you can do more couple integration something like OM next

For facebook fans there is also graphql for elxir graphql-elixir implementation.


I’ve worked on several applications where a synchronous round trip to a server (even a fast one) is unacceptable.

Highly interactive UI/UX

A UI that changes and reacts to user input “on the fly”. Often, these are designs where a full page refresh (even a fast one) is jarring and undesirable.

The “Mashup”

Also, the “I don’t control all the servers” use case.

I work on a site right now that combines video, slide content, webrtc, web sockets, chat, etc. Many of these services are provided by third parties (Vimeo) for example. These components are presented together to create a unified UX. There is a high level of interactivity between components (for example, the video playing advances the slides).

This is the extreme example of the first bullet point. I have a user interface where a page refresh is unacceptable, but users still anticipate being able to interact with all the content.

Extreme latency connections

It doesn’t matter how fast your server is if your connection is slow (or non-existent).

This scenario is less common then it used to be, but there are still classes of applications that need to account for slow and dropped connections.

For example, public health workers that need to go into poorer regions to collect data on, say, disease outbreaks. Such an application may need to use local storage to cache the collected data, and perform syncs with the backend whenever it detects an available internet connection.

You could build such an app native, but if your workers are volunteers, it may be cost prohibitive to support all of their platforms with a native app. In such a scenario, a highly cached web app might be your best means of distribution.

If you can believe that any one of those scenarios is a legitimate case where having a fast server just isn’t good enough, then the case for Elm is easy: No runtime exceptions. No undefined is not a function. No surprises.


In our company we have to make sure the time and money on a project is spend well. If we develope in vanilla js changes can be made by us. If elm apps throw an error with chrome 99 in the future i´m not sure if we can fix elm core code ourselves.

How do you see the fact, that elm like many other languages are a one man show? What if for whatever reason elm isn´t developed any further?

1 Like

It’s really a two man show with contributors three and four dropping to under 20 commits. Elixir is far healthier in this regard. I think your concern is valid.

From a few videos I’ve seen it appears the elm folks know they haven’t done a good job at evangelizing their technology.


I’m not concerned about Elm development ceasing anytime soon. No Red Ink is all in on Elm and Evan. There’s a thriving community. And there’s definitely a taste in the JS world for building front-ends in a more reliable way then Vanilla JS allows.


I’m not concerned either - interest in Elm is huge.

Out of all the JS alternatives, three stand out the most:

  • Elm
  • ClojureScript
  • Opal (Ruby)

The latter two interest users of their parent languages most, and while Elm is obviously influenced by Haskel it doesn’t seem to be tied to the Haskel community like the others do.

There was talk on Lamda Days 2016 - Elixir and Elm – the perfect couple by Tomasz Kowal. Hope there will be video soon.


Just added - Master Elm to the Wiki - it is going to be a series on mastering Elm and looks pretty good.

I look forward to seeing the Elixir & Elm video too @mkunikow :023:


You can still run into this situation with the transpilers as well. Most (if not all) of the new frameworks are transpiling in some form: React, Angular 2, Ember, Aurelia are just a few examples. What if you run into a situation where there is a bug in the transpiling process?

Yes, you can write vanilla js in that situation, but you can do the same thing in elm and port to the vanilla js code. Babel is basically in the same situation. Even though guthub shows 196 contributors, if you look at the commits, Sebastian McKenzie is doing like 98% of the commits so the babel project is basically a one man show as well.

What I’m saying is that if you are concerned that Evan will stop working on Elm, then your concerned should extend to all transpilers. But I predict, that eventually everyone will be transpiling otherwise the web assembly project wouldn’t exist.


Just added this to the Wiki: Erlang Factory SF 2016 Keynote: Phoenix and Elm – Making the Web Functional, by Chris McCord & Evan Czaplicki :023:

Edit: Watched it now and I like that Evan said in the next month/release of Elm the Phoenix-Elm relationship is not going to be just great, but amazing! Can’t wait :slight_smile:


Added TodoMVC example with Elm to the wiki…


Nice little demo Elm app http://irh.github.io/circles/

1 Like

Native Phoenix channels in Elm

An implementation of Phoenix channels in Elm inspired by mgold’s elm-socketio.

The Chat example in the context of a Phoenix app can be found here https://github.com/svard/hello_phoenix.


Just found: http://www.elmcast.io