I agree, they are completely orthogonal features. The only personalization that's happening is inside the new session that the person creates when using incognito mode, which is understandable.
It’s not reusable. It’s not consistent. It’s not scoped.
It may be hard to see now how it will bite you now, but I promise you, it will. It would take hours to explain why, but I am speaking from years of experience here.
There is a reason large organizations have abandoned this approach, and it isn’t just personal preference.
This talk gives a pretty good explanation, Airbnb.design, Netflix, Facebook, and Instagram have many others
But I only want the element to be the color it IS, not a range of colors it could be. Whats to stop a dev using $concrete when they should be using $cloud? or $linkGray instead of $headerLinkGray?
these inconsistencies compound, especially across teams.
Nothing would stop them from choosing to use cloud vs. link gray but it's far easier to identify and fix those cases than it is to have #CCC, lighten(#CCC, 10%), etc. around the codebase. This doesn't fix human error, just reduces it.
Can you elaborate? I can't agree with you. Tailwind is meant to provide a consistent design system, of which CSS size should never get out of hand (which is the case then using regular CSS). Whenever I use Tailwind, I end up adding maybe 20-30 lines of CSS and I never have to open a CSS (or other sass/less/whatever) ever again. Have you tried Tailwind or you're just assuming what you're saying?
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!
Everytime I see Tailwind/Tachyons/Functional CSS at the top of HN I die a little inside. I've said it before and I'll say it again: if you actually like this kind of CSS, you probably don't work on large websites. And when you do, the reason people hate it so much will become abundantly clear to you.
Functional CSS makes for an unscaleable, inconsistent, unmaintainable dumpster fire of styles that is objectively worse than just writing regular CSS.
<sarcasm>
But it's convenient, right? So who cares! AirBnB, Facebook, Walmart, Github, and Twitter are all probably wrong anyway.
</sarcasm>
These are not stylesheets I want to emulate. As I mentioned in my other reply, GitHub is actively moving towards a more utility-based approach to solve this problem.
Compare this to a fairly large app where the CSS and markup were completely rewritten using Tailwind by a friend of mine recently:
This is all the CSS needed to render almost the entire app from mobile to desktop widths, in both light and night themes. The "utility CSS" is generated by a framework and not something engineers have to be concerned with when writing components.
Atomic CSS was used on Yahoo sites, since the Marissa Meyer level. Apparently on a few of their properties. Hard to assess whether it was a failure or not. Considering their websites were a negative asset, I doubt the use of Atomic CSS was a major component of that, there were definitely bigger problems.
This is all really terrible advice and my only conclusion is that you have never actually had to maintain websites that use this approach toward CSS as they grow past being a little one off blog into a large, customer facing, PWA.
With this method of CSS it will take years to consolidate, update and redesign your application. Ask me how I know. :-)
Yes and (moslty) no. Cascading that reaches “outside” of its component to affect other things is bad. So it is all about your approach to the cascade. Most people who have been working on the front end still struggle to grasp the concept of encapsulation & isolation when it comes to their CSS.
In my experience working on a web app that sees +80k DAU, the most difficult updates to our UI are ALWAYS in the cases where somebody wasnt cogniscent of the cascade. Or was, and used it when they shouldn’t have.
IMO, theres a lot of pushback to this technique and not a lot of questions into its benefits, but plenty of questions as to why its “just like this” so “why should I use it.”
I encourage you to consider the benefits of an isolated approach to UI, or perhaps try building something with it and see how the method compares to your current approach.
Or, we can all go on assuming that Airbnb, Facebook, IG, et al, have all opted into this approach for no reason
