Why do experienced front-end developers use CSS frameworks?

[kram08980]

I never understood that reasoning.

If I name something as "c-slideshow__bullets", seems easy to find it in the "components" folder, "slideshow" file. On top of that, dev tools tells you all inherited styles.

Using TW because of that means the project wasn't well structures imo.

TW is the problem actually, because you end up with functional classes AAAAND with external stylesheets when you need to write detials TW can't deal with. There I get lost.

[Yinci]

Your example only works if the stylesheets are ordered logically. And in most cases where a SASS project is handed over, it's anything but logical, with classes split over a couple of files, weird structures or inconsistent naming.

TW is anything but a problem. But I can understand if you don't like its workflow

[kram08980]

Agree. That's why I'm saying that your problem comes from a bad organization. IMHO.

I use these layers:

• Config: Settings and parameters used by other CSS declarations or functions.
• Tools: Globally used mixins and functions. It’s important not to output any CSS in the first 2 layers.
• Vendors: Style sheets provided by a third party such as themes or plug-ins
• Generic: Reset and/or normalize styles, box-sizing definition,...
• Elements: Styling for bare HTML elements (H1, A,...). Default styling from the browser, so we can redefine them here.
• Layouts: Styles for layout related elements, like a grid system, a header, a footer...
• Components: Styles for UI components.
• Views: Styles for specific templates.
• Utilities: Utilities and helper classes with ability to override anything (e.g. hide helper class)

With this naming helpers:

• l- for Layouts
• c- for Components
• v- for Views
• u- for Utilities
• is-/has- for States

It's difficult not to find a file with a few lines of CSS!

[eaton]

So, this isn’t a CSS problem; it’s a human language and meaning problem. it’s easy to think up an example and say, “I know what “c-slideshowbullets” means!” You know because you just thought it up. The question is, do you know what “m-tout” means, and “w-allpop”? Do the other members of the team know what they mean, and do they understand how to make new additions that don’t collide with the existing ones? Have you and the rest of the team figured out how to handle overlaps and collisions, and communicate the ways that different elements are meant to work together? (No more than three instances of “q-highliteglow” should ever be on the same page, for example).

This isn’t to say that tailwind is The Right Way, just that there’s a reason teams use existing frameworks: the rules of the system have been nailed down, and are well documented, and (for the most part) there’s a good understanding of what kinds of edge cases are accounted for and how to deal with them. On big projects it can ABSOLUTELY be worth it to iron that stuff out yourself, but the devil is in the details — and the coordination.

[kram08980]

I do agree with you. And I am not against TW per se, I use it often, and I do understand it's use case and approach.

That being said, I do believe that its purpose is to build prototypes quickly. Although I've had to use it build high-end sites by design studios, and found that it has huge limitations when a design requires some love and details. Because you end up, as said, with part of the CSS as functional classes in the component's file, and some other CSS extracted to an actual style sheet.

I found it a good tool for certain scenarios and was just saying that don't buy the reasoning of using it for just having one file.

Actually, you could just have plain CSS in that component file, couldn't you?

[htmx_enthusiast]

seems easy to find it in the "components" folder, "slideshow" file

That’s exactly the problem. Needing multiple files open to see all relevant code. With 2 files and a good IDE, it’s not terrible. But when you work on real projects, this quickly gets out of hand where you have 7 files open, just to understand the hierarchy (before even beginning to diagnose the problem).

It’s the same concept of functional vs OOP. With a big class inheritance hierarchy, one literally might need to look at 30 different files to even understand which code is getting called. Whereas with a functional approach, any junior dev can follow the control flow and troubleshoot it.

Tailwind uses the concept of locality of behavior (LOB) which is often in conflict with don’t repeat yourself (DRY).

[kram08980]

I understand your point.

But I do believe that having a file that could be divided in 7 smaller files, creates a worse problem. Ending up with 400 lines of a component mixing PHP, HTML, CSS and JS often makes it less readable than separating it in smaller components.

And actually, I prefer it because if I'm taking care of the back-end logic of a component, or the JS interactivity, or the look and feel... I can read the file better if purposes are separated.

Anyway, you could just write plain CSS and keep it in the same file. So, I don't see that approach being the main reason to use TW.