jacamat

jail is not that bad.

Localization != personalization.

I'll definitely respond to this more later. ;)

Mixins FTW!!

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.

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!

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.

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.

No, the key phrase is, "We don't think this is the best way to write CSS."

in what way is that consistent tho?

you have that with tailwind too, lol. probably even worse the bigger your app is.

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.

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>

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. :-)