Oh no, laziness! Someone is doing something in an easy and convenient way that somehow doesn't match up with other people's ideals of conceptual purity! :'(
Bloating your markup with classes is simply a bad habit. It bites you hard in the long run.
Even the framework that they are using proposes better alternatives.
“Tailwind encourages a "utility-first" workflow, where new designs are initially implemented using only utility classes to avoid premature abstraction.
While we strongly believe you can get a lot further with just utilities than you might initially expect, we don't believe that a dogmatic utility-only approach is the best way to write CSS.”
A class based rapid prototyping framework is a powerful tool, don't get me wrong. However, like all tools you should only use them when they truly are needed.
How so? If what I need is (as the author describes) to occasionally make a quick relatively-usable site, and I want to do some styling on it, and then forget about frontend UX until I need to do another small site 4 months from now, how will this pattern bite me?
How can you achieve reuse (DRY) with this? Every time I have a button, if I want my buttons to be consistent and have a single place to change them, I have to like invoke a button partial that just outputs my <a> with 20 classes on it? It's a lot easier to reuse a CSS class (an abstraction) than a template of a chunk of HTML (an indirection) -- especially across divides of languages/runtimes/client-vs-server if you have any of those.
I agree with the point you're making, but it doesn't seem to address my question. The author describes the usage pattern that I find myself in, and I suspect is relatively common among non-frontend devs: we aren't particularly skilled in CSS or other frontend web dev work, but every now and then we find ourselves wanting to make a quick, simple, but usable site as a landing page for some other project we're releasing.
For people in that niche, frequent tweaks/changes to the styling seem unlikely: I'm going to make the site once and unless it breaks I'm unlikely to come back to the code for it.
The parent comment I replied to makes the direct claim that this class-based pattern will bite me, and I'm curious if somebody can help me figure out how that would happen.
I think the article provided good insight on this: "I wonder if the reason this approach makes more sense now is that we’re doing more generation of HTML than we were in 2003. In my tiny example, this approach to CSS actually doesn’t introduce that much duplication into my site, because all of the HTML is generated by Hugo templates, so most styles only end up being specified once anyway."
So you write your button one time in a reusable button component, then reference the component and avoid writing the same 20 styles again. I think this has benefits as it keeps all the information for a single component in the same location, making it easy to understand and edit the component from a single location.
Could you suggest how it's bloating the markup and how it'll bite you in the long run?
I understand that maybe adding a bunch of classes for every element will increase the overall size of the page but if it's served with gzip compression doesn't it actually (maybe only technically) work better to have repetitive classes everywhere instead of unique class names?
The problem with granular classes is that you project won't scale in an efficient way. It also makes refactoring almost impossible.
On a small one page website, do use them. However in something more complex like an e-commerce website theme or a complex web app, you will regret it quickly.
One of the selling points of CSS is the ability to scale and refactor very quickly and easily. Class based frameworks remove all those benefits. Extracting components and building sementically is the solution. As I said in my previous comment, that framework they are using supports it. They say it themselves:
“*While we strongly believe you can get a lot further with just utilities than you might initially expect, we don't believe that a dogmatic utility-only approach is the best way to write CSS.*”
I have worked on many contracts where the client came to us because their current web agency wanted to charge crazy prices to refresh their website's design (e-commerce websites change at least one a year). Almost every time, those projects are a pain for both the team and the client because the previous developer decided to be lazy and use classes or inline styles everywhere.
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
I tend to think laziness is positive when it inspires better architectures. Picture a dev who just sits there drinking his coffee until he finds a way to do something without typing a lot or remembering a lot of small details. Now picture a dev who dives in enthusiastically, writing the same bits of configuration a hundred times with small tweaks. Whose code would you rather maintain?
If an abstraction makes it easier to do what you want to do, it's a useful abstraction.
