The benefits absolutely do not outweigh the cons. For starters, your CSS can never compile down to a smaller size than component CSS - ever. Because of the nature of compositional classes the plateau of problems expands out almost infinitely, and the resultant inconsistencies necessitate new overrides, more code, more complexity, more misdirection.
What size site do you work on? How often do you have to completely change an interface, or move a component from one place to another without it breaking at all, and how well does that work for you with Tailwind? How do you plan to scale this codebase consistently across organizations, teams, potentially platforms?
Tailwind and the frameworks like it are absolutely terrible at scale. I've spent years of my life trying to remove functional css from sites trying to scale while it holds them back.
Co-author of Tailwind CSS here. Prior to building Tailwind, I followed more traditional approaches to writing CSS, like BEM. In fact, I remember when BEM first came out, and people hated it too. I've worked on small projects, and very large projects. I recently rebuilt a large web app using Tailwind, and my resulting CSS was TINY. I use Tailwind in conjunction with Purge CSS. The resulting filesize was 8.1kb gzipped (42kb).
> Tailwind and the frameworks like it are absolutely terrible at scale.
My experience has been the opposite. BEM is terrible at scale. You write the CSS, but then never dare change it, because you have no idea of the consequences of those changes. Developers end up duplicating BEM components for their use case, because it's safe. Which just leads to more CSS code. It's also worth noting that we're seeing more and more large companies move to utility based CSS, including GitHub and Heroku.
At scale, the priority is isolation of components. This allows things to be composed, moved, etc. without affecting each other.
We accomplish this in our web app (over 500 kloc) by simply giving each component’s top-level element a unique, formulaic, memorable CSS class (which is very easy to do with SASS/SCSS). And each component gets its own CSS (or .scss) file, HTML file, JS file(s), and I18n directory. The app loads each component’s CSS when that component is loaded at run time (which could be during startup or later). I just don’t see how one could get more straightforward than this for a large app.
We do have some classes that are included in the base-level stylesheets and shared among components, but we only use those when it would result in less code than not, or when necessary for themeing.
It may take a lot of effort to build this kind of architecture, but once you’re there it’s a breeze to create, compose, and maintain UI components.
The problem with isolation of components is that then the stylesheets are no longer cascading -- each component needs to be re-designed to fit within a design framework, and there's no CSS reuse between components is entirely copy-and-paste. Good luck re-styling anything for "dark mode" without having to hand-visit each component's JavaScript and CSS.
Plus, component isolation has really slow polyfills. None of the Google stuff as of late runs on anything other than Chrome for like a year after launch because it's too slow and broken -- everything is being rewritten in Polymer, which relies on browser support for component isolation.
Avoiding the cascade is kind of the point, although I'm sure that sounds antithetical. IMO, the cascade should be treated with an "opt-in" approach, where you have a fine degree of control over what, precisely, is cascading and why.
In general, with component CSS, you will tend to avoid the cascade, except within your component. This is actually where utility classes have some value - if they're scoped very tightly to the parent, and their effects are well-understood - then your single purpose class can add an easy way to do simple updates.
That being said, for my part, and on my own website (doggos.com) we do not use any form of utility classes whatsoever. The entire website depends upon isolation, and through this isolation, I have a degree of control that I've not found in applications that have opted for other methods.
In short, it's worked very well for us.
As for your dark mode example... you should take a look at how Apple made dark mode a reality with their new Mojave update. I think you will be surprised at the level of isolation their interface demands and, although we're no longer talking about the web here, just how easy it was for them to implement...relatively speaking.
In short, I can make a site go dark with components, no problem.
We're not using any Web Components APIs, thus no slow polyfills are required (see my comment for how we isolate component CSS).
As for eschewing the style cascade, yes, that is happening when we isolate each component's CSS. However, wouldn't using Web Components proper have the same problem? And yes--it would be a very large task to add a dark mode, as you say. Each component would have to be visited. However, when we drop IE11 support, CSS custom properties will make this potentially much easier.
We don't copy-and-paste CSS often (remember we're re-using components and composing them everywhere). If there's enough commonality for CSS copy/paste to be tempting, it's probably time to either revisit how components are being composed (do we need to create a new component, or maybe have these 2 similar components inherit from a base JS class?), or add those styles to a top-level stylesheet and use shared CSS classes.
> I recently rebuilt a large web app using Tailwind, and my resulting CSS was TINY.
I think Tailwind is quite an interesting approach, but to play Devil's advocate: how much bigger was your HTML? With all these class names, you're basically moving some of the entropy over from the .css to the .html, right?
I'd love it if you expanded on that last comment - my instinct is that functional CSS is a footgun, but I'm not nearly good enough at CSS to really be able to unpack that into concrete problems it causes.
Sure thing. Due to an NDA, I can’t get into granular detail about the site, but I’m more than happy to expand on the problem.
When I started here, I sort of “inherited” a large stylesheet written in the classic BEM/Tachyon style of CSS. I can see why the author chose this method, because at the time the website was small and functional classes seem like a really good thing, as they help you get up and running quickly.
Over the years, however, the site got more popular, and now the demands of the interface are increasing. At one point, it was perfectly OK to do, say, “container mt-5 mb-5 p-20 text-green” etc. This flexibility allowed the site to grow, and while the CSS did bloat, the impact was seen as negligible for years.
Now the site sees 50-80k+ DAU, and seeing as the business is very established, it makes sense that we would want to add bells and whistles to the UI that wasn’t on the roadmap those years ago, like theming, widgets, or simply making a previously non-responsive page responsive.
In Tachyons, and in Tailwind, the abundance of utility classes means that even the best, most organized authors will create inconsistencies. The original container styles from earlier might look something like
“container mt-5 mb-5 p-20” in one place and “container mb-30 mt-30” or “container bg-dark pt-5” in others.
It may seem trivial to just add and remove classes at will, but it isn’t. Removing a margin-bottom from one element inevitably affects the position of another on the same page, and trying to reconcile these inconsistencies _usually_ means an override, because figuring out how to rearrange functional classes without breaking anything else is a time suck.
Removing this style of CSS from the project has been tedious, but necessary. Now that we build with small, immutable, scoped components, its trivial to drop in a new component (or remove it) from anywhere without affecting anything else. And you avoid the unexpected inconsistencies created using utility classes by, well, avoiding them. As someone that used to love BEM, tachyons, Atomic CSS, etc., the lack of scope, unpredictability and huuuuge bloat created by overrides steers me away from it even for the tiniest of projects.
> container styles from earlier might look something like “container mt-5 mb-5 p-20” in one place and “container mb-30 mt-30” or “container bg-dark pt-5”
I've only used Tailwind briefly for some side project, but I thought the docs made it clear that whenever you have a situation where you feel you're repeating styles you should extract them into a new CSS class. There's a whole section dedicated to that in the docs:
How would this have been prevented if those same developers weren't using Tailwind and instead simply created .container1, .container2, and .container3?
> Now that we build with small, immutable, scoped components
What do you mean by the word component? Are you talking about a React or <insert framework here> component? I don't really see how it's related. It seems like your team quickly iterated and didn't think forward about creating a common look for "containers" until a good amount of development was done. The common look could have been accomplished by extracting the common styles like the above link suggests or creating a common "Container" UI component with isolated styles. The mistake was not thinking ahead and seems unrelated to Tailwind IMHO.
> Now that we build with small, immutable, scoped components, its trivial to drop in a new component (or remove it) from anywhere without affecting anything else.
Any suggestions for further reading on "small, immutable, scoped components" ? I'm half sure I know what you mean and entirely sure I don't understand it well enough to explain it to somebody else.
There’s no magic. Remember that at the end of the day, no matter what approach you take to your CSS, we are all dealing in trade offs.
I like to say, that with components, you encounter “a new level of bugs.”
With Functional CSS, you deal mostly with incidental bugs. “This container has margin 10 and this one has 15!” or “This text-red is overriding all my text!” Individually, these are annoying, but together they can compound into unfuckable problems. Right now I’m working on rebuilding a header that was styled with this approach, and ultimatley wound up unable to remove certain classes without breaking other elements. Something as simple as moving the text from one side of the screen to the other involves building an understanding of how they work individually, which is very challenging in a site as large as ours.
Enter my new header, a component. Its got a parent of .HeaderComponent and everything is scoped inside of it. If I delete, say, a .Link here, it doesnt affect links elsewhere on the site. And since I include re-usable mixins for base styles, like text, its easy to (say) @include BodyFont; or HeaderFont; without affecting the page or the site as a whole.
What I mean when I say “a new level of bugs” is that how and why you build things becomes more important. If I build a header component, but a large change happens elsewhere on the site, its unlikely I will change my original component. I’ll make something new and call that, instead.
In this process you can wind up with poorly built components, things that wind up not being used as much as you thought, etc. But the beauty of it is that getting rid of them is SIMPLE. I made a lot of mistakes when I started building doggos.com with components, but I’m really excited about how easy they were to remove. If you just make something new when you need something new, you wont have a bunch of legacy code following you around everywhere.
That probably isn’t a greaaat explanation, but I’m very happy to expand further or give you some links. In particular, Airbnb.design has some great lessons on why they ultimately went this direction, and they do a much better job of explaining it than I!
What size site do you work on? How often do you have to completely change an interface, or move a component from one place to another without it breaking at all, and how well does that work for you with Tailwind? How do you plan to scale this codebase consistently across organizations, teams, potentially platforms?
Tailwind and the frameworks like it are absolutely terrible at scale. I've spent years of my life trying to remove functional css from sites trying to scale while it holds them back.