Elm-UI

About a year ago, I saw a post on /r/elm about elm-ui and watched the associated video. It was an interesting concept to completely diverge from CSS for the layout and style of your application and rely entirely on an abstraction layer that was built in the lexicon of a design system. The video is absolutely worth a watch, and the parts that got me were the “there are many ways to do anything in css” paired with “they dont all work together” and “your daily development experience is making thousands of micro-decisions and they will in the long run likely not play well together”.

At first glance, I over-associated the design system talk with elm-ui. To me it was a way to build a design in Elm-UI quickly. Basically using Elm-UI as a DSL for making prototype style designs. I could see massive benefits in that; I could sit down with a designer and buildout the application rapidly using their language. I didn’t consider it for building final elm applications at the time as I felt the ecosystem around CSS, SASS, preprocessors, postprocessors and rendering optimization was too advanced to replace.

Fast forward to the beginning of this year, I was building an embedded project into our marketing teams’ wordpress site. It had a lot of filtering logic and used elm-visualization to get around paying for Highcharts or a Tableau license for all of our different use cases. The nature of the wordpress injection, we wanted to keep as much of the code out of wordpress and in VCS. So we built an Elm Browser.element app that we served on S3 + Cloudfront and just put the script tag and the target element on the wordpress site. To get the styles I needed for that application, I used elm-css. This namespaced all of our styles in such a way that I didnt need to put a separate stylesheet into the wordpress site and I didnt need to worry about colliding with existing styles.

Going through that application, I felt elm-css was very verbose and the injection of a <style> tag was ok but not ideal. It worked very well in the particular case I needed for it. I really enjoyed the type safety in elm-css and keeping more of the project in elm was definately a good thing.

In the elm-css docs, on the first line, Richard Feldman gives a shoutout to elm-ui:

elm-css lets you define CSS in Elm. (For an Elm styling system that is a complete departure from CSS, check out Elm-UI.)

In the post mortem of the project, I put an action item to try elm-ui again, since elm-css was more verbose than we would have liked, and it wasnt very clear how to organize that code. Do we keep the styles in the same file as the view? Do we create an entirely separate elm application tree for just the styles like we would with SASS? The benefits over using native Html.Attribute.style for inline styles are marginal and there is about the same level of verboseness.

So I started digging in. Luckily for me, being Philadelphia based, Richard Feldman himself runs the Elm Philly Meetup, and there was a presentation on Elm-UI. I brought my designer buddy to come and check out this “Design DSL” and he fell in love with it. I still wasnt convinced we could do all we would need to do in it for most of our projects but I was determined to give it a fair shot.

Fast forward to a week or so ago. Same design coworker was dealing with a problem an upwork contractor had made in building out a one-off web application that was meant to help our customers get a feel for where they are in their market and who they can partner with. They were 11 weeks into a 2 week project, and things were not improving. My design buddy asks for some help getting the wordpress project running locally so he can at least start hacking at it to try and get something salvageable out of it.

I see the designs and it is a relatively simple 2-3 page application with some modals and basic search and filter capabilities. I do my best to get him working, despite my disdain for wordpress, and figure if i have final desings for this project, I have my opportunity to try out elm-ui.

7 hours later, I finished. It took me a little under a workday to learn elm-ui, model the relatively simple application, and build out to pixel perfect accuracy the site. The DSL is so intuitive, and it seriously has me reconsidering every elm projects with non-trivial styles. There is only one correct way to layout things and it is all typesafe. It ends up being way less verbose then elm-css, and in some cases lese verbose then using a CSS design system. Granted you lose the DRY-ness of having reusable components, but the speed and type saftey of laying-out your application in a canonical, type-safe way blew me away. Whats better, I only have to look in 1 place to figure out what I need to change for a visual update. No finding the class name, then figuring out what SASS lines are affecting that element. No SASS organization mess. I literally handed over the views code to our designer and he made changes (and since it was only view code, I knew it couldnt break the application).

Many parts of elm encourage organic problem solving and growth instead of trying to fit a problem into an existing pattern. This is echoed very loudly in Evan’s Life of a File. I feel that elm-ui extends this to the entire domain of a frontend application by allowing the rapid development of UI’s without having to fit them directly into a component systen.

So if you are bounching back and forth between css frameworks or trying out various strategies for styling in elm, I would highly recommend giving elm-ui a shot.