Live data from Hacker News

Working with Tailwind CSS every day for 2 years

themosaad.com

191–200 of 215 posts

Re: Working with Tailwind CSS every day for 2 years

#191

I really like Tailwind, I see a lot of hate in this thread so I'll try to offer a counter-perspective. First of all, it's important to understand what Tailwind is good for, and what it's not good for. Tailwind is NOT a design framework. It doesn't dictate the "theme" of your app. I like to think of tailwind as a tool for writing "clean" css that encourages good UI/UX practices. We need to stop comparing it to Bootstr…

I have a lot of custom stuff like breakpoints and typefaces and new sizes. If your designers can work with the tailwinds configuration file it shouldn’t really be a problem

Re: Working with Tailwind CSS every day for 2 years

#192

This style comes and goes. Utility classes. Then a framework like bootstrap comes up. Then it’s back to utility classes. I feel like I’m taking crazy pills

> I feel like I’m taking crazy pills You're not. If you look hard enough, long enough, you'll see this same pattern in every corner of programming. Round and round, never forward.

Funny you said that cus there’s another “look ma no framework!” Thread today.

Re: Working with Tailwind CSS every day for 2 years

#193

> This plugin would allow me to use my existing CSS knowledge by writing: > Instead of: But... why ? I just don't get tailwind.

My gripe is that it’s stuff I don’t always have to care about. If I’m not working with CSS it’s just noise.

Whatever way that’s refactored, I only want to see that when I’m working with the styles and I don’t wanna do anything special for it either.

Re: Working with Tailwind CSS every day for 2 years

#195
post #164

Earlier quoted context omitted.

Also, I did look at the docs and there is an entire page dedicated to this subject that you can read and it does mention @apply. https://tailwindcss.com/docs/reusing-styles#extracting-class...

Thanks. I did overlook that. Although, the docs are a bit foreboding. "Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse." Then it lists a bunch of reasons that seem to just be the author's preferences on things like naming and workflow productivity. I guess I don't…

I didn't think naming things was that hard, until I got a chance to try building a project without having to name things. I'll never go back.

Re: Working with Tailwind CSS every day for 2 years

#196
post #31

Having used both Tailwind and a more traditional scss system in the past. I think my personal favorite is styled components[0]. It strikes a good balance between not having to move between many files, like you might find your self doing with traditional css/scss system. While being declarative and semantically easy to read. It is not perfect by any means, and in larger components/pages it can lead to some pretty long…

You could combine styled-components/emotion with something like open-props[0]. You get all the power that comes with CSS and a set of variables to help you create a consistent design. That's how I manage my styling. [0] https://open-props.style

Ooo, that is very interesting. I will have to give that a shot, thanks for sharing!

Re: Working with Tailwind CSS every day for 2 years

#197
post #170

Earlier quoted context omitted.

I agree that some of it is preference, but the main point he is making is that the number of utility classes doesn't matter if you're using a framework and styling a component. Yeah, it's ugly markup but so what? With that said, I think it's reasonable to roll some things up into general classes. They remain very easy to change. >I haven't seen anyone argue not to use React or Web Components because naming a componen…

Got it. So this would be more of a hybrid approach and clears up that question on naming granularity. Give the "component" a logical name and use the utility classes for the component's entities. That makes a lot more sense to me. I didn't realize those child entities were the things people were giving names to. CSS has fairly rich ancestry rules, so I just assumed people use them. Thanks for taking the time to clari…

I still think you're misunderstanding. It sounds like you think that the component has a class and everything flows from that. Like .component-name a {}

The point is that HTML elements don't need to have semantic class names at all. So even the top most element in the component would still use utility classes.

Re: Working with Tailwind CSS every day for 2 years

#198
post #126
post #80

Earlier quoted context omitted.

> Spamming utility classes causes horrible git commits, git history, git difference checks; As opposed to what? This is still an issue with any kind of utility class, where the alternative is inline styles or CSS-in-JS, both of which are substantially worse. > Conflicting utility classes aren't clear, and sometimes the order cannot be trusted; This is fixed in the IDE with tools like ESLint. I have VSCode setup to au…

> if you use tailwind correctly (with @apply) you only have to update it once. "Whatever you do, don’t use @apply just to make things look “cleaner”. Yes, HTML templates littered with Tailwind classes are kind of ugly." That is straight from the Tailwind docs: https://tailwindcss.com/docs/reusing-styles Using @apply a lot just reinvents CSS; that's not the point of Tailwind. I can write similar comments about the res…

> If you’re going to use @apply, use it for very small, highly reusable things like buttons and form controls — and even then only if you’re not using a framework like React where a component would be a better choice.

I would say the documentation adequately responds to your complaints about re-usability then? Use a component, use the IDE, or use @apply. The notion about needing to change classes 1000 times for a small edit just isn't true (I've never had to do this w/ 2+ years of tailwind).

> I think you're too narrow minded to accept any input so I won't bother.

Making some sort of ad hominem attack about how I'm narrow minded is useless. I'd love to hear your input.

Re: Working with Tailwind CSS every day for 2 years

#199
post #141

Earlier quoted context omitted.

You manage this complexity the same way you manage the complexity of repeated code nearly anywhere else: you encapsulate. If you have a standard box (div + styles) that you use everywhere, abstract it in whatever way you're writing your application allows. For example, a component in React.

Or...a CSS class? I think the point is that CSS already has the means for abstraction built right in. Using an application framework in order to abstract a list of styles adds unnecessary complexity that compounds upon itself. Somebody writes a React component to abstract a button and its standard styles, and all seems simple enough. Then we need marketing styled buttons, and buttons that are anchor elements, and one…

That seems to be a straw man its never just plain html and CSS. Even if it were, what you describe just devolves into dozens of similar or slightly different (many times by mistake) classes that all need to be maintained.

I would much rather dig into a component that has been built to be flexible for all of those needs to keep it up to date, restyle of add new behaviors and designs requirements vs going through hundreds of html files looking for all of the classes that were created to do those variations you list above (including effectively duplicate (or worse yet cascaded with different behaviors to accommodate the different html construct they were placed on when created).

I really did dislike tailwind from first learning about it, but using it has turned me on it 100%.

Re: Working with Tailwind CSS every day for 2 years

#200

> This plugin would allow me to use my existing CSS knowledge by writing: > Instead of: But... why ? I just don't get tailwind.

This is far from being the best example of WHY you should use Tailwind CSS. I wrote about the HOW. I'll try to write another article about the WHY soon.

I think something clicked yesterday after reading a comment. It works for SPA/css-in-js/components-based projects, and this long class string is manageable as long as it is only present in one single place in the whole project (thinking about versioning and the mental model of where's what).
Post reply on HN