A little weekend learning: Trying out Tailwind

I (re-)realized I had the book “Modern CSS with Tailwind” bought, never read a page of it until today. With me being a fast reader and this book being 90 page in size, I skimmed through the book fairly quickly.

Tailwind never was convincing to me, from the definition of it, it felt very counter productive. My friends who used it and this book made good enough case for me to actually take it for a spin and see for myself. I actually had a project for this. A Covid19 dashboard I created last year, where I used the CSS framework I love the most- Bulma. Let’s use Tailwind on it to see how it feels like!


Step 1 - Tabula Rasa

… as far as CSS is concerned! After creating a new branch, I removed all the design and existing CSS framework so that the UI looked from…

to a much more beautifully designed…


The charts and maps are still the same and will remain so even after the experiment. I do intend to change those too but that is another day’s tale to tell.

Okay, so got my clean slate, now let’s get on with the experimentation!

Note: The system is entirely functional. It just looks a little pale that’s all.


Nice one Mafinar - I will be following with interest :smiley:

I hear this a lot… and then people fall in love with it :joy:


Corresponding tweet for this thread:

Share link for this tweet.

1 Like

Step 1.1 Setting up Tailwind

I used this link to setup Tailwind. This commit has this. I also read the book on this chapter but this being a LiveView project I needed a more tailored tutorial. I did use the example given in the book to try out moving and enlarging some titles on the card, they worked (I didn’t commit them because they don’t look good in my particular case).

Interesting things, I went all heroic and modern and what not and decided to NOT use the @4.2 while installing css-loader (The article recommends it, the book doesn’t concern itself with css-loader in its introductory chapter), and was yelled at by the compiler through error messages, using version 4.2 helped. I’m in too much of a hurry to afford not knowing why.

Another thing, VS Code is showing Unknown at rule @tailwindscss(unknownAtRules) on @tailwind directive and while my OCD makes me want to fix it, I can afford not caring for today at least. It’s inconsequential.

So, it works, I brought back my theme.scss and colors.scss and removed Bulma specific variables. Awesome! I can see the font changing and the overall UI changing.

I am not a designer, I am not even design-minded, so it’s more than expected that whatever I do here will suck. Hopefully, it will be better than the first screenshot, since I have matured compared to a year ago (or I’d like to think). But I will not hurt any readers eyes with sharing screenshots at each stage unless there is a noteworthy design change or an aha moment! This time, it just knows Tailwind classes, nothing more, so no screenshots :slight_smile:


Step 2 - Layout Changes

So texts are all over the places, so I need the first pass to replace all the columns and column with it Tailwind aware semantics.

@apply seemed to be friendly to me in this. I kept the class names intact and used some @apply magic to compose Tailwind classes to make the UI structure feel somewhat decent.

