As a once-strident critic of Tailwind for its many failings and incompatibilities with the state of the actually-modern "vanilla" web art, I am <i>very</i> pleased to see the huge strides they've made with v4. Being able to access the Tailwind theme through native CSS variables (they even have an example in the docs of a button component written in native CSS in an external stylesheet using native variables! Oh happy day!) is absolutely massive, and being able to use a CSS-only config is equally amazing. Finally, Tailwind feels more like it's a utility (ironic, since its claim to fame is utility classes!) which you can add to any project, rather than some bizarro "viral" framework that wants to eat sensible architectures and lives in its own JavaScript-y silo.<p>Perhaps all the criticism over the years actually had an effect. Or maybe they finally arrived at good conclusions on their own. Either way, I suspect many of the pro/anti-Tailwind arguments are no longer relevant, and that's a Very Good Thing. Now we can get down to business and ship product.
CSS has become significantly more user-friendly than in the past, with most browsers now behaving consistently. It's worth learning as there is no build step involved, and it avoids cluttering your markup with excessive code.<p>You could opt to use style attributes directly within your HTML. Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar methods. Is it just to save a few keystrokes?
Using style attributes even seems more straightforward since it doesn't require translating code in your head.<p>I simply don't see the appeal.
My initial reaction to Tailwind was: what a pain. I already know CSS, now I have to learn CSS again...<p>I imagine its how parents might feel when they go to help their children with math homework only to find the math is now totally different from when they were in school and their methods (while still valid) for solving problems are no longer accepted by the school and their child is annoyed by having to reconcile the two systems...<p>I get the, tailwind works well in a team and scales nicely and you just have to use it, mentality. I've experienced it.<p>I still prefer a plain style sheets that targets elements by a class or tag (especially since CSS supports nested selectors!).<p>There is an issue in managing stylesheets, and for that I really like how Remix/React Router manages CSS where CSS flies are defined and applied at the route level. Where that isn't enough or dynamic styles are too complex for a .css file:<p><pre><code> style={{...}}
</code></pre>
is always available.<p>CSS is so powerful, flexible, and extensible, tailwind feels like a limitation rather than an enhancement. I don't understand the continued appeal, but clearly many others do. I'm not sure why, but I am confident we'll all have moved on to something else in another 3 or 4 years too.
I love tailwind, used in 3 projects in the past 4 years, it’s intuitive, well documented, simple. I don’t miss the days of emotion and styled components where I would have to think of a name for every styled div in the project, with tailwind a container is just a div and a few classes nothing else. Less bike shedding discussion, less brain cycles spent naming things, less time wasted in reviews.
I used tailwind for my site and ended up liking it a lot, but maybe for reasons that are not often mentioned? The real value of tailwind is being able to read all the styles that affect a an element in one place. Sure the classnames can get long, but it’s still a lot faster to read that long line, than open the browser tools each time or scroll up and down one (or many) stylesheets.<p>Then when you come back to that code later, you can confidently edit it without worrying about causing changes to other elements.<p>The cascading nature of CSS is still helpful, but I find that I usually want to limit my styling to just one element. For all the rest I go back to css but I wrote very little css because I usually just want to get the whitespace right.
"Build times reduced", "no more @tailwind directives", "No more js configuration", "Designed for the modern web".<p>To me, this screams "CSS now can do everything we used to do ourselves, but let's keep pretending that we are still needed somehow"
Question for people who are good at CSS stuff. I am not.<p>I'm upgrading a personal Phoenix project to 1.7, and Phoenix now uses Tailwind by default. So I thought I'd try and update my one page thing to use it instead of Bootstrap.<p>So far, it looks like crap whereas the Bootstrap one looked 'good enough'.<p>What's the easiest way to get something that looks kinda sorta decent, with some nice defaults, without trying to become a designer?<p>Or should I just reinstall Bootstrap and be done with this.
There's a clear pattern in every "Tailwind or not tailwind" conversation (which happens everytime Tailwind is mentioned).<p>There's those that never used it for more than 30 minutes, that just tried it out or just skimmed through the docs. Those are the people that hate it and prefer "vanilla CSS" or similar.<p>Then there's the people that actually used it for a real project, within a team with more than 1 single person. Those are the people that understand its value, accept its trade offs and love it.<p>I've seen a lot of people jump from the first group to the second group. I've seen almost none jump from the second to the first.<p>That's why Tailwind is so successful.<p>It might not be beautiful in the eye of the purist, but it's absolutely fantastic in the eye of the builder and pragmatic.
I appreciate there are people who find Tailwind useful and are productive with it, but it has this clean yet generic look that I now see everywhere, because Tailwind is now everywhere.
Tailwind is a testament to the greatness of inline styles (styling a thing without naming it), the universality of strings and also the limits of strings.<p>I am excited for what comes after it, until then I'll use Tailwind (reluctantly)
Was it really necessary to break all existing apps using `npx @tailwindcss`?<p>It's an easy enough change to `npx @tailwindcss/cli` but we now have to go back and update all Apps and templates and since it uses v4 we now have to test every App to see if anything's broken with a v4 major release.<p>Given its massive install base, surprised they wouldn't maintain backward compatibility with v3 and have an explicit opt-in upgrade path to v4.<p>Edit:<p>v4 did actually break all our Tailwind Apps which doesn't support `@import "tailwindcss"`, likely because we use `npx tailwindcss` without any local npm dependencies. Trying to use the existing v3 `@tailwind components` renders a useless app.css. Only solution atm is to explicitly use v3 and change all our build scripts to use `npx tailwindcss@v3`.
Tailwind’s abuse of CSS classes as a DSL has always felt like a hack to me.<p>You shouldn’t need a special editor extension to get highlighting/autocomplete/etc, just use TypeScript and a CSS-in-TS solution.
Thanks Tailwind devs! It’s a testament to the success of the concept and the quality and consistency of execution over a seriously long time, that Tailwind became how LLMs write code for the web.<p>Congrats on the release.
Migration guide, if anyone is wondering: <a href="https://tailwindcss.com/docs/upgrade-guide" rel="nofollow">https://tailwindcss.com/docs/upgrade-guide</a><p>Some breaking changes in there. May want to hold off on upgrading until LLMs come around to writing v4 code with ease.
Question for those developers who, like me, have no f/end build step: How would I use tailwind without a f/end build step? All the examples of using tailwind 4.0 on the linked site assume a f/end build step.<p>My project does not use (and I have no plans to include) npm, or PostCSS, etc.
This changes the colour palette <i>again</i>. They do this almost every major release. Starting to become a liability: upgrading will change your colours.
I’m a recent convert to tailwind. I’m very comfortable with css and I was initially turned off on the huge horizontal lines I saw in tailwind projects.<p>However, more and more component libraries are based on tailwind so I decided to try some immersion therapy.<p>Here are the top things I enjoy that was not obvious to me:<p>1. The class names are css shortcuts. Using them save you a lot of time. This is probably obvious to anyone who’s seriously looked at tailwind but I didn’t see that browsing the docs. I just saw nightmarishly long lines.<p>2. The lines look longer when you are not familiar with the class names. I initially pulled all of my class names out into a string outside my markup and included similar to how I’m used to using emotioncss. This made tailwind tolerable for me at first. However after several days I started to feel less turned off by those lines. I think it’s because I could recognize them. I will still break down a line with something like clsx.<p>3. clsx helps so much vs trying to entirely rely on tailwind syntax. The docs don’t discourage this at all but for some reason I thought it wasn’t idiomatic tailwind at first.<p>4. My app has to support a very large number of themes. Tailwind has proven to be a very attractive way of solving this problem. CSS variables are cool but the long syntax of using them is helped a lot in tailwind.<p>5. Adding my own custom variants is so easy and made me feel like a power user with such a small learning curve.<p>All of this is just my two cents to guide anyone who is like me watching from the sideline and wondering why? Why would anyone ever want to tolerate those “disgusting long lines mixed into the html”. Neo, all I see is the lady in the red dress now
Personally I'm not interested in using Tailwind but my main criticism is that it didn't go far enough in its approach.<p>Instead of using classes (which are extremely limiting) they should have created their own language like Imba did (inspired by TW).<p><a href="https://imba.io/" rel="nofollow">https://imba.io/</a>
I think the reason why tailwind is as popular as it is, is because it really ties in with the "change something, save, then immediately see the result" loop and dx of modern day web development.<p>Yes, this works with regular css too but it's the fact that you can do bigger changes inline quickly without making up a class (and god forbid you already have a different class affecting the same element and it gets hairy). Personally I think this is nice, it's great to immediately see results and then adjust. But dx is not the only thing that matters and there are tradeoffs too. Personally I would use tailwind for personal projects but I don't think I would try to introduce it at work.
Locality of behavior can be done with few lines of js.
<a href="https://github.com/gnat/css-scope-inline">https://github.com/gnat/css-scope-inline</a>
I'll stick with 3, not rewriting so much of the codebase because taking away features is now an improvement. Not sure where dogma and performance overlap but it isn't in making @apply a hassle.
Tailwind and Sveltekit are the reason why I still love doing FE after all these years. Initially I was so sceptical of TW. I simply can't work without it now. Huge thank you to authors for their hard work.
Anyone who has ever had to deal with CSS over time knows that the biggest issue is having leftover classes. Utility first approach means this never happens.
I like tailwind but think it’s not needed anymore as CSS got better.
Utility frameworks don’t necessarily need a build step.<p>I forked and finished Tachyons successor Tachyons 5:
It has container queries built in and p3 colors.<p><a href="https://github.com/gobijan/tachyons5/blob/main/tachyons5.css">https://github.com/gobijan/tachyons5/blob/main/tachyons5.css</a><p>If you need very sophisticated layouts write them in plain css. For quick styling utilities are awesome.<p>Unpopular opinion. Now downvote me to the ground.
Last time I tried v4 the automatic content detection was pretty bad. It would falsely detect tailwind classes if it seen a similar name in a string in a code file. It seemed pretty dumb.
Heck yeah, cool to see Tailwind add support for transitions without Javascript.<p>As a burgeoning web developer, dealing with animation libraries seems like it's not worth the effort (or at least not for something as simple as a blog), so this is much appreciated.
Did they really nuke the entire js config file? I have a number of advanced use cases that depend on it, like eliminating false-positive content matches.
Tailwind suits the kind of developers who hack things together and build up technical debt and spaghetti code rather thinking about things first and designing things properly.
Tailwind is mind-boggling to me. Like something that would be written by someone who doesn’t actually write a lot of HTML or CSS.<p>Bootstrap is bad enough, where you end up using 4, 5, 6 classes for display, margin, padding alterations to existing components.<p>It’s just unreadable crap. No wonder it’s popular though. Most people suck at designing. The ones that don’t aren’t using Tailwind.
To some extent, reading between the lines of many of these comments, I think “pure CSS” designers are feeling threatened by the quality level of Tailwind sites designed by the rest of us.