Coming to terms with Tailwind

- Posted in css development tailwind webdev workflow - 8 comments

For a while, I blocked the Tailwind keyword on Twitter. I was a bit mad that @tailwindcss and author Adam blocked me on Twitter after I wrote a bit of criticism that got popular.

I was also tired of getting dragged in every Tailwind related conversation on the Svelte Discord. Apparently people thought it would be fun to mention me every time Tailwind came up. I guess I brought upon myself with these blog posts:

(All I was trying to do was making people reconsider their CSS strategy instead of blindly going for the new popular framework.)

Now, getting blocked by a person, that’s one thing. I guess Adam’s coping strategy with criticism was an “I don’t want to hear it.”

Needless to say, you then create your own bubble of truth. I understand you want your social media experience to be pleasurable. I’ve been getting into some stupid Twiitter fights recently and they can get you annoyed.

The weird thing is we never even had an interaction or anything on Twitter. Then there comes the point where I have to use Tailwind for work and I am blocked by an offical account and – that feels kind of stupid? Getting blocked by a company entity for having an opinion is kind of… strange?

??!

It’d be like my bank wouldn’t want me to be a customer anymore after I critiqued their app (post in Dutch). Sorry. Being critical of these things is part of _my job_.

Anyway.

You know how sometimes you fight something and it just doesn’t die? And then it just becomes part of the ecosystem? I think Tailwind is a bit like that. There’s no going back. It’s just part of the system now.

Just like I don’t like React I will probably never really like Tailwind.

But that doesn’t mean that I can’t be a professional and write the best Tailwind code I can if that’s what’s asked of me. And try to find the good stuff in there, which is what this post is about.

It’s the same with React. The rest of the world already decided a long time ago that React is a good idea. I don’t like it. I think the syntax is too complex and too many parts of the ecosystem try to reinvent the wheel. But there’s definitely good parts to React. Some of the most exciting frameworks I’ve found recently are all written in React.

So generally, if I don’t like a technology, I now have 2 choices: complain about it and try to avoid it or try to deal with it the best way I can.


So after battling Tailwind for a while, a new project came up, where Tailwind was requested as a part of the development.

I was tired of fighting it and I remembered what people argued in the original criticism, “have you actually really used it?” – upon which I argued – “I don’t need to use it to know that it’s bad! I tried it for a two hour experiment and I already know!”

Now. of course a two hour experiment is not the same as real-world experience. It’s not the same as giving it a try in a codebase with multiple people. It’s also not the same as being a deliverable towards a group of people who don’t know much CSS.

You see, it’s all easy to claim the right path for years, but if in the end your deliverable is too difficult to change or maintain, maybe you should question your methods.

I can forever claim that people should just learn CSS but if that happens to be a difficult thing, maybe we should try to make a deliverable that is more… malleable. Even if it creates some maintainability problems.

I know the devs at Spatie love Tailwind; a developer I respect also loves it. So surely there must be something there?

Long story short, the stars were aligned to give Tailwind a real try.

The Tailwind authors themselves argue that all the Tailwind overload of classes a shock at first but gets productive soon.

I don’t know if I was entirely productive at first because I first had to shake up my dev stack to add in support for PostCSS, PurgeCSS and figure out all kinds of Tailwind specific things. That was part of my original criticism – people kept bring up config & build problems in the Routify Discord – but I just happened to be in a productive dev tooling month, and built in all the tooling so I could run a Tailwind-based workflow in earnest.

And after that, going into the work of implementing a UI I had to admit. There is something here.

You know how there’s this huge book called JavaScript: The Definitive Guide and then Crockford’s JavaScript: The Good Parts?

I think there’s also something like Tailwind: The Good Parts.

  • Documentation is extensive and well written
    • I love the ⌘+K shortcut
  • The new Headless UI looks great and solves a real problem
  • The Tailwind UI project’s look for their component has some good visual choices (although Tailwind’s techniques make that look kind of baked in, especially if you use Tailwind UI)
  • Tailwind UI’s Figma file has the highest level of quality I’ve ever seen in an external Figma file
  • HeroIcons looks good
  • The underlying idea of design tokens to customize design output is great; design tokens are now being discussed to be a standard; having a centralized config that builds constraints into CSS systems will help maintainability. A framework that promotes those ideas can be a boon.

Now, time will tell if I’ll really regret going down this route. But for now, I’ll happilly accept Tailwind-based projects and learn as much as possible.

From a team perspective, it’s not just my opinion that counts. It’s the combination of opinions from the client (we often work directly with the dev team), my colleagues and myself.

If more projects come up, and as we learn more about Tailwind, I’m sure I’ll have something new to say. But for now I chose to embrace it as a new workflow. Just don’t say I never warned you if code become unmaintainable in the end.

