Elm-css and cache

I’ve started using elm-css but now it takes a little longer for the page to display in the browser. I guess this is because the js generated by elm-css generates the css classes each time, which is additional work compared to before. Can the css be generated and kept so that this is not an additional work every time the page displays in the browser?

Also, .css files could be cached by CloudFlare and the browser. Since there is no separate file now, is the advantage of caching lost or is it compensated in some other way?

The previous discussion in 2018 How to do CSS in elm? talks about performance, but are there any further updates on that front?

My page does have lots of nodes.


1 Like

Potentially a bit out of date, but some performance comparison was done on various options for CSS in Elm:

There may be a more up to date version of the above somewhere? stylish-elephants was a working name for elm-ui pre 1.0, and I think its performance was improved from the graphs in that link.

One thing I tend to do with elm-css is to use Css.Global and generate traditional CSS classes, rather than do it all inline. I only do inline for things that can change in the view function, and anything that is more static I use Css.Global for. This can help with performance.


Here are some more up-to-date results comparing Elm-UI on Elm 0.19.


Wow! This is really helpful. Thank you.

I’d also recommend looking into A newer, updated fork of elm-css as a newer, updated fork of rtfeldman/elm-css. Richard even briefly mentioned this fork in a recent episode of his podcast Software Unscripted.

Is there still a tool that will transform elm-css Css.Global into a plain .css file? So you can basically use it like a SASS compiler such as ‘compass’ but using Elm for a nicer functional programming experience whilst doing so? I know there was one but was removed from elm-css, but forked somewhere else?

1 Like

I would love to see the results of this fork on the benchmark. The phantom types improvement is promising from a performance perspective.

I had an idea for a pre-processing tool that could take elm-css code (including inline styles, not just global styles) and convert them to generated external CSS files, replacing the inline elm-css styles with CSS class names.

I discussed the idea in this Elm Radio episode at 1:09:21:

I have a very early start at a prototype here, but nothing substantial yet. If anyone wants to work on it I’d be happy to give guidance on it! I think it’s a promising concept.


Actually I was using dzuk’s fork. I agree, it would be great if that is added to the benchmark tests.

That sounds mind bendy! I think what I was thinking of is still there in elm-css?

Never actually tried it, so I am not even sure of what it does. But occured to me that if you want the maximum perf you should use plain .css and this could be a nice way to generate it, also can use common code between an app and its Stylesheets.elm.

1 Like

I have started using raw tailwindcss classes with the lsp and it has become very hard to go back to elm-css for anything other than elm-select package development.

The pre-processing tool is an awesome idea which would mean you get all the benefits of elm-css without the potential issues.

Someone please make more hours in the day!


Yeah, I remember the old days of elm-css generating a stylesheet. I think a fork of that old approach was maintained for a while, not sure if it’s still around (I wasn’t able to find it, but maybe someone else can share a link).

I think the approach I’m talking about could be a superset of that, but it’s an ambitious project idea that would take some time and effort to build. I do really like being able to use locally scoped styles personally, especially with the help of tools like elm-tailwind-modules.

Is your affinity for tailwind from a development perspective, or is it taking the performance considerations into account? I’ve never used tailwind, but from a quick look it appears to be kind of like elm-css but less flexible. Is there something about it that makes the development experience better (when writing elm code)?

Is your affinity for tailwind from a development perspective, or is it taking the performance considerations into account?


Tailwindcss scans all your elm code for tailwind classes and builds your stylesheets with only the css you actually use at compile time. So your bundled css is very minimal usually. Because you are leaning on tailwindcss you dont need elm-css to fold over your entire project and attach span’s to all your elements for localised css classes during runtime.

Breakpoints, psuedo elements and modifiers are far more terse in tailwind.

div [ class "sm:bg-slate-200 hover:text-black dark:text-blue-300" ] []

This expresses breakpoints hover states and dark mode, but you have a similar experience with transitions and animation which is a fair bit more work in elm-css.

If tailwind doesn’t have a unit increment that suffices, overrides are easy to do. Tailwind will generate a snowflake class for you from this.

div [ class "dark:text-[#FF5733]" ] []

I have yet to hit any css utilities that tailwind doesn’t support, elm-css lacks a bit of support around things like grid etc. I know there are forks etc but i’m not interested in playing follow the fork.

Getting inspiration from any component systems like tailwind UI means you can literally copy and paste the classes in to your project and you have a beautiful, accessible element rendering on the screen. Speed of development in this case is just way better.

The tailwind lsp is also amazingly good, so whilst you are essentially writing class strings, it has all the autocomplete intellisense goodness you want as well as warnings and errors when you combine modifiers in the wrong way. Once I got it working it actually was the thing that fully made me a tailwind convert.

Tailwind documentation is top notch. Easy to find what you need, has examples, can’t go wrong.

I’ve never used tailwind, but from a quick look it appears to be kind of like elm-css but less flexible. Is there something about it that makes the development experience better (when writing elm code)?

For package development, yes, it’s less flexible as it requires a non elm step, but other than that I would probably disagree.

From a productivity and development point of view, my opinion is it’s far better for the way I work. I did go in to tailwind kicking and screaming though. Once I saw the speed of development boost in my personal projects as well as at work I couldn’t deny it was better. I took me a couple of days to remove all the elm-css code in a pretty substantial production app and replace with tailwind. Have to admit it was pretty rewarding to delete a bunch of elm-css logic and replace with a string that did the same thing.


It kind of makes inspecting your styles in developer tools a bit crap. You get used to it but it did irk me a bit initially.

You can get some gnarly long class strings. Very annoying, but you can layout things pretty well with classList. It’s not perfect but less annoying.

It’s a non elm extra step to build your css stylesheet. Some folks may not like this but all the production elm code I work with is bundled and so its a trivial step.

The tailwindcss extraction is pretty simple, it wants to see fully resolved classes so things like the following wont work as expected. Support would need to be added for things like constant propagation to resolve classes etc.

bp = "sm:"
cl = bp ++ "text-slate-100"

Would need to be…

cl = "sm:text-slate-100"

As you can read, i’m pretty in love with tailwindcss so your mileage may vary. Trying it out is pretty easy.


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.