This year I was invited to speak to this wonderful little (300+ attendees!) pre-conference before the annual Strange Loop conference in St. Louis. I found lots of interesting food for thought in the other speakers’ talks, and I blissfully am still unaware of the predominant reception of my 20 minutes of fame, where I tried to show how “easy” it is to do nice animations in Elm using the CSS transitions engine available in modern browsers. Links to my talk are at the bottom of this post, but first off, here’s what I heard, learned and started to think about in the immediate aftermath of ElmConf:

The Future of Elm

Expanding Elm’s Acceptance in a React World

The panel Q&A at the end of the day was very interesting, judging by the significant number of votes for questions about how Elm can expand it’s reach “in companies”. I think there are several issues here that could be addressed, but I don’t work for a company that has a large programming staff, senior architect, etc. (at our company we just made the leap as a group–none of us had much Elm experience–to use Elm, and we are so happy with the results!) so I am pretty naive on the politics of platform selection in tech companies.

Evan Czaplicki (the creator of Elm) probably is not so naive, because it’s obvious he spends a lot of time understanding the questions that these employers or their employees bring to him about Elm. One significant bit that should go ka-ching in tech companies that I did hear over and over again at the conference (and it’s also my personal experience programming in Elm) is that Elm coders are extremely happy using the restrictions and conventions presented by Elm, getting help and satisfaction from the compiler, tracking down issues in the time-traveling debugger, acquiring new skills in functional, immutable programming and seeing quick reliable results and eagerly look forward to bug fixes and tricking the compiler into giving them the blessed “all clear” signal; as compared with the JavaScript world where “all clear” means now you know there are lots of other bugs lurking in your code ready to break things. When I did chime in about comparing Elm’s present-day uptake to that of Ruby on Rails from several years ago, I of course forgot to bring up the fact that there was this same feeling back then, of wow, I just have to follow the rules and this new expressive language (Ruby) and this framework (Rails) that seems to understand what I need, actually makes me happy to use it.

I know it’s not very Elm-y to go negative, but some of the anecdotes that were mentioned, about infighting in JavaScript shops over coding style, choice of frameworks, complex tooling and setup, etc sounded pretty dreadful. (“And then the whole team of 6 developers ended up quitting.”) I’m wondering if, as the number of companies that are making the switch to Elm increases, whether the main Elm website might use a few testimonials from respected names that could describe some of the contrasting pros and cons between Elm and JS, especially when it comes down to individual and team morale and productivity.

Elm Best Practices and Emerging Domain Solutions

I really liked the fact that Evan mentioned that a lot can be done to improve Elm without changing Elm itself; instead by listening carefully to long-time and newer users’ frets and misunderstandings, and responding with some important documentation and sample code. I think if there were an “Elm Foundation” (maybe there is) with a small, active board focused on PR, the biggest thing that could add more legitimacy to Elm might be an e-book series (or collection of Elm packages and sample applications) highlighting best practices in various problem domains that confront current JavaScript/React/Angular/etc. shops.

I did my own careful listening to the speakers who came before and after me, and it occurs to me that it would be wonderful to see articles, Elm Town interviews, videos, published modules, and example apps for some common problem domains that more than one speaker mentioned. These were the things I heard, and about which I don’t see a lot of published Elm work out there (yet):

Web Workers. One magic moment at the conference was when Luke Westby clicked the “make this repository public” button for his Ellie codebase. I look forward to poring over it to understand the architecture he developed for setting up Web Workers and managing compiler jobs on them. Seems like this is a very powerful paradigm that a lot of responsive Elm apps could take advantage of.

Avoiding duplication of state in the Elm model and another source of truth (either a JavaScript system connected via ports that must maintain state; or local key-value or IndexedDB storage, as in Murphy Randle’s journaling system; or a remote backend server somewhere, as Ossi Hahnihen described in a recent Elm Town interview). Both Jonas and Murphy mentioned the nightmare of keeping two sources of truth in sync. It seems like there is some consensus that Elm front-end applications are better off always pulling a complete clone of whatever state they need to present a user interface, and immediately saving any changes made to the model out to that other system. Some good rules of thumb for singe-page applications (or as Evan said, applications that load multiple pages) would help here. Richard Feldman’s elm-spa-example sample application gets to this also, as each page fetches its page-specific model when it loads.

Deciding on strategies for using ports. Murphy’s talk was great. Since ports seem to be in many Elm projects, it would be nice to have a summary article posted somewhere that describe the range of successful approaches used to communicate with the DOM and with JavaScript libraries. I think the bigger picture on ports might be a little more complicated than the one example Murphy had; there are probably a variety of use cases out there that might provide hints to developers when they have to work with the JavaScript world.

Handling touch events. After Jonas mentioned that he had to write some custom code to allow his maps to correctly interact with touch gestures on mobile devices, I poked around on Google and could not find a widely accepted touch event library in Elm. I don’t if there is consensus on one, or whether nice examples of mobile apps that correctly handle touches are out there. Or if not perhaps they should be created.

Accessibility built-in. I kept getting the feeling throughout the day that there was huge excitement in the room about Tessa Kelly’s Accessible HTML package. I would guess that just about every developer out there wants to, or has to, follow WCAG guidelines and make his or her product more accessible, and  I think the additive incremental nature of Tessa’s approach is the right one. (Don’t know how easy it is to make React-component-based sites accessible by comparison). I think it’s very tricky in Elm right now to advocate for a package that dictates all of your view code for you, but if we had an autocomplete or keyboard shortcut to paste in, say, a fully accessible tab panel layout (with comments), and then let the developer make modifications, that might help us get to a more accessible web, in Elm. Then repeat for other widgets! Maybe the future of Elm is when there is a slick IDE that can add chunks of your view with one or two keystrokes, and that you can customize for your company’s particular coding and UI standards. In the meantime, Tessa could probably write the book (maybe she is) covering best practices for the many, many common cases of making sections of your views WCAG- and ARIA-compliant and accessible.

A Self-Review

I think it’s important to reflect publicly on my first presentation at a technical conference. Perhaps because I ended up showing almost an entire Elm app, at least one attendee reported on Twitter of being scared about CSS transitions after hearing my talk. I suppose if I ever get a second chance at this kind of thing, I’ll learn to be politically and educationally more effective (as Richard Feldman eloquently described in “Teaching Elm to Beginners”). You have to lay the groundwork and motivate folks to get them to come along with something useful but perhaps a little strange, like CSS animations. But I do think I was able to implant one or two bits of Elm knowledge (and even, hopefully, some understanding) to some in attendance. I guess I can hope I was able to stir up a little curiosity in some of the conferees to learn more about how these animations work. And it was a terrific learning experience for me personally (talk about motivation…), so I thank Brian Hicks and Luke Westby, the organizers, again and again for giving me the opportunity.

Here’s the recording of the talk:

The source code for both the demo animations used in the talk and the slide deck is available from my GitHub account if you want to play around with those animations, and get links to other animation resources.

And here are the other, highly recommended talks from ElmConf. If you’re interested in the future of Elm, how to teach (and learn) Elm, how to add accessibility to your Elm site, how to add mapping capabilities to Elm, what the fashion industry may have to help us understand different styles of programming, and many other topics and philosophies, check out the complete ElmConf US 2017 playlist: