I haven’t followed Elm very actively for quite awhile. My workplace has a kiosk product where I, along with two others, did the entire front-end UI in Elm. Multiple screens, a full configuration interface and talking to a C# back-end. I think we’re on Elm 0.17 or Elm 0.18 still. At least at the time we shipped the first version, it was larger than any example app I’d seen and there weren’t a lot of non-toy applications or examples to compare against.

I certainly have overall positive feelings about it, with some frustrations (like any language really). I’ll say that the most stand-out thing about that code is that I can be off it for six months, come back to it and within an hour or so I’m back to comfortably knowing what’s going on.

I’d played around with functional languages before Elm; I’m a bit of a language nut. One thing that’s easy to forget is how intimidating the syntax can be to people who haven’t seen anything like it before.

I don’t know that I would do such a large project in Elm again though. Or at least, it’s not something I’d push for wider adoption within work; some has to do with factors like finding developers and fact it’s just really early days for the languages in the grand scheme of things. It needs more time to grow.

On the technical side, having subpages and doing the routing of messages can be really painful and I don’t really like the ‘huge flat data model’ approach. I abstracted the core routing boilerplate away by using a JavaScript templating library to make a boilerplate generator. You specify the screens you want and your main.elm gets generated from a template, with the appropriate message routing and handling for update and view calls and the structure of the top-level data model being generated for you into an Elm source file that actually gets compiled. it worked out for us, but I still feel like it’s working around a shortcoming of the language.