I agree with you in the general case, but many people are going to be using Tailwind as part of a build step, and many of those people will be using Vite to do that build. Two options down is the option to install the CLI, which does not require any other build tools.

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?

To answer your question sincerely, Tailwind is a series of utility classes that make it easy to author CSS within HTML (pages or components). Back in the day we had many libraries to do this, the most popular was called Bootstrap. It looks like this: https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootst...

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.

While I don't disagree (broadly speaking) with you about the complexity of webdev, it looks like you don't have a full understanding of what Tailwind is:

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.

Generally use the standalone tailwind CSS CLI tool for keeping things lean. Sadly the download link from the "Getting Started" page https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.... is broken.

Shows that the "bloated" way of doing things is now the norm.

What is the issue? Except you not being up to date with the ecosystem and complaining about it?

Why do I need a car key and worry about gasoline? I can just hop on a horsie and ride away!

Because if you are working with CSS, there’s a decent chance you’ll be using npm and/or Vite, and it’s convenient to integrate your tools to save yourself time. Don’t like it, pick another installation method, like the standalone CLI build option, that needs neither.

Are you just lazy? Apart from not being up to date with common ecosystems (which I'd expect when doing anything web), look at the Getting Started:

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.

Software is required to "help" with CSS. Only seems reasonable that you'd need to install said software. Installing the Tailwind package provides the Tailwind software. So when you build your website that uses the `block` class, that class actually exists somewhere - because you pulled it in with the installation via the package manager.

Surely we can agree that distributing shared libraries via a package manager is a good practice, no?

Only parts of modern web dev are unnecessarily complex. What you can do with frameworks like SvelteKit or Nuxt, SolidStart, Remix, Next, ... is amazing. For simpler use-cases you sure can and should use vanilla HTML, CSS and some JS maybe some HTMX to level the interactivity ceiling, but for highly interactive apps with flexible rendering you need one of the modern frameworks. I assume you lack experience in front end, so believe me, getting started with a simple React SPA pre CreateReactApp (6-8 years ago?) was a horror trip. Now, starting, working on and deploying an app with the modern frameworks, e.g. SvelteKit doesn't get any easier in any tech. As a long term full stack dev my assessment is that web dev is in an exciting phase. A lot of innovation (and improvements) has been made in the recent years. Tooling has greatly improved mainly thanks to Vite, reactivity has become simpler, DX is a prio 1 concern thanks to Svelte. While not being fully convinced of general usefulness of universal rendering, I admire the innovation there.

Webdev is a shitshow so investors money could burn quicker. Huge potential for companies that can come in and transform the stack by throwing away the whole "modern" JS stack and use things like Turbo or LiveView

Aside from that the website also has a guide to install it with postcss, a tool I've never heard of before (forgive my intentional ignorance).

If you scroll down 6 inches you'll see there is also a standalone CLI.

> What the hell is Vite?

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.

Looks like you are not really familiar with how Tailwind works. And if you don't understand it of course Vite or a build step will look weird. But I suggest first getting familiar with the thing you are discussing to avoid adding misguided comments to the discussion that really don't add any value.

I resisted using it for a long time, it just seemed too much like read-only code for me. But I've been building my latest project with it, and I have never iterated on the front end more quickly. It is great fun.

this is the honeymoon phase, wait until your package manager and transpiler is out of date, and your progressive web app framework is out of date, and your typescript version isnt compatible with the upgrade yet, and tailwinds isnt either or it is but none of the documentation is yet, but you have to upgrade because your CI/CD cant run your version of node anymore

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

i've been using it for... years? and it still feels like magic when i use it. v4 fixes my only real issue with it which was the config file feeling so detached and rough compared to everything else.

I feel the same. I tried many css solutions over the years and always made a mess.

Tailwind is by far the first time I'm productive with styling.

I'm impressed with everything they've built.

Is tailwind better than CSS modules, and if so then why?

I don’t work on the frontend very often, I think the last time I did so was when bootstrap was “the tailwind”, but when I recently had to cover for one of our react developers I got to work with it. I genuinely didn’t think there was a difference in my work flow between the two. Looking up meta language magic in the official documentation and then using it through brute-force development. Maybe I’m missing something, more likely I’m just a terrible frontend developer.

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?

OKLCH is a curve that makes everything look nicer lol

https://abhisaha.com/blog/interactive-post-oklch-color-space...

OKLCH is widely supported in all modern browsers.[1] My easiest winning point with getting teams to start with OKLCH is that we can 'programmatically' control the color shades and tints by tinkering with numbers/values. To the designers (who don't write codes), I tell them that they can now focus on choosing the key colors (primary, accent, etc.) and then let CSS do the magic.

A good friend maintains a tool to tinker with various shades/tint of colors with OKLCH https://colorcolor.in

1. https://caniuse.com/?search=oklch

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

First, note that all colors in sRGB can be losslessly converted to OKLch (but not the other way around), so I don't know if this actually changes the colors or not.

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 has the main advantage of LCH, which is that the numbers make sense, meaning that if you have two colors that are the same lightness they will look like they are the same lightness, because the numbers make sense you can now do programmatic color manipulation - increase lightness by 5 etc. that in the past would have been too difficult to really do (so people would instead just have variables giving the different rgb values and switch them in)

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.

> Anyone know if that is part of a wider adoption trend or is Tailwind pioneering here?

It's part of a wider adoption trend. https://bottosson.github.io/posts/oklab/#oklab-implementatio...

In case you're wondering how to pronounce it...

https://dillonshook.com/how-do-you-pronounce-oklch/

Oklch is a polar colour space corresponding to the rectangular Oklab, designed as a perceptual colour space, matching how people see things, rather than how display technology works.

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>

2. Specifying colours that are beyond the sRGB gamut. This is what they say in https://tailwindcss.com/docs/v4-beta#modernized-p3-color-pal...: “taking advantage of the wider gamut to make the colors more vivid in places where we were previously limited by the sRGB color space”. Frankly, this is seldom actually advisable. For most purposes, sRGB is quite enough, thank you: go beyond it, and your colours will be too vivid. In photographs it makes sense, but for colour palettes used with blocks of colours and such, it’s normally a bad idea. Yet if you are trying to go beyond sRGB, meh, nothing wrong with writing it in Oklch. Though color(display-p3 ‹r› ‹g› ‹b›) may be easier to reason about—

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);

I don’t know how they chose those numbers, but there’s no low-order polynomial curve there; they seem entirely arbitrary choices. Not a good showing for Oklch. The “modernized P3 color palette” shown is just as bad: all of L, C and H seem arbitrarily chosen. If you’re going to do it like that, you’re completely wasting your time putting the numbers in a perceptual colour space.

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

I think the rewrite aimed to simplify installation and configuration. TW 4.0 switched from PostCSS to LightningCSS [1], and Rust-based tools tend to offer a simpler setup via single binaries (in contrast to the complexity of typical JS-based tools).

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.

--

1: https://lightningcss.dev/

I absolutely care about things that take hundreds of milliseconds for my builds. The faster I can build, the faster I can iteratively try new things things out. The goal should be to be able to see changes instantly after you make them, and Tailwind is usually just 1 part of a build pipeline.

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

Despite tailwind 3 being very fast there are situations where it can be a little slow and it adds up. I’m personally really glad they’re tackling performance in v4.

No idea if anyone was complaining, but if building in CI it shaves off some pennies (or more?) no?

I see tailwind as a new form of CSS built for the component age. It’s not a framework or design system.

How does Tailwind handle responsive design issues better than CSS? Assuming of course CSS where the devs know how to use clamp.

I use DaisyUI on top of Tailwind to get the nice semantic classes like btn.

Looks like the contain utility has been added here [1] and is also available in v4.

[1]: https://github.com/tailwindlabs/tailwindcss/pull/12993

I'm a new user of Tailwind, but there are 5 points where I believe Tailwind is wayyy more efficient than CSS:

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

Ok, my problem is that I don't know just by reading the styles that other contributors wrote, whether they are still relevant, or if the HTML they applied to was changed or removed. They didn't write clean atomic commit, and I can't get them to adhere to some sort of convention.

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.

> 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!).

I'd like to not have to read or write CSS. Let's see you tackle that. ;-)

What does that mean?