8 Comments

  • Brecht says:

    I think this is a fair review about Tailwind. Just started playing with it and i noticed those same benefits as well. We live in a economic world where things need to go fast and frameworks can help with that. Especially to write and maintain code that was made by a colleague. Is Tailwind “the best framework ever”? Probably not. Same can be said about bootstrap and many others. It’s a tool. And one thing i like about Tailwind is that it does something different and for some Company or person, it could be just that “perfect tool in the toolbox”. Not a good marketing plan to block you for some opinions you’ve given. But maintaining old framework code is always hard… Try working with some bootstrap V1 code…. so on that matter i think some of the opinions you give are valid for many frameworks.

  • Sasa says:

    If you use React then Chakra-UI is a more logical choice.

  • Antony says:

    I love utility classes, and I also love scss.

    It takes only 40 lines of scss to write a grid layout ‘framework’, and it’s also possible to loop trough 6, 12, 24,36 columns, it is even possible to have them all looping from 12…100 , and it will still take 40 lines – although it will generate a tone more CSS.

    I only see utility classes for padding, margin, and some text align/styling. Although html already got a decent support for most of the cases. Quotes, strong, code, and so on….

    I think it all come to preference. Some people have enough knowledge to understand different point of view, and some people with excellent grammar skills, and a will to shine on the web trying to look much more senior than their 2 years experience working as a web dev in a web agency, are very vocal about their opinion, which is just a reflection of their very limited experience.

    As soon as you go out there exposing those junior bloggers/twittos who think they are the best because they are writing tones of tutorials on what is the correct way of writing CSS and JavaScript…. But are still not intermediate level in coding yet… They start behaving like a group of bullies at high school. You have to pick up your fight wisely.

  • mark watson says:

    Everything has tradeoffs. Everything.

    It’s immature to say “this is good” or “this is bad”, and it’s also immature to balk at the consequences of your actions. No one owes you anything.

    You took a dump on their work – you criticized something you didn’t even grasp fully. Then you went out of your way to whine about what they did to you. Embarassing.

    I’m sad I read your article, it was a waste of time.

    I hope you can grow from this experience.

  • Allan says:

    @Mark Watson: I hope you can grow some empathy and kindness in how you communicate, as I felt your comment here to be harsh and condescending. If you’re attempting to sound mature and teach other people what maturity is, I can assure you that you are not achieving this goal; it just came across as _mean_.

    I think the self-reflection and self-awareness displayed in this analysis is laudable. Please keep up the good work. Some criticism of your approach is valid; it always is. My comment here could be better, but I hope that we’re all trying to be kind and considerate and encouraging.

    Thank you.

  • Ant says:

    Dear Johan,

    It is not ok someone bans one from any SN. Really not ok and is also weird and unfair. But.

    You see, if you didn’t like a tool, no need to crusade against it and spread your dislike for it to the world. It is just as simple as that.

    Once I used to develop using Angular and didn’t like it, so as my team. But none of us started to post on internet our opinion and criticism, because many Devs using it and do create great stuff with it. Developers will decide themselves what to use and whether they like it or no.

    Every time you have an urge to solidify your ego, repeat this mantra – to each his own. Repeat couple of times for better effect.

    Cheers

  • Laurence J says:

    Allow me to add my opinion:

    One of the criticisms I hear about Tailwind is: why should I use another tool, when I can write plain css/scss?

    After working on multiple team-based projects, that is, imho, an extremely naive approach to any development, especially at scale.

    Just how good is your (not the author nor anyone in particular) scss organization and documentations? People tend to confuse yagni with oversimplifying things and/or overestimate themselves (Dunning Kruger effect). And in larger projects, their oversimplified attempts either 1) devolve into css cesspools, or 2) at best, reinvent a css framework like bootstrap or tailwind: highly-opinionated sans good docs.

    In my and my team mates’ opinions, we would rather read Tailwind’s docs than another developer’s half-arsed attempt at reinventing the wheel. It is also a godsent, when starting a new project or onboarding new developers.

    Very few web developers get to dictate the css framework/organization a project will use. Some are forced to use Salesforce’s lightning system. Others have to use poorly-written in-house css frameworks. In our team, we learned from our past mistakes, and adopted tailwind for ourselves and our future hires. Primarily for its excellent docs, and also its low-level nature (utility) and well-thought-out, extensible and incremental design.

    There are real problems and challenges with tailwind (or any utility-based css framework), both objective and subjective. But the ones mentioned in the earlier articles aren’t it. Not knocking, just saying. We’re still learning and discovering these ourselves, as well as coming up with solutions for each one.

    We need better, knowledgable articles that explore real issues in Tailwind and how to solve them.

  • Laurence J says:

    (Sorry for the previous, long comment. That was the POV from our team/company.
    This one is purely my opinion and my own journey)

    I lived through zen garden then bem and smacss (never tried oocss), so my initial reaction to tailwind was also somewhat negative.

    Then one day, I stumbled across a 2-hour video where someone cloned an entire website using just tailwind. The development process was organic, forgiving and incremental. That’s when I decided to really give it a go and started to clone websites myself using tailwind.

    Initially, I stuck with bem-styled classes, only using tailwind as a design token system (which also worked extremely well). Heck, I was using `theme()` instead of `@apply` just so I could continue to use css properties.

    But the more sites I cloned, the more I came to love and embrace the idea of utility css. Soon, I was no longer creating/renaming/cleaning up/maintaining css classes.

    And one Friday afternoon during our company’s “Share-a-Technology” sessions, I live cloned the front and product pages of the Epic game store with tailwind and svelte (at the time, we were primarily vue/react + 7-1/itcss).

    That’s when my team mates and project leader really took notice. After a brief learning/poc period, we started to use it in a few smaller-budget, non-critical customer projects. Those went extremely well. So we tried it on a larger project (custom lob software, iirc). That too, went well. Today, almost all our projects, large or small, use tailwindcss for the frontend.

    Anyway, that’s my journey and experience. But with any anecdotes, take me experience with a grain of salt, ymmv.

Leave a Reply

Your email address will not be published. Required fields are marked *