211–220 of 391 posts
If you've gotten to the point where you're complaining about Tailwind CSS being a leaky abstraction, shouldn't the answer be obvious? Just use CSS.
Earlier quoted context omitted.
There's a meaningful difference to my workflow of doing versus doing .mycomponent__wrapper { padding: 0 1rem; // Don't forget the time to look up whether it's vertical | horizontal or horizontal | vertical because I forget all the time } then and toggling between files, and making sure the team knows my preferred CSS layout structure in the general case. Plus, the solution for more complicated CSS is to just write it…
Regarding the choice of class names: you are using using wrapper elements routinely, outside absolute edge cases like border gradients, you don’t have current CSS skills. As mentioned previously current CSS means you can have a 1:1 match of HTML element to UI element for the vast majority of layouts, no wrappers required. Current gen frameworks will put the styling inside the component so styling is literally a matte…
Now if there is a go-to-definition for CSS classes, that would be quite useful. But I appreciate that I don't have to even think about putting a name to my styles with Tailwind.
Earlier quoted context omitted.
Tbh a lot of times when people say beginner they really mean “this is way easier than the way I’m used to, and that freaks me out because it means the old way is redundant, so I’ll claim this is for beginners”
By beginners, I meant people who know HTML and some CSS, but not enough to design a great UI. Tailwind allows them to add a few classnames and the page looks great. On the flip side, you have a developer who can design using CSS. Tailwind comes along and, although it’s great, you’re learning new classnames and now you’re no longer using web standard properties (CSS).
> Tailwind allows them to add a few classnames and the page looks great
How is this the case any more than "raw CSS allows them to add a few styles and the page looks great"? You can't just haphazardly throw styles onto the page and it'll magically look good cause it was made in Tailwind. You design the exact same way you would if you were writing raw CSS, it's just you're putting the styles in the HTML class tags instead of modifying the CSS directly.
A person who's bad at CSS is not gonna be any better with Tailwind.
Tailwind is super effective at inlining the common, basic CSS tasks. Further, Tailwind does nothing to prevent you being able to write good ol' CSS.
The examples OP have picked feel niche, contrived, and likely solved in better/simpler ways. I would never dream of writing something like this:
"lg:[&:nth-child(3)]:hover:underline lg:[&:nth-child(3)]:hover:font-bold lg:[&:nth-child(3)]:hover:text-blue-600 lg:[&:nth-child(3)]:hover:opacity-100"
That's just bad CSS. That's not bad Tailwind.
Tailwind is not an abstraction, it's shorthand. It saves you several bytes in the source, saves seconds of typing, and in return rewards you with a massive headache.
Earlier quoted context omitted.
After trying out Tailwind in one pet project I have to say that for larger teams it should not be used. Looking at the code now I get the feeling that maintenance would be a big problem. A bigger project with multiple pages having full on Tailwind css classes peppered everywhere looks to be a nightmare. Does anyone have experience jumping into an existing larger project with legacy tailwind all over the place? Would…
I've had some experience migrating large UI projects at work to use a design system based on Tailwind. Haven't faced any issue with Tailwind at all, even while integrating in existing projects. Tailwind is a different way of writing CSS, with some guard-rails coming in from the design system consistency. Tailwind also provides sane defaults (rem over px, for instance). If someone's bad at writing or thinking in CSS,…
Good idea, but importantly only applies to flex and grid layout, not paragraph-like blocks of content.
It is not a good practice to use flexbox for layout, especially if there are nested flexboxes. It takes a lot of time to recalculate such a layout, which can be seen when resizing a desktop browser, or when advertisements load on the page and the layout shifts.
”Write symmetric CSS. Prefer px over pl or pr, mx over ml or mr etc.”
Usually but not always. For example, text boxes can look more visually symmetric with less padding on the ragged side, while interaction-heavy mobile layouts may want to have a larger padding on the right to give the user something to safely scroll.
Earlier quoted context omitted.
By beginners, I meant people who know HTML and some CSS, but not enough to design a great UI. Tailwind allows them to add a few classnames and the page looks great. On the flip side, you have a developer who can design using CSS. Tailwind comes along and, although it’s great, you’re learning new classnames and now you’re no longer using web standard properties (CSS).
By that definition it would be hard to justify anything besides HTML, JS and CSS. That would also exclude TypeScript and every JS Framework there is on earth. That's hard to justify from every angle (development and business wise) imho.
With Tailwind, whatever the actual merits, the biggest points of traction (IMHO) are the frankly excellent example sites[1]. You can click through numerous examples, all load quickly and without ads, that give you numerous variations of components, layouts, and even full pages. You can spin up a vanilla HTML or React app and ship good looking pages very quickly, esp. if you are bad at design.
As for the mentioned nested selectors (which I'm a huge fan of), in the next version I'd like to see grouped nested selectors. So instead of:
[&>div]:mt-4 [&>div]:bg-white [&>div]:px-2
[&>div]:(mt-4 bg-white px-2)
Earlier quoted context omitted.
There's a meaningful difference to my workflow of doing versus doing .mycomponent__wrapper { padding: 0 1rem; // Don't forget the time to look up whether it's vertical | horizontal or horizontal | vertical because I forget all the time } then and toggling between files, and making sure the team knows my preferred CSS layout structure in the general case. Plus, the solution for more complicated CSS is to just write it…
Regarding the choice of class names: you are using using wrapper elements routinely, outside absolute edge cases like border gradients, you don’t have current CSS skills. As mentioned previously current CSS means you can have a 1:1 match of HTML element to UI element for the vast majority of layouts, no wrappers required. Current gen frameworks will put the styling inside the component so styling is literally a matte…
Also means you have to think of a name for every component you want to apply style to which is surprisingly tedious.
I love CSS, I'm relatively good at it. Didn't enjoy Tailwind until I really did. Working on a frontend project with other people Tailwind is fantastic. Everyone can see and understand what I've done and there's no trying to understand other people's style sheets, or see what they've done or anything else (especially with the VSCode plugin that orders the Tailwind classes properly). Sure, pure CSS does some bits bette…
Presumably the next dev you will hire will be a frontend engineer? CSS is a core competency for a frontend engineer, whereas Tailwind is an add-on. If I were choosing a frontend engineer for my team, I would make sure there core competencies are up to snuff.