Tailwind CSS v4.0

I’d say it depends on who is paying you. If you have job security and want to tinker, then play with tailwind if you want (most trendy / loud people seem to like tailwind). If however you are working on your own project / are self funded / or have a deadline just stick with bootstrap that you know, and focus on getting your work done instead of bike shedding on the UI

you can use @apply to merge the various utility classes together in to something resembling a name, like

.btn-primary { @apply py-2 px-5 bg-violet-500 text-white font-semibold rounded-full shadow-md hover:bg-violet-700 focus:outline-none focus:ring focus:ring-violet-400 focus:ring-opacity-75; }

But their v3 docs seem to be very against this.

"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."

Reasons:

* You have to think up class names all the time — nothing will slow you down or drain your energy like coming up with a class name for something that doesn’t deserve to be named.

* You have to jump between multiple files to make changes — which is a way bigger workflow killer than you’d think before co-locating everything together.

* Changing styles is scarier — CSS is global, are you sure you can change the min-width value in that class without breaking something in another part of the site?

Yet... my experience using projects that use tailwind is that every button everywhere is styled the same way, but it's repeated in multiple areas. The 'kinda ugly' part, but also... it's repeated in multiple places. Trying to change the universal focus behaviour of buttons in a project like this is hard, because... I can't search focus:outline-none without finding everything that has 'focus:outline-none' on it. I can't just search/replace, because it'll impact other stuff.

So I end up spending way too much time trawling through way too many scattered specific styles all over a codebase, vs having a defined 'btn' style someplace. "well, that's just the project's fault"... possibly, but it seems to be the promoted/preferred/evangelized way of using tailwind, judging by the projects I've had to get involved with the past few years. IME, this approach may have good short term benefits, but poorer longer term maintenance, doubly so when the original people are no longer involved in the project, and outsiders have to come in to deal with it.

Yes, I’m a huge fan of how easy it is to whip up quick isolated prototypes in Claude artifacts.

There’s a risk of breaking changes in libs causing frustration in larger codebases, though. I’ve been working with LLMs in a Nextjs App Router codebase for about a year, and regularly struggle with models trained primarily on the older Pages Router. LLMs often produce incompatible or even mixed compatibility code. It really doesn’t matter which side of the fence your code is on, both are polluted by the other. More recent and more powerful models are getting better, but even SOTA reasoning models don’t totally solve this.

Lately I’ve taken to regularly including a text file that spells out various dependency versions and why they matter in LLM context, but there’s only so much it can do currently to overcome the weight of training on dated material. I imagine tools like Cursor will get better at doing that for us silently in the future.

There’s an interesting tension brewing between keeping dependencies up to date, especially in the volatile and brittle front end world, vs writing code the LLMs are trained on.

Why do you keep saying CSS has “caught up”? Tailwind has always just mapped to CSS, so you’ve always been able to do anything in CSS that you could do in tailwind. What has CSS done that makes you see no value in Tailwind today where you used to see value?