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.
If you decided to do a project in vanilla CSS, I'm sure the style names would come back very quickly.
I don't think Tailwind is the place to start learning CSS. Tailwind is just a more efficient way to write CSS, and you should be aware of what's going on under the hood. It doesn't mean if you're writing your CSS in Tailwind you're never gonna look at normal CSS. There's plenty of times when I'm iterating on a design and I'll hop into the "Styles" section of my console and directly edit the element.style{} section, writing normal CSS to mock something out before translating it back into Tailwind in my editor.
So I certainly haven't forgotten normal CSS names. Not to mention the Tailwind names generally match up pretty closely with the underlying CSS names. It's only minor translations to go between the two, and maybe a special case here or there. The documentation[1] is very good with a quick search can type CSS or Tailwind names into to find what you want, and it'll show both the Tailwind name and the CSS attributes/values it outputs so I tend to keep that open in a tab while I work.
As someone who has been writing CSS for approximately a billion years (actual number more like 13 years) I'm a fan of Tailwind and don't see how it's a 'beginner' thing at all. It solves real-world problems building web applications, and actually many of those problems only come up when you're building large, long-lived applications with many contributing developers which is precisely the kind of thing beginners aren't in charge of.
> 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.
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.
[1]: https://truerev.com
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.
What it does is ensuring Locality of Behaviour, and css properties not leaking in other component of a web application.
It's essentially the same as css scoped to a single component.
If you copy the examples in the Tailwind docs it looks like your ripped off Stripe. If you copy the examples in the MDN css docs it looks like you ripped off a decade old govt site.
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 ;)
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
What are the benefits you're getting from CSS-in-JS?
Emotion isn't without it's flaws though. The company that created Emotion doesn't use it anymore because of runtime overhead[2] so Tailwind may be the future after all.
[1] https://emotion.sh/docs/introduction
[2] https://www.infoq.com/news/2022/10/prefer-build-time-css-js/...
Oh wow. Literally this is the exact argument I use for not using tailwind. Not saying either of us is right or wrong it’s just odd how different people perceive things.
Yes, you will have to know what the classes do, but where that isn't already intuitive it's just a one-off lookup, and then you know.
HTML + CSS can simply not be parsed without hoping between multiple files. Unless you inline all of your CSS, of course.
You have styling split between the classes and the actual CSS tailwind implements, which every team I know that has used tailwind absolutely does have to look at.
<div class="flex gap-x-2">
display: flex;
column-gap: 0.5rem;
[2]: https://tailwindcss.com/docs/gap
Edit: formatting
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.
If they're typical things that you'd expect a library to solve, sure. If they're "I want my element to rotate in 3D" then most developers would think they're just working outside of the scope of the library.
Which... is asinine. One is simply a redacted and simplified expression of the most common implementation of the other case.
Tailwind falls into the same bucket - in my opinion. Like most frameworks, it's not there to handle your niche and complex use-cases. It's there to provide bumpers that push you into a pit of success for common use cases.
When you need to do something that's not common - use the escape hatches that are built in. That's not leaking - that's giving you the flexibility to fall back to a custom implementation.
The goal just isn't "abstraction" from css. It's common-sense, local, and consistent styling for common cases. I can build most lego sets from single square blocks - but it's nice to have a bigger selection available. Does that mean I need to understand those bigger pieces to make sure they fit, don't have weird gaps, and line up? Absolutely. Does that mean I shouldn't use them? No, probably not. But it does mean that sometimes I still need single square blocks.
Let’s look at typescript, or sass. There is (afaik) no construct in the underlying js or css that cannot be represented using them.
You could conceivably never learn javascript, learn typescript and basically be fine.
So when people say “leaky abstraction” they seem to be assuming that tailwind, which is a framework will allow you to represent every possible css output.
…which it can’t do, obviously, and was never intended to do.
All I’m pointing out is that the expectation that it could might not be quite so daft when viewed from the lens of “I expected tailwind to be a framework in the same way sass is” or perhaps “the same way this framework that compiles using sass is”.
It’s like if I was using vue, and found that the template language can’t express complex logic without writing js (h() expressions) and not using the template language at all.
It’s wrong to say it’s a leaky abstraction; but it’s maybe not completely asinine to say, it a bit rubbish that you have to do that as soon as you hit any non trivial use case…
> Like most frameworks, it's not there to handle your niche and complex use-cases. It's there to provide bumpers that push you into a pit of success for common use cases.
…but as you say. Quite so. Im just saying I can see the frustration people encounter when they have the naive expectation that those edge cases are rare enough they’ll never hit them, and then immediately run into them.
I don't love Tailwind, but I can understand the spot it's trying to fit in, and I value the things it's trying to offer (locality, consistency, sane guidelines).
I think the sweet spot for that value proposition is projects where the designs don't need to be pixel perfect or extra fancy - they just need to work, quickly. I've used it successfully several times in those cases. Not to mention personal projects where just having a decent template made that I can tweak is great.
I would probably not use it anywhere you have real UI constraints or concerns, and you care a lot about specific animations or exact pixel placement. I tend to reach for styled-components in those spots these days. Since it gives me a fair share of the same value proposition (locality, consistency) but removes the guidelines/bumpers.
They play pretty nicely together (with some constraints), though - again, use the different lego blocks where they make sense. Stop trying to treat everything like a tailwind shaped nail you have to beat in with just that hammer.
You can play this "leaky abstraction" game with almost any concept, without the ability to reach down an abstraction level you lose flexibility. Its not a smell to be slightly leaky.
All abstractions are leaky; some are useful
Also, it makes me sad to see people so eager to throw away separation of concerns :( Yes everything describing it is on one screen but now your HTML is filled up with hundreds of words of awful classnames and markup that should have been put elsewhere!
Having a neatly encapsulated component that does everything is fine in most setups. Your main challenge will be not growing these components too big.
(( I really dislike Tailwind btw, mostly because I am just translating CSS into something else all the time which feels like a waste of mental effort; and the long lines of cryptic classnames is just bizarre to gain such a big popularity. I loathe it, it's a maintenance hell. I imagine all frontend devs liking this grew up using Bootstrap or something and mostly do small projects ))
Yikers this comment sets the stage for a real bad game of phone tag! I think you're mistaking TailwindUI[0], the set of proprietary UI component cheat codes based on top of TailwindCSS, with TailwindCSS[1], the actual CSS library being discussed here.
I don’t think it has ever lived up to expectations, HTML+CSS in that way is simply broken. You can’t really write CSS without hard-coding the HTML structure, so you might as well do it in one file.
I don't see the issue with 'separate files', do people not use split view mode in their IDE?
edit- this comment in another thread: https://news.ycombinator.com/item?id=33789859
The problem with reusing CSS comes, when the style you’ve previously created, is almost, but not exactly perfect for the current component. Changing it to better fit you current need risks breaking existing layouts, and so you are left with overriding it. But when you do that, you eventually end up with a lot of override classes just to change one or two things. So, what do you name these classes? If you name them for what they are intended for (ie. “semantically”), you are bound to end up with a lot of differently named classes, that all do the same or nearly the same thing, because it turns out that we commonly want to override the default styling in very similar ways. You end up with dozens of one-rule classes that all just set float to right or display to none. Alternatively, you name these overrides for what they do. This way, whenever you need to float something right, you just add the `float-right` class to the element. You can now eliminate all those redundant semantically names override classes. But if you go back to the classes you started with, it also turns out that those would have been a lot more reusable if they’d contained fewer rules to begin with. This makes sense, because more rules = more specific, and fewer rules means more general. At this point, I’m sure I don’t have to point out to you, that you’re well on your way to reinventing Tailwind.
I'm my experience the _vast_ majority of CSS never gets reused. Sure if all you are building is marketing websites or landing pages then I suppose some generic "cards" or whatever will get you pretty far, but for anything even moderately more complex... no chance
Maybe it would've been possible to build tooling around using CSS files that created the same benefits, but now we just don't have to any more.
This type of drama or negative style of writing needs to stop. Be objective, there is good and bad everywhere.
Practically none. And any designer is prone to reuse the same spacings from project to project. So you bring the language file with you. Something like this :
:root { --spacing-sm: 1rem; --spacing-md: 2rem; --size-tall: 32px; ... }
And you can do some pretty nice things with these pure CSS tokens. Without any hassle or dependency.
Say I have a button component with different variants, these variants change styles across multiple elements in the component.
Using scss and BEM this is incredibly simple, add a parent class and I can modify nested elements easily. But using tailwind I have to make an mess of things to get this working or recreate the component.
I’d love to hear how anyone solves this issue.
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 (HTML + CSS) for a description of a single layout.
I started using Tailwind at my job I started 2.5 years ago and after the learning curve of memorizing the commonly used class names I have yet to run into a situation where I wished we weren't using it. I also started adopting it in all my personal projects because it makes me so much faster at getting work done and the code is easier to maintain.
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.