Hacker News Reader

Comment by shubhamjain | Hacker News Reader

I don't understand why it's an either/or between Tailwind vs using CSS classes. Tailwind is awesome. At the same time, no, repeating the same styles for links, buttons again and again isn't great. Code littered with hundreds of classes is plain ugly and makes it hard to read and work on. This[1] is a valid complaint about Tailwind. The < span > at the end has nearly 20+ classes.

At some point, you should abstract some set of classes. In some cases, CSS selectors and other CSS feature will allow you to do what you want with far fewer lines of code.

[1]: https://twitter.com/xirclebox/status/1673557143088242689

View on HN

You can quickly create a .primary-button (or whatever) class where you group all the Tailwind classes with an @apply. Then just add primary-button wherever you want.

https://tailwindcss.com/docs/reusing-styles#extracting-class...

I'd also add that the code in the Tailwind example is much easier to maintain and jump in on. It describes everything going on without you having to cross-reference a separate CSS doc with all of the actual meaning hidden in it. Joining a new project with 1000+ line CSS files + media queries randomly added throughout is a horrendous experience.

is @apply a preprocessor thing? does CSS still not have a native way to do multiple inheritance/traits?

You can use CSS preprocessors such as Sass that have inheritance. But most people doing front end design these days separate out design elements into components, which pretty much completely handles the re-usability of the underlying CSS. But @apply is useful for smaller elements used across components like buttons, form elements, headings, etc.

My opinion, here's the deal: no, you don't need to abstract any set of classes. That defeats the purpose. But there's a catch: you must be working in a modern component-based framework to work like this effectively.

Because that's the context where Tailwind grew.

If you have your set of e.g. React components defined you don't really ever "repeat the same styles for links, buttons again and again". You just use your components. <Button/>. <Link/>. <Card/>. <Container/>. Whatever you need. And then your only "raw" tailwind in your "templates" is the scaffolding around it.

And it's great. No write-only CSS syndrome, no coupling between components, at-glance understandability of what's going on.

But you gotta be using components, otherwise it's just overwhelming.

It's an either/or because once you start heading down the Tailwind/Bootstrap path, it pulls you out of the habit of using proper classes and such, and now you have fifty pages where some bit of text uses "text-xl" or whatever instead of a proper and descriptive class. You get into the habit of writing HTML with a bunch of styling directives in it, just like we did in the pre-CSS days.

I do agree, it's easy to abandon classes altogether. It's also a bit concerning that newer devs are starting with Tailwind. At the same time, I think one should be able to notice that certain styling is just getting repeated everywhere and abstracting it out makes sense.

What I actually like about Tailwind is not that you don't have to create classes at all, it's that you don't have to do it for things that don't need it. My old codebase was littered with hundreds of classes doing the same set of styling — padding, margins, flex-box stuff. That's the biggest thing Tailwind helps with.

That may be an issue with inconsistent design elements on your site, then. Simplify, reuse as much as possible, simplify again, repeat.

You are using the word "proper" twice as to indicate that it's well established what that means in terms of CSS. Adam felt that the idea of semantic names wasn't really working. This was an itch that I had myself without ever articulating and I think that the popularity of Tailwind shows that many developers felt/feel like that.

> You are using the word "proper" twice as to indicate that it's well established what that means in terms of CSS.

To say "proper classes" doesn't imply anything about CSS. Classes are a markup concept. The class attribute predates CSS; CSS's selector language lets you target "classified" content, but it's not like classes were invented for CSS.

> it pulls you out of the habit of using proper classes and such

What's "proper classes and such"? You mean hundreds of increasingly specific and non-reusable BEM abominations like `.hero-text__sticky-container--secondary` that no one remembers and creates new ones?

Oh the joys on having to edit a website that was made (by myself or someone else) years ago before Tailwind. It takes at least a few hours to figure out exactly what all these class names actually do, and you are still never sure that there isn't some random lines in the CSS files that will prevent the style from changing like you hoped.

