Anyone remembers the vanilla tailwind implementation? It's called the `style` attribute.
Tailwind is a leaky abstraction
201–210 of 391 posts
Re: Tailwind is a leaky abstraction
#202These are fairly complex use-cases that aren't needed for 99.9% of CSS people write. In most cases I'm throwing together a handful of components in a flex container or right-aligning some buttons or something. And for that typical CSS usecase, I find Tailwind way better both for quickly iterating and for hopping into code someone else wrote. I love not having to bounce between and cross-reference 2 (or more!) files (…
Tailwind is honestly great for beginners since it "simplifies" CSS into short-hand classes. The people that know CSS don't want to learn new classnames when they can use CSS and that is a standard. I'm personally scared of forgetting CSS if I use Tailwind extensively. I also don't like the aesthetic of all the classnames being bunched together, but Tailwind does have value.
> The people that know CSS don't want to learn new classnames when they can use CSS and that is a standard.
And then they end up with dozens (and in big project hundreds) of bespoke CSS class names that no one can remember or keep track of, and just add new ones to the ever expanding file ;)
Re: Tailwind is a leaky abstraction
#203Earlier 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.
Justifying using Tailwind, Typescript, JS Framework, etc. comes down to how much value they provide to each user and how much time they save.
For example, building your own type system or JS framework would require a lot more code and man-hours than using margin: 4px vs m-2.
Re: Tailwind is a leaky abstraction
#204Earlier quoted context omitted.
Tailwind is honestly great for beginners since it "simplifies" CSS into short-hand classes. The people that know CSS don't want to learn new classnames when they can use CSS and that is a standard. I'm personally scared of forgetting CSS if I use Tailwind extensively. I also don't like the aesthetic of all the classnames being bunched together, but Tailwind does have value.
> The people that know CSS don't want to learn new classnames when they can use CSS and that is a standard. And then they end up with dozens (and in big project hundreds) of bespoke CSS class names that no one can remember or keep track of, and just add new ones to the ever expanding file ;)
This is not the way either. I use CSS-in-JS which has its own flaws, but CSS stays with the component.
Re: Tailwind is a leaky abstraction
#205Earlier quoted context omitted.
I don't think that's true, just by importing the tailwind u add more bytes than plain css which you will end up writing.
Pretty sure tailwind has had the option to have the minimal CSS generated on-demand from the set of classes you actually use, for a year or so. I haven't actually tried using this feature yet though (haven't had time to upgrade tailwind in the project where I've been using it). I suspect writing your CSS by hand could still be more efficient in per-byte output, but not enough to justify the productivity loss from not…
Someone can fact check me, I'm going off memory: I believe in v1 Tailwind (before they added the "JIT" compilation) when you were in dev mode it just had all the classes available at all times, and then added a step to the prod build where it would purge unused classes from the CSS.
Now Tailwind scans for which classes are used as you add them and builds an output from that. So if you only used `m-auto` the only CSS it would output in the final build is
.m-auto {
margin: auto;
}Re: Tailwind is a leaky abstraction
#206Earlier quoted context omitted.
Maybe I'm going out of a limb here, but wasn't the whole point of CSS to not have to touch the markup when changing the styling? Not trying to talk Tailwind down, I have just missed a lot of the evolution of web design in the past 15 or so years.
I've never understood the point of separating markup from the design. I've seen CSS Zen Garden and... neat? But I don't get the point in real-world use. I've never had to redesign a UI in a way where I'd only change CSS and not also be moving around markup in the process. And once you're changing both of those things, there's the overhead of cross-referencing and keeping names and hierarchy in sync. At that point I d…
The question of where to put the styles boils down to "do your content and style people work in completely separate teams?" For a newspaper, this is true. For someone who got their mate to set up their blog, this is true. Early days web was mostly like that. Not any more. If it's the same person doing it, put it in the same place. Separation will just be a hindrance.
Re: Tailwind is a leaky abstraction
#207Earlier quoted context omitted.
> The people that know CSS don't want to learn new classnames when they can use CSS and that is a standard. And then they end up with dozens (and in big project hundreds) of bespoke CSS class names that no one can remember or keep track of, and just add new ones to the ever expanding file ;)
This is not the way either. I use CSS-in-JS which has its own flaws, but CSS stays with the component.
That's why the wink ;)
I used to sort of like CSS-in-JS, but on larger projects it also quickly devolves into "I know we have a design system, no idea what we have there, here are one-off CSS styles for this particular component"
Everything is with its trade-offs alas sigh
Re: Tailwind is a leaky abstraction
#208These are fairly complex use-cases that aren't needed for 99.9% of CSS people write. In most cases I'm throwing together a handful of components in a flex container or right-aligning some buttons or something. And for that typical CSS usecase, I find Tailwind way better both for quickly iterating and for hopping into code someone else wrote. I love not having to bounce between and cross-reference 2 (or more!) files (…
> I really feel like people start with their conclusion that they don't like it because it's weird and foreign and then look for excuses to justify why they think it's bad.
At least from this article, I get the impression the author used tailwind for a bit and kept running into these issues where he had to go in and fix it manually in CSS. After enough of these, you get annoyed.
Re: Tailwind is a leaky abstraction
#209Earlier quoted context omitted.
You could just use that subset of CSS though. If fact it’s a genuinely good idea to do so. Grid first, using paddings and gaps can do almost everything you can draw 1:1 without hacks. No margins, no clear fixes, no floats needed.
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…
I really relate with your example here. Adding padding/margin is such a common task, it should be quick & easy.
Re: Tailwind is a leaky abstraction
#210Earlier 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 have only used Tailwind on personal projects, but I can't imagine it'd be harder than "regular" CSS, which is generally somewhat append-only anyway (you need a lot of team discipline to tame that somewhat). In fact, I'd expect it to be more maintainable, exactly because it removes the indirection of CSS classes. They're an abstraction that don't make much sense if you're already using components, and the very point…
If only there was a DOM-aware CSS linter.