Tailwind CSS v4.0 Beta 1

Tailwind threads usually include comments and questions that are answered in the documentation, so here's some useful links for people that haven't used Tailwind before.

A core part of Tailwind is that you reuse styles by using a templating system vs using custom CSS classes e.g. you have a button.html file that contains the styling for your buttons for reuse, so you don't have to keep repeating the same utility classes everywhere.

https://v2.tailwindcss.com/docs/extracting-components#extrac...

> It’s very rare that all of the information needed to define a UI component can live entirely in CSS — there’s almost always some important corresponding HTML structure you need to use as well.

> For this reason, it’s often better to extract reusable pieces of your UI into template partials or JavaScript components instead of writing custom CSS classes.

@apply (e.g. .btn { @apply py-2 px-4 bg-indigo-500 text-white }) is only meant for reusing styles for simple things like a single tag and is generally recommended against because you should use templates instead:

https://v2.tailwindcss.com/docs/extracting-components#extrac...

> For small components like buttons and form elements, creating a template partial or JavaScript component can often feel too heavy compared to a simple CSS class.

> In these situations, you can use Tailwind’s @apply directive to easily extract common utility patterns to CSS component classes.

Inline styles can't be responsive and can't target hover/focus states e.g. there's no inline way to write "text-black hover:text-blue py-2 md:py-4 lg:py-5 lg:flex lg:items-center" and the CSS equivalent is very verbose.

https://v2.tailwindcss.com/docs/utility-first#why-not-just-u...

> But using utility classes has a few important advantages over inline styles:

> Designing with constraints. Using inline styles, every value is a magic number. With utilities, you’re choosing styles from a predefined design system, which makes it much easier to build visually consistent UIs.

> Responsive design. You can’t use media queries in inline styles, but you can use Tailwind’s responsive utilities to build fully responsive interfaces easily.

> Hover, focus, and other states. Inline styles can’t target states like hover or focus, but Tailwind’s state variants make it easy to style those states with utility classes.

Opinion: As utility classes are quick to type and change, and it's easy to find where you need to edit to change the styles of a component, it's an order of magnitude quicker to iterate on designs compared to CSS that's scattered across files and shared between pages in hard to track ways. CSS specificity and cascading aren't often used, and mostly just cause complexity and headaches so are best avoided. Tailwind-style vs classic CSS is similar to composition vs inheritance in OOP with similar pros/cons, where complex inheritance is generally discouraged now in OOP languages. Yes, the Tailwind approach is going against the standard CSS approach, but CSS wasn't initially designed for highly custom responsive designs so it's not surprising if its "best practices" don't fit everywhere.

Also, Tailwind is really for custom responsive UI and website designs. If your site is mostly Markdown documents and you don't need a custom design or complex mobile/desktop styling, the above isn't going to make any sense and plain CSS or something like Bootstrap is likely a better choice.

I'm really curious as to why they felt the need to work on improving performance.[1]

Were people complaining it was too slow? Were the performance improvements just the benefit of refactoring they did for other reasons?

Considering the build happens once during your build phase, taking under half a second doesn't seem like something I would even bother looking at. So it just jumps out to me, so I'm just curious.

[1] https://tailwindcss.com/docs/v4-beta#new-high-performance-en...

They are switching from sRGB to OKLCH.

First time I heard of OKLCH tbh. Anyone know if that is part of a wider adoption trend or is Tailwind pioneering here?

Looking at the examples it does seem to offer some advantages; but was primarily surprised that they now use it as a default.

According to this article [1] OKLCH accounts for biases in human perception of color brightness. Seems useful, but I don't know the answer to your question.

[1] https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...

I think a lot of the optimization work was for dev time and it carried over to build time. I listened to a podcast interview with Adam Wathan where I think he said they just got really into shaving nanoseconds. They have a very successful business and I think they just enjoyed doing this work. On the other hand I do think even if you’re cutting from 50ms to 5ms (both low numbers in absolute terms) there are often new unforeseen workflows that become possible once you can do that operation so frequently that it’s free. You could do it on every keystroke.