No, that sounds like a tangental problem born of inexperienced developers and/or poor communication.

There are many, many, many cases where communication is not possible because who is working on the code now didn't exist when it was written (unless you want to take the time to document out all of your CSS and hope that everyone who touches it follows that documentation exactly). A new team taking over, a new agency updating a website for a client that was made by another agency, a new developer being brought on, etc.

Sure. That's not a problem exclusive to CSS, though, and I don't see how it's one fixed by allowing bad coding practices.

> No, that sounds like a tangental problem born of inexperienced developers and/or poor communication.

I've yet to see a single project to not devolve into a mess of class names. Not only that, but a mess of class names with significantly repeating boilerplate, intimately tied to specific elements.

Proper classes would appear rather more like `class="secondary sticky container hero-text"`* in the markup. So no.

* or `hero text`, even (sans hyphen)

Have you ever jumped in on a project with hundreds of "secondary sticky container hero-text" all over the code base? It is a woeful few hours (at least, maybe day or two) of cross-referencing all of these "semantic" class names to their definitions in CSS, and even then you are never truly sure if there is another rule overwriting your changes somewhere else in the CSS. And good luck if more than one developer has touched the code since you last saw it.

As I replied in a sibling comment: https://news.ycombinator.com/item?id=36635382

I agree with you somewhat, I wrote a blog post called "Use 98% TailwindCSS, 2% plain CSS"[1]. I have recently been making an effort of making dark/light themes work and the problem increases again: it's a bit too easy to forget a set of qualifiers. I know that a number of libraries attempt to create "smart" class combination functions, so maybe the best solution is somewhere in that direction.

[1]: [link redacted]

It's not a valid complaint.

You extract those into components, and use them as components

Sorry for the rant incoming, but please no, for the love of God, no. Absolutely do not create a new component if it's just to abstract a CSS classe and a few HTML elements (unless you really really use it a lot).

I've been on a project like that, and the result was maddening: any page or component template would contain only references to other components and almost no plain HTML tag.

Each time you encountered something like a 'Title' or a 'Button' or a 'FooBarHeader' component, you didn't knew how much Javascript was executed behind each of those, or wether it had any side effects until you looked at the code (and sometime had nasty surprise on components used everywhere).

You also either had to look at its API or modify it to correctly use the web plateform (eg: how do I specify to my 'Button' is of type="button" or of type="submit" ? How do I add some aria attributes ? What if I want to add a 'data' attribute ?).

On top of that, the generated, runtime DOM would look nothing like the design-time template you are changing, which goes against the plateform, again.

And you also ended up with a huge 'components' surface, where this moderately complex (in term of essential complexity) had more than a hundred components, with some basic 'Button' component being monstruous 500+ lines of code under the hood (because of CSS-in-JS), all of it destroying the performance of the page.

On this particular project, I realized that the tag-to-component ratio was less than 1, even maybe closer to 0 than 1. In other words, behind each little <span> visible in the inspector, you had something like 3 to 5 component instances. I've called it "loosing your footing", as you couldn't touch any primitive, drowning in a sea of abstraction.

Somehow, I feel that it's more specific to the 'React' world which is a bit too trigger happy when it come to creating new component.

Any tool can be wielded incorrectly. You don't need JS to split something into components, components as a concept is orthogonal to JS.

The entire history of CSS is about the struggle to create components: from BEM to Sass and nested CSS. Separation of concerns cuts both ways: https://twitter.com/simonswiss/status/1664736786671869952?s=...

It’s not an either/or within Tailwind itself. It explicitly allows you to add classes like that using the built in styles using @apply (IIRC buttons are the example used in the docs).

The docs actively discourage you from doing this.

https://tailwindcss.com/docs/reusing-styles#avoiding-prematu...

They discourage you from doing this wholesale for the good reasons in the link you posted. But it is still highly useful for small elements that are reused across the site.

Plus, I'd assume that almost everyone using Tailwind is going to break their website/app into reusable components - which negates the need to use @apply across the board.

Reply on news.ycombinator.com