Tailwind CSS v4.0 Beta 1(tailwindcss.com) |
Tailwind CSS v4.0 Beta 1(tailwindcss.com) |
> Installing with Vite
What the hell is Vite? Oh, it seems to be something you need to install via npm.
I cannot help but to ask - why do we require npm, or Vite, for something that looks like it should "help" with CSS?
Why is the webdev such a shitshow, that seems to get ever deeper into its own weird rabbit hole?
As for why it requires npm: I dislike the Node ecosystem as much as the next guy, but it’s a tool used for web development. Where else are you gonna install it from?
Thankfully, tailwind is available directly as a downloadable binary. Unfortunately the link in their beta docs is buried, and also broken -- the correct link is here:
You'll notice that Bootstrap CSS includes every single utility class within Bootstrap. This is fine, but it could be a lot smaller - reducing page load times for clients and data transfer for servers - if the CSS included by a library was solely the CSS used by one's site, and no more. This is why we web developers use an npm/vite build step generally, even if our out is very plain static HTML/CSS.
"Well why can't I just use Tailwind like I do with bootstrap? I just want to play around with it and not have to learn all that build stuff."
You can: https://tailwindcss.com/docs/installation/play-cdn
You'll also notice, if you search for Bootstrap today, that it expects one is using npm and webpack, parcel, or vite.
For perspective, a build process that removes unused tailwind classes can result in .css files of around 10kb. But a .css file with entire tailwind framework is about 2.5MiB.
It doesn't? Most of my clients and websites I saw just use the bundle.
https://getbootstrap.com/docs/5.0/getting-started/introducti...
The docs don't expect any complicated tooling.
a (CSS) code generator.
It happens to be written in JS so it can be integrated as part of existing build steps or bundling. That's the rationale behind it. :) It's build-time, not something client-side.
Shows that the "bloated" way of doing things is now the norm.
It's also not a requirement. The binary still exists, you can run it standalone.
Why do I need a car key and worry about gasoline? I can just hop on a horsie and ride away!
Hey, I yearn for the days of good car analogies too. But the car key is not an essential part of the car experience, rather a necessity borne of the distrust of follow man.
Getting started ->Installing with Vite ->Installing with PostCSS ->Installing the CLI ->Upgrading from v3
At the bottom of the CLI paragraph it says "You can also download standalone builds of the new CLI tool from GitHub for projects that don’t otherwise depend on the Node.js ecosystem."
They just put the most common stuff at the top, because that's what most devs will use.
Surely we can agree that distributing shared libraries via a package manager is a good practice, no?
Surely we don't need a "package manager" and a "build chain" for this?
Then again, I'm a person that writes any web-related code (HTML, JS, CSS, etc.) by hand.
Where did we take the left-turn of not understanding how things work on the actual tech level? These tools hide all of the actually required steps to npm-infested bloat.
At one point, long ago, you could just download a file, reference it in your index.html, and use it without ever having to worry about updating this package. It had its flaws, but it also had many advantages compared to having an external dependency that might conflict with your version of Typescript, or being highjacked by bad actors.
I don't diss the concept of package managers at all, but there are lots of case where vendoring an external package is preferable than adding it as a dependency.
It's the NPM ecosystem above that's being stupid, and believe that adding more tools and more processing is a good thing.
That's ok, but don't go around spouting nonsense about about investors throwing their money away on js projects.
That’s on you. Vite is the de facto standard bundler today and one of the best things to happen to the frontend ecosystem in the last few years. Without even using it, do yourself a favor and check it out.
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.
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...
for the curious:
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.
And I do agree, that moving to better integration with native CSS is a step in the right direction, very curious about future of v4
[1]: https://adamwathan.me/css-utility-classes-and-separation-of-...
I am glad that they support container-queries[1].
But all the real goodness is in contain[2] (which sounds the same but is not related).
Tailwind really needs to support contain. I am disappointed by their statement that there will be no major additions, because contain is really that important - both from a dev perspective, and from a performance perspective. It belongs in v4 from the start.
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_contain... [2]: https://developer.mozilla.org/en-US/docs/Web/CSS/contain
Bring up any said problem and I'll give you an efficient, robust, fast, simple and maintainable way to solve it in pure, native CSS (maybe even with further advantages!).
The time has come to embrace good ol' CSS again! Heheh.
and now you have 100 flags across 5 configuration files and dont know which one to change to make everything work, but changing it might break the ability for a random dependency to compile, and even if you get that to work it turns out your project doesnt render anymore
Looking at the alternatives I was considering Vite with React and Vue plugins (and try to migrate my code so it works by default without any other configuration in Vite) or try Astro (because I have Vue and React) with their default configuration, but still not sure what would be the best option.
If it where just for me I would rather use React like framework (while I don't like that much React) but at least bun supports JSX out of the box and they seems to be working towards having a bundler integrated.
Tailwind is by far the first time I'm productive with styling.
I'm impressed with everything they've built.
CSS modules is a (great) mechanism for providing isolation, very useful in the context of today's component-oriented front end development.
Tailwind provides some (quite good) building blocks for a design system, such as a palette, a sizing scale, values for shadows and rounded corners... and a vast set of classes to apply them. The set of classes covers basically every CSS feature, making it possible to slap everything in the class attribute of your HTML elements and never or almost never have to deal with CSS files.
In other words, CSS modules is a solution for those who love CSS and needed just a way to not deal with naming clashes without resorting to BEM. Tailwind is a tool for those who very much would like to avoid writing CSS
The latter is true either way. These days I’ll use HTMX and let a LLM do the CSS. Unless I specifically have to work on something which faces customers. So I’m wondering if there is some trick to tailwind I’m missing?
If you’re brute forcing Tailwind then you need to study CSS fundamentals. The vast majority of its utility classes are essentially 1:1 translations of CSS properties with some syntax sugar and DX improvements. Translating them to custom classes is a mechanical process even without @apply. There are even browser extensions like Windy that can rip HTML elements with arbitrary CSS to Tailwind classes.
https://abhisaha.com/blog/interactive-post-oklch-color-space...
A good friend maintains a tool to tinker with various shades/tint of colors with OKLCH https://colorcolor.in
[1] https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...
The reason to use OKLch is so that when using CSS color mixing (via animations, gradients, etc), they look "better", as indicated by the sibling comments.
OKLCH just basically exists because there is a hue change from blue to purple in LCH when the lightness goes less which does not match how humans think of these colors (supposedly, don't know if there is any cultural difference)
So in OKLCH the lighter blue does not look purple like it does in LCH, it looks like lighter blue.
It's part of a wider adoption trend. https://bottosson.github.io/posts/oklab/#oklab-implementatio...
There are three things to consider here:
1. Colour interpolation, as used in things like linear-gradient() and color-mix(). The default of sRGB is not particularly good; choosing Oklab or Oklch instead will normally improve things. Oklch is an okay default these days. I reckon that for most applications, Oklab is better. Oklch tends to be too vibrant in the most extreme cases like #ff0000 → #0000ff. Here’s a simple demo you can play with:
data:text/html,<style>div{width:20em;height:2em;display:flex;align-items:center;justify-content:center;background:linear-gradient(in var(--space) to right,var(--from),var(--to));}</style><input type=color value=%23ff0000 onchange=document.body.style.setProperty("--from",this.value)><input type=color value=%230000ff onchange=document.body.style.setProperty("--to",this.value)><script>document.querySelectorAll("input").forEach(e=>e.onchange())</script><div style="--space:srgb">sRGB</div><div style="--space:oklab">Oklab</div><div style="--space:oklch">Oklch</div></body>
3. Specifying general colours. I’ll be blunt. Perceptual colour spaces are horrible at this. With things like HSL and LCH (and even display-p3 colours), you get values in a known range (e.g. 0–100%, 0–360°, 0–1), and they all work. With things like Oklch, do you know how thin the range of acceptable values is? Just try working with yellow, I dare you, or anywhere at the edges of what things are capable of. As a human, you cannot work with these values. You have to treat them as opaque, only to be manipulated by colour-space-aware tools. To take the most extreme example, take #ffff00, which https://oklch.com/ says is approximately oklch(0.968 0.21095439261133309 109.76923207652135)… whoops, you already slipped out into Rec2020 space. And it goes approximating it to #ffff01, anyway. And fairly minor adjustments will take it out of any current (or probable!) gamut. Just look at the diagrams, see how slim the area of legal values is at this extreme.
Perceptual colour spaces are really good for some things: interpolation, and some data visualisation palette things. But beyond that, you’re in a digital world, and a limited world at that, and they’re actually quite difficult to work with, and you should normally stick with #rrggbb. Especially if you have any interest in working near the maximum of any colour channel.
As an example, look at a place oklch() is used in that document:
--color-avocado-100: oklch(0.99 0 0);
--color-avocado-200: oklch(0.98 0.04 113.22);
--color-avocado-300: oklch(0.94 0.11 115.03);
--color-avocado-400: oklch(0.92 0.19 114.08);
--color-avocado-500: oklch(0.84 0.18 117.33);
--color-avocado-600: oklch(0.53 0.12 118.34);
To be clear: Oklch is way better than RGB for some things, but it’s downright terrible for some purposes (often because you do actually care about the display technology, rather than a theoretical model of how vision works), and a lot of the claimed benefits for some purposes don’t hold up to real analysis.
I'm not seeing much demand for P3 at the moment though. Most designers I've spoke to don't know it exists.
That’s really interesting to think about actually! What kinds of practical things do you think could be enabled by an extremely fast tailwindcss?
Moving from pure JS to Rust also brings performance gains. Even if the main goal wasn't "performance," it's a nice side effect worth highlighting.
--
Bret Victor's Inventing on Principle is probably the best demonstration of why this matters; in the first 10 minutes he shows a very concrete example of an insight that would not have occurred without instant feedback https://www.youtube.com/watch?v=EGqwXt90ZqA
When we're talking about ms the build is not the thing that is affecting your ability to try new things out. It was already so fast it was near instant.
But the moment you need to style real html and not some kind of component structure - you have to look for something else.
If I switch to "old man yelling at the sky" mode I would say that's an example of a nice concept (utility classes) taken way too far.
Like GP said, this kind of specificity is impossible in inline styles altogether which is relevant when not using CSS-in-JS in React et al.
- layout: flex and grid are great solutions, Tailwind just makes them extremely easy to use. Flex and grid are barely unusable without first defining at least 4 or 5 helper classes, more likely a dozen. Tailwind just provides them and makes them easy to use. I never could remember the flex properties, I learned the Tailwind classes I needed in like half a day of practice
- mobile first design: Tailwind strongly encourages mobile first design if you want to do responsive design. It scared me at first because media queries are hard to manipulate in CSS. I've never made a responsive design page faster than with Tailwind, it's insane how easy it is
- dark mode: as simple as `dark:xxx`. The default and dark properties being close together is awesome. As with responsive design, Tailwind prefixes make it so easy to do what's painful in plain CSS
- defaults: having sane, overridable defaults for everything (sizes, colors, whatever) makes the code infinitely more consistent. You barely even need to think about real values, just how it looks, and you have less risk of defining slightly different classes for no reason
- no cascading: CSS cascading makes it hard to reason about styles, and easy to break unrelated components by mistake. It's solved with CSS modules (or even with BEM), but Tailwind just eliminates the problem
CSS has the solutions, it just doesn't make them easy to use.
2. You barely need media queries anymore for responsive design. Auto-adapting flex or grid containers and the use of clamp() reduced 90% of my media query usage. I usually use like 1 to 4 media queries in project (for master layout and responsive nav, for example). And there's a nice side effect to this type of intrinsic design : layout and type is way easier to optimize for every viewport! Mobile first design is really easy to approach in this way.
3. You can apply a dark mode by only switching a theme file with design tokens inside. Way lighter, way easier to read, does not clutter your codebase.
4. As a corollary to the previous point, the defaults you are talking about can be CSS custom properties defined in a theme file as I think, Tailwind 4 will do. You could then use the exact same defaults in native CSS.
5. Simple rules about CSS usage, enforced by Stylelint for example, can prevent the vast majority (and maybe all!) of the cascading problems you mention. Here are some rules and a Stylelint config I posted in a reply below: https://ecss.info. I've got a good track record with teamwork and this config.
CSS solutions may be really easy to use when approached properly. I'm happy to follow up with examples and/or reply to subsequent questions and thoughts!
The other problem is that I don't have a designer and tend to make things ugly given full freedom, but I do want things to have their own visual identity.
1. I address the problem of relevance by inserting the CSS right into the component with a link tag. If the component is not used, the CSS isn't either. A positive side effect of this technique is that you always have an easy access to the CSS by following the link in your editor of choice. As for the relevance of the rules inside the component, the said component should be light/simple enough that this isn't harder that glancing a minute (max!) at both files.
2. You can use Stylelint to ensure adherence to specific rules. I have developed a config aiming to prevent these kinds of problems. You can find rules, guidelines and a link to the Stylelint config (still beta) at https://ecss.info.
3. A CSS theme file with custom property design tokens is sufficient. As I understand, Tailwind 4.0 made the switch to CSS tokens. You can thus use the same naming convention for your tokens in native CSS.
As complementary advantages you get future-proof code, no build step, and a lot less unused CSS (for instance, Tailwind's own homepage sports 85% unused CSS!).
I'm happy to elaborate further or respond to any subsequent questions you may have!
I'd like to not have to read or write CSS. Let's see you tackle that. ;-)
> Most importantly: cached content is no longer shared between domains. This is known as cache partitioning and has been the default in Chrome since October 2020 (v86), Firefox since January 2021 (v85), and Safari since 2013 (v6.1). That means if a visitor visits site A and site B, and both of them load https://public-cdn.example/my-script.js, the script will be loaded from scratch both times.
Most developers know better than to hotlink to an image because it might one day return a completely different image (and potentially an unsavory one) yet they casually use external code dependencies.
It is also why the Dependabot(sp?) that has become so popular among devs makes me nervous. Something automatically updating your dependencies is a recipe for disaster.
the main project I work on uses nx, sst, and pnpm, it’s all tightly coupled. this project is fine for now. just different.
i like to use it with DaisyUI also. the part i like is that all the classes i need are already written so its just putting pieces together.
I think that's what the comment you're responding to meant.
Part of that the tailwind package is doing is making sure that only the relevant tailwind classes are included.
2. Watch Inventing on Principle if you haven't already. Pushing build times into milliseconds or sub-milliseconds enables new capabilities
1. you need to know the specific effects of the individual directives but you don't need to deal with the cascading behaviour and other complexities.
2. you don't need to leave your local markup to make styling changes.
3. you don't need to synchronize selectors across multiple files (non-locality).
And because Tailwind involves a lot of repetition of the same CSS classes for the same markup, it naturally drives you towards defining reusable HTML components that encapsulate the markup and CSS classes.
There are a lot of subtle usability improvements like this that avoid CSS footguns and make dev UX better overall.
2. If you link your CSS inside your component you have a direct access to it. A simple editor split suffice to edit it. I would say that's a pretty standard workflow.
3. You can force (with Stylelint, for instance) the use of scoped selectors in CSS files, essentially preventing any selector spillover (which is a real problem). Scoping component selectors inside the one and only corresponding CSS file is important and achievable without complex code dependencies.
4. The drive to define reusable components should already be natural enough on its own! Heheh.
By approaching CSS with the good tools and mindset, you can have a great dev experience while preventing complex dependency chains, third party rules/lock-in. You can also use the most recent CSS features not implemented in Tailwind (looking at you clamp()!) to provide a better end-user experience more easily.
It's a great time to rediscover CSS!
Also, browsers are insanely good at parsing and applying CSS. You need hundreds of thousands of unique selectors before the browser takes more than fraction of a second to parse and render an entire CSS file.
https://www.trysmudford.com/blog/i-spent-a-day-making-the-we...
You rarely see frontend devs disparaging backend devs for their tech choices.
For example, on the back end in Java there's been just basically SpringBoot for a decade, and as long as you keep up with it's minor changes you're all set.
Its just my lived experience of using node.js build systems
Do the selectors in those style tags not apply globally? How do I prevent contributors (including myself) from accidentally writing a selector that affects HTML in other components? I see ECSS allows plain tag selectors for example?
Isn't the design token variable file quickly going to balloon? As you mention, it looks like Tailwind provides this now as well, but you'll still want to run the build step of generating the minimal style sheet that provides only the tokens you actually use, rather than having to compile that style sheet manually.
As a related question: if you're already running Stylelint, what's the problem with a build step?
And: is the CSS on Tailwind's homepage actually unused, or used in dynamically added HTML? Is the additional download+parse size actually significant, or does it e.g. compress well and not affect performance that much? Throttling network speed at least doesn't result in a terrible loading experience for me, it seems.
2. You could use a build step for this, yes. Personally, I don't because the theme files more or less contain always the same tokens. I rarely add any (colors being the most frequent) and if I do, the cost of it being unused is minimal. My standard full theme file is around 5kb.
3. Stylelint complements my work but isn't necessary. My code does not depend on it to work, contrary to Tailwind, for instance. I'm free to stop using it any time.
4. It's a monolothic file containing all the code needed for the whole site and not only the page I'm looking at now. It may not make that much of a difference in performance, but still, the browser downloads CSS code it does not need now and then must read through all of it to apply needed rules. Not optimal.
By the way, it's great you came back with further questions! Hope to have addressed them at your satisfaction. Still at your disposal if you have more!
But on the ECSS homepage I see selectors like `html`, `.flex-module` or `.is-loading` (I'm assuming `flex-module` and `is-loading` aren't components - if they are, then that sounds like being pushed towards a layer of indirection that I'd like to avoid?) - aren't those likely to affect other components?
What's the disadvantage of not being able to stop using Tailwind at any time? How likely is that to play out?
Why does it matter if something's "not optimal" if it doesn't make much of a difference in performance? (See also: not removing unused styles from your theme files :)
Backend stability has its advantages, but the rapid evolution on the front end reflects a response to real-world challenges—like improving developer ergonomics, addressing accessibility, or enhancing performance. Front-end devs often have to bridge the gap between design, user needs, and tech constraints in ways backend systems rarely have
In the end, the fragmentation you see in front-end frameworks is a strength. It’s not “easier” or “harder”—just different kinds of challenges. Both disciplines are vital, and dismissing one does a disservice to the teams and individuals who keep these systems working in harmony.
I also say C++ is "harder" than Java, and that's not "dismissive" of Java devs. lol. I AM a Java dev. I did C++ for 10 years followed by Java for 25 yrs after that, so I feel justified to have opinions. I could also say Assembly Language was hardest of all but I won't because it might be "dismissive" of any easily-offended C++ devs. :)
1. some simple selectors can be used in specific contexts (like `html` for type inheritance, for instance). `flex-module` is a component name (albeit a very generic one only used for example purposes...) and `is-loading` is a "state class". I use simple prefixes to distinguish between selector types and `is` is one of them.
2. Breaking changes could be introduced through the Tailwind dependency tree. Some update could be necessary to patch an exploit, again breaking functionality. Updates become routinely necessary. Which is not the case for native code. Also, using new CSS features can be more taxing within the TW ecosystem than in with vanilla CSS. In a nutshell, it's about simplicity, maintenance and the perenniality of your code. On the other hand, you may be "lucky" and never experience something like the above. But I'd wager there's more chance that you will than not. At least, my own dev experience tells me this.
3. Well, I'd say it's a matter of scale... I see 60kb of CSS on Tailwind's homepage. If more than 80% is unused, that's something like 45kb of CSS. I think at this amount, you could see marginal improvements in rendering and loading. At least, more than with comething like 2-3kb of unused CSS. Hehe. But yeah, as I said, marginal. BUT! hehe, with a less monolithic approach to bundling CSS, as with links in components, for instance, there's a real gain to be had: the browser delays reading the files not being used in the current viewport. So, if you footer is not displayed in the first screem it's CSS won't be read, accelerating overall rendering. This, in my experience, makes a palpable difference.
Hope I'm being clear, english is not my first language. And thanks for the mental workout! Hehe.