Adam Wathan, the creator of Tailwind CSS, writes about CSS, Vue, Laravel and building a software business.
HN commenters repeatedly point to his utility classes and separation of concerns post as the best argument for Tailwind's approach.
Why is it that Tailwind causes such emotional reactions in people? Functional CSS has been around a long time now.
When functional css ideas were introduced it presented a novel solution for scoping issues, naming issues and bloat issues. I remember discovering basscss and tachyons around 2015. The paradigm immediately felt like a huge improvement in my workflow. The iteration was so much faster than what I was used to with Bootstrap, BEM, or SCSS- I felt like I could design in code for the first time. My favorite workflow for web design became loading basscss in a CodePen, with almost no idea of the outcome I wanted and iterating towards something. What’s kind of amazing is that it allowed for these sorts of quick sketches and improved maintainability in large projects.
It also led me to my first inkling of a design system- through the use of composable and constrained styling primitives. A lot of the ideas introduced with those libraries now saturate the frontend ecosystem. And keep in mind, functional CSS, or at least the principles behind it have evolved a lot since 2015, particularly when it comes to components and CSS-in-JS. The original creator of basscss has gone on to create a number of equally impressive projects that advance the main ideas: styled-system, rebass, basically everything from @jxnblk.
I haven’t used Tailwind or any other functional CSS philosophy over the past few years since I find primitive and composable styling components, CSS-in-JS, themes,…
This [1] is one of the best articles I've read describing the issues and thought processes around the complexities of structuring css. But the suggested conclusions are exactly where I start to have problems. Take this recommendation for example:
.align-left {
text-align: left;
}
This is a very reusable class, of course, because it is literally just css but with a different name. But that's what always ends up happening. The lowest common denominator for reusability in css is so low, that you often end up with ridiculously simple classes like this, or close, basically re-inventing css with a different syntax. The new challenge becomes learning this new language and how to compose it.
The core issue with CSS is that it has divergent architectural characteristics simultaneously. On the one hand there are usually a set of extremely re-usable primitives: btn, normal-text, overlay, card, etc. Then very quickly, we get higher-level components/styles that are extremely not re-usable: order-form, contact-page, etc. And other stuff in between. Applying the same structural models to all of it will cause sub-optimality at some level.
To address this, I've found that applying different models to different aspects of the css most beneficial. Basically having a mix of both utility css, and semantic css. Low-level, highly re-usable components are defined in a utility fashion so that font-sizes, colors and other things are consistent throughout the site. And complex,…
Thank you for your support!
The biggest advice I can give you is not about any specific tool, it's about an approach. You need to think about how you will market the book if you're self-publishing.
Engage with the community that will be interested in the book. Write articles, help out on Twitter, write code libraries, etc.
For me, I wrote DynamoDBGuide.com two and a half years ago over Christmas break. I wanted to just make an easier introduction to DynamoDB after I watched Rick Houlihan's talk at re:Invent (which is awesome).
That led to other opportunities and to me being seen as an 'expert' (even when I wasn't!). I got more questions and spent more time on DynamoDB to the point where I started to know more. I gave a few talks, etc.
I finally decided to do a book and set up a landing page and mailing list. I basically followed the playbook that Adam Wathan described for his first book launch.[0] Write in public, release sample chapters, engage with people, etc.
In terms of tooling, I used AsciiDoc to generate the book and Gumroad to sell. On a 1-10 scale, I'd give AsciiDoc a 5 and Gumroad an 8. But the tooling barely matters -- think about how to find the people that are interested :)
Happy to answer any other questions, either in public or via email.
[0] - https://adamwathan.me/the-book-launch-that-let-me-quit-my-job/
Check out the Tailwind author's reasoning: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/
I find it more compelling than I expected.
The truth of the matter is that as much as the idea of separation of html vs css sounds good, it's so hard that I rarely see it done. Without constant vigilance, you end up with premature abstractions, things you can't actually reuse, and an append-only accumulation of CSS.
The dream sounds good but leaves all the hard details for you to work out yourself. And frankly, after over a decade, I remain unconvinced and ready to look for new ideas.
Breaking the rule with Bootstrap since it first came out never stopped me from building great things, yet trying to obey the rule slowed me down and had me constantly refactoring CSS. It feels like a cargo cult.
We've been pointing to CSS Zen Garden for 17 years as an example of the benefits, but giving everything a class so that you can address it from a .css file isn't the hard part, and that's all the garden shows. The hard parts are organization, maintenance, coming up with a unified strategy, playing CSS whack-a-mole when you change HTML, deciding where to define what, finding where you defined what, etc. The garden demonstrates none of that.
1. Positioning (yes even with flex) is unintuitive and painful
2. The fact that the !important tag exists, and at a broader level the fact that cascading exists
3. The community seems pretty hellbent on rejecting working solutions for being "bad". float: left is "bad". And yet, many/any other positioning systems are, to me, much worse. So to me, it's all "bad". Similarly, tables are the easiest way to position things correctly (since point 1, all other positioning tools are pretty bad), and yet, table-based-layouts are "bad". So again, it's all "bad".
More elegantly put:
- https://adamwathan.me/css-utility-classes-and-separation-of-concerns/
- If you search "What's wrong with CSS y combinator", you'll get some derivative of this exact conversation over and over again for the past 15 years. CSS people saying "no it's good!", many other types of people saying "it's just too complicated and I don't want to keep doing it", followed by css people saying "no it's good!"
I think Tailwind is probably the closest approximation to tolerable CSS, but I also think its existence highlights a greater problem with both the community and the technology.
No, not custom at all. Quite the opposite - it's a well-curated set of standard classes. It's the focus on utility-based composition of style that sets Tailwind apart. For me the problem being solved is maintainability, recognising that CSS is tremendously brittle with regard to the application it serves and the context in which it is evaluated.
Probably best to read https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ which does a much better job of explaining the motivations, and the conceptual journey of its creator, than I ever could.
Many folks (not all, but many, I'd even venture to say ... most) have a four step reaction to Tailwind:
1. That is the stupidest webdev idea I ever heard, and I've heard a lot. // 2. Fine, I'm trying it because everyone else keeps prompting me to and/or its creator seems competent. // 3. This is weird but actually quite helpful and totally not what I expected. // 4. You have ruined me for any other CSS framework and I never want to use anything else.
All CSS is crap. Tailwind is (in my experience and opinion) the least crap and most productive approach yet.