Is your affinity for tailwind from a development perspective, or is it taking the performance considerations into account?
Both.
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.
Downsides…
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.
