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…
Working with Tailwind CSS every day for 2 years
191–200 of 215 posts
Re: Working with Tailwind CSS every day for 2 years
#192This 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.
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.
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
#194Re: Working with Tailwind CSS every day for 2 years
#195Earlier 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…
Re: Working with Tailwind CSS every day for 2 years
#196Having 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
Re: Working with Tailwind CSS every day for 2 years
#197Earlier 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…
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
#198Earlier 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…
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
#199Earlier 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…
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.