Cards are also pretty structured in Bulma, and I assume in any API it would look similar. So I smelled another @apply worthy feature, at least ostensibly. So I went ahead and did that too, I used a composition of titles like has-text-centered is-title is-5 even in Bulma land (sort of what I’m going to do in Tailwind, there was a universal Find/Replace that saved me to create a card-title class.

The final thing looks like this:

I think in working with Tailwind, one needs to take dual approach- macro and micro. When thinking big, and making a big chunk of content presentable, one can go for @apply on some soon-to-be-discardable classes and make the things (temporarily) structured, later once the author is fluent enough with the UI, replace it with more articulated classes. The micro approach is the opposite, isolate a particular UI component, and experiment with combining utility classes, and once satisfied, keep it, and move on to a next UI component. Once the author is comfortable with the experience, things could be @apply-ed, resembling the first approach, and making it more articulate with experience. Things converge towards a semantically sound system through experimentation from both ends.

Again, I am learning things and thinking out loud, maybe I am going the wrong way, and will correct my ways. I am not even fluent in CSS, far from it, it’s all in the name of learning and good fun!

I will go watch (and be more disappointed) by Love, Death and Robot now and be back later with more.

UPDATE: Relevant chapter on this for the book, Chapter 6! Which was actually the first chapter I read! But during development, I mostly consulted the documentation of Tailwind.

Reaction: The Tailwind code examples in the wild is super messy in the eyes! Not sure if it’s due to inexperience though.


End of Day 1

So, after those macro level changes, I moved on to more widget-by-widget designing.

This was fun in an “exploratory” sense of way. I made changes, the changed reflected and once satisfied, I moved them to their own class name, only to realize it could be a least common denominator to another design should I remove some utilities and add them as classes. I think the more I make things and see the result before my eyes, I will get an intuition on how best to build the structure.

I’m afraid I will end up making a new “framework”-ish pattern at each of my projects, and therefore, more maintenance. I am not sure I would want that. Things like Bulma gives you sensible defaults and makes some decisions for you, which I am totally cool with. But well, Tailwind IS fun and I only played with it in total what, 2 hours? So I will work more to see if I like it better.

This was the most important commit. Things to try next weekend:

  • Name things right, it’s a mess.
  • Investigate why it takes forever to compile since Tailwind was added (aka get introduced to some tool-fu)
  • Redesign some stuff instead of making it look like a more straight-forward clone of the Bulma version

Decide on which one to keep :wink:

Here are the screenshots (Tailwind converted one):

and for detail view:


Damn, I missed fixing the footer :man_facepalming:


Woke up and took a look into my code. And decided to end this experiment with TailwindCSS and keep this branch as it is, a branch :slight_smile:

There are several things I observed that made me realize TailwindCSS is not for me:

  1. In the wild, when I looked into the examples, very few of them used @apply and most of the examples hurt my eyes plenty. Like the following example:
            <button class="text-base  rounded-l-none border-l-0  hover:scale-110 focus:outline-none flex justify-center px-4 py-2 rounded font-bold cursor-pointer 
        border duration-200 ease-in-out 
        border-teal-600 transition">
                <div class="flex leading-5">Next

I could have done it in CSS too. I already knew about border-radius, and I will need to keep that knowledge in my brain because it’s the framework independent way, however, now I need to keep rounded-*-* in my head. Multiply that by almost all the other properties.

  1. Even if I carefully apply things and get myself free from the overcrowded class situation, I will end up inventing my own way of doing and naming things, which may waste time in cases where I probably would be better off with sensible defaults and override when necessary, or just use CSS classes with CSS properties.

  2. If I am to prototype things where good semantics may not matter, I wouldn’t still use it because I have OCD about code organization and I won’t be able to sleep at night with it, getting back to point 2.

  3. In a team environment, there runs a risk of a case of “escaped applies”, a hard to debug situation where there was a card-image px-4 py-2 rounded left out unintended

  4. It’s slow to compile, probably I am missing some tool or steps but there you go, more tools, more fatigue.

So from my experiment, Tailwind does not teach me anything notable enough to go on with it. Maybe I am old fashioned and maybe I am not a front-end developer which makes me not get a few of its merits, but I will happily go back to the way I did things before :slight_smile:

Please read all of the above with a huge “In my opinion” in mind

Also, I have read this article and I agree with most of what’s mentioned here:


I have been working with TailwindCSS but in a static page, therefore using the CDN to grab it, but this is not the way to go at all for production, because the file is just too big. So, it needs tooling to the rescue for making it smaller, while with other CSS frameworks this isn’t such a big issue.

The huge amount of utilities classes needed to write in the HTML markup is just crazy and makes the HTML unreadable. Too much noise and pollution for my eyes.

I have to recognize that is easy enough to work with and achieve very good looking results :slight_smile:

Still on the fence if I will use it for any serious project, but If I do decide to use it then I will need to use @apply to cleanup the HTML markup, and that is just more work :thinking:

Another advantage in TailwindCSS is that web apps will not look so similar, because you are note using pre-defined choices.


Oh ow, yeah I agree there… Is that really defining, basically a style as part of the classname? What on earth?!? o.O