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."
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?
npm is for designed primarily for js dev. Many (most?) sites aren't written in js -- they're written in Java, C#, Python, PHP, etc.
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:
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.
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?
CSS is text. What's wrong with copying the required CSS stylesheets over and including (importing) them from your own stylesheets?
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.
x86 ASM is text but we don't build software by copying and pasting it. While the underlying thing we ship is CSS, that doesn't mean we can't add tooling layers to make it easier or more efficient. While it's totally allowed to write by hand, most frontend web developers I know are very comfortable with NPM, and indeed having dependencies consumed from a package manager is often preferred.
> Surely we can agree that distributing shared libraries via a package manager is a good practice, no?
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.
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
Agree, and the most maddening thing is that the platform is honestly better than ever. Doing your layout in CSS is so much easier now than it was 10 years ago, thanks to CSS variable, containers queries, and widely supported flexbox & grid.
It's the NPM ecosystem above that's being stupid, and believe that adding more tools and more processing is a good thing.
This is such a biased take.
There's many ways to build a website, you just don't like the most popular way because you're not comfortable with the technology and ethos.
That's ok, but don't go around spouting nonsense about about investors throwing their money away on js projects.
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.
So Vite is a security measure against opportunistic theft? Theft of what?
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.
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.
Though you are of course correct, I see no problem with somebody reading about technologies that they themselves don't use here on HN. I personally read HN to get familiar with new technologies that I may find useful in my work and private life. I first heard of OpenAI and Anthropic here.
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.
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.
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.
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
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
Good rant! That's kind of what web-development seems like sometimes. Almost every part of the technology stack is there to fix some other part of the stack that never was ideal to begin with. TypeScript being the best example. It only exists because JavaScript sucks, and JavaScript only ever existed because in 1994ish some guy failed to get Java to run in the browser, and the only reason we're building apps in what was originally a "Document Rendering" system (HTML) was also not by design either but just an accident of history. One train wreck after another.
no, it's not a good rant. this is the billionth "web dev is too complicated!" rant that is present under every. single. thread. about any technology vaguely related to front end development.
I haven't yet reached the end of the comments, but I'm also fully expecting at least one "Electron is a cancer that is eating my computer and the reason why my wife left me".
This site leans heavily backend it seems.
There's a strain of patent smugness that comes with a lot of comments about frontend on this site and it's quite disheartening to see it.
You rarely see frontend devs disparaging backend devs for their tech choices.
I've been using it for a long time now and the honeymoon period hasn't ended. I do understand what you're saying, but luckily I keep it pretty simple with a standalone tw executable and no node.js or complicated frameworks, so I have been able to avoid these pitfalls.
What do you think are the best option to avoid that? I was wondering what could I do with a project that I have that is a long lived code base, so we have some legacy parts.
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.
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?
Bootstrap is so much worse because of all the nested CSS styles. One of the big benefits of utility classes is that they’re relatively isolated to one element (with a few exceptions like tailwind’s group classes). This has a lot of benefits like eliminating spooky action at a distance and making elements so independent they can just be copy pasted between Tailwind projects.
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.
After some experimenting I found that Tailwind works best with hybrid approach. The essay[1] is correct, that often you have one-of-a-kind blocks, like headers, footers, etc. that you can just fully implement with TW utilities, reducing cognitive load for class naming and structuring. But for more reusable elements, like buttons, links, inputs, popups, it's just much nicer to have them (and their variations) behind simple `btn btn-blue btn-small`. Even when using component-based approach, it's just much simpler to manage all those various states as explicit classes, rather than re-implementing CSS cascade in JS to determine how to combine corresponding TW utilities. I feel like if Tailwind Labs would be less radical in their marketing strategy, it'd receive a bit less of a backlash. Maybe :)
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
CSS first configuration is a good change! It seems like it would makes it easier to combine tailwind with regular CSS files which still uses the same design tokens. This is useful e.g. when creating a site with a component architecture where the components are styled with CSS, but some of the content comes from CSS or markdown.
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
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.
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.
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.
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:
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:
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.
Any thoughts on what color space you'd prefer to use? I'm working on a Tailwind palette creator (https://www.inclusivecolors.com/, it's based around letting you visualise the curves you mentioned), which uses HSLuv right now to avoid problem 2 in your list. HSLuv has perceptual uniformity as well (which is great at helping you pick colors that contrast) but it doesn't support P3 unfortunately, similar to Google's HCT color space.
I'm not seeing much demand for P3 at the moment though. Most designers I've spoke to don't know it exists.
I invite (for fun and learning!) anyone here still thinking native CSS provides no efficient solution to the problems Tailwind may have solved 5 years ago to challenge me:
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.
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.
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!
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.
> 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:
> 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.
> 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.
YMMV but I find ‘lg:…’ to be much better than ‘@media (min-width: 992px) { … }’ at the expense of repeating ‘lg:’ every class. Since most components don’t need too many responsive classes per breakpoint, this is a net benefit most of the time (and nothing is stopping devs from combining utility classes and custom css with media queries).
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.
The clamp() CSS function (and auto-adapting grids) can reduce media query usage to a really loooow minimum. Nowadays I use media queries only for mobile nav and maybe layout grid adaptation. Like 2 to 4-5 media queries per project maximum.
I think that's what the comment you're responding to meant.
Yes! This sums it up perfectly. To the latter point, it's more so a tool for building design systems that comes with a [very large and thorough] default implementation.
I prefer scoped css, eg svelte or react with CSS modules. This allows one to closely pair the styles with the component, but still separate out the styling from the html (I cannot stand tailwind/inline syles)
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.
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.
> 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.
That’s really interesting to think about actually! What kinds of practical things do you think could be enabled by an extremely fast tailwindcss?
LLM trying design using tailwind, stuff like: try to recreate this bitmap image using tailwind utility classes; the iteration speed for that kind of tasks depend on such speed.
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.
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
> 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.
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.
If you want to try new things out and move fast with your CSS, you're not building the entire system. It's a partial build and that was already faster than you would even be able to react. Your browser refreshing would take longer.
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.
Given its popularity this can actually get into measurable carbon emission savings. Not world changing. But maybe a few international flights over the lifespan.
The carbon cost of a bloated CSS framework isn't the build time, it's the billions of times the resulting CSS has to be parsed and applied on the web pages where it's used.
Have you examined the build artifacts of a site using tailwind? The size of the CSS is often smaller than the same styling in "normal" hand written CSS. There are a dozen blog posts from large engineering orgs that have confirmed that switching to Tailwind slimmed their builds down. Shopify has been a big proponent of Tailwind and they are absolutely obsessed with shipping as little code as possible because of the scale they operate at.
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.
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.
Read some of the Getting Started documentation, for fun. First step:
> 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?
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.
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?
npm is for designed primarily for js dev. Many (most?) sites aren't written in js -- they're written in Java, C#, Python, PHP, etc.
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:
https://github.com/tailwindlabs/tailwindcss/releases/
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.
This is a feature for projects already using Node and Vite (which is quite popular these days).
It's also not a requirement. The binary still exists, you can run it standalone.
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.
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?
CSS is text. What's wrong with copying the required CSS stylesheets over and including (importing) them from your own stylesheets?
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.
The number of tailwind classes is so large now that copy/pasting the whole set into your project would mean a huge bundle size.
Part of that the tailwind package is doing is making sure that only the relevant tailwind classes are included.
So Vite builds a custom style sheet based upon the Tailwind classes that are actually used in the project?
yes, exactly
x86 ASM is text but we don't build software by copying and pasting it. While the underlying thing we ship is CSS, that doesn't mean we can't add tooling layers to make it easier or more efficient. While it's totally allowed to write by hand, most frontend web developers I know are very comfortable with NPM, and indeed having dependencies consumed from a package manager is often preferred.
> Surely we can agree that distributing shared libraries via a package manager is a good practice, no?
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.
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
Agree, and the most maddening thing is that the platform is honestly better than ever. Doing your layout in CSS is so much easier now than it was 10 years ago, thanks to CSS variable, containers queries, and widely supported flexbox & grid.
It's the NPM ecosystem above that's being stupid, and believe that adding more tools and more processing is a good thing.
This is such a biased take. There's many ways to build a website, you just don't like the most popular way because you're not comfortable with the technology and ethos.
That's ok, but don't go around spouting nonsense about about investors throwing their money away on js projects.
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.
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!
So Vite is a security measure against opportunistic theft? Theft of what?
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.
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.
Though you are of course correct, I see no problem with somebody reading about technologies that they themselves don't use here on HN. I personally read HN to get familiar with new technologies that I may find useful in my work and private life. I first heard of OpenAI and Anthropic here.
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).
> 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.
I've never had as much fun doing front-end web stuff as I've had since I've picked up tailwind.
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.
80/20 is the greatest "thing" of all time. You critique it from the outside but when you're in, oh man.
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.
Is tailwind better than CSS modules, and if so then why?
they serve different purposes.
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
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.
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
Good rant! That's kind of what web-development seems like sometimes. Almost every part of the technology stack is there to fix some other part of the stack that never was ideal to begin with. TypeScript being the best example. It only exists because JavaScript sucks, and JavaScript only ever existed because in 1994ish some guy failed to get Java to run in the browser, and the only reason we're building apps in what was originally a "Document Rendering" system (HTML) was also not by design either but just an accident of history. One train wreck after another.
no, it's not a good rant. this is the billionth "web dev is too complicated!" rant that is present under every. single. thread. about any technology vaguely related to front end development.
I haven't yet reached the end of the comments, but I'm also fully expecting at least one "Electron is a cancer that is eating my computer and the reason why my wife left me".
This site leans heavily backend it seems. There's a strain of patent smugness that comes with a lot of comments about frontend on this site and it's quite disheartening to see it.
You rarely see frontend devs disparaging backend devs for their tech choices.
I've been using it for a long time now and the honeymoon period hasn't ended. I do understand what you're saying, but luckily I keep it pretty simple with a standalone tw executable and no node.js or complicated frameworks, so I have been able to avoid these pitfalls.
https://tailwindcss.com/blog/standalone-cli
What do you think are the best option to avoid that? I was wondering what could I do with a project that I have that is a long lived code base, so we have some legacy parts.
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.
It’s a standalone executable.
or just use bun? used to also face all these issues - but with bun it's mostly gone for now (and for newer projects) - hope it stays that way!
Or just use CSS. Never had any of those issues.
Always the right choice!
I use bun where I can, and I’ve upgraded old projects to it successfully
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 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?
Bootstrap is so much worse because of all the nested CSS styles. One of the big benefits of utility classes is that they’re relatively isolated to one element (with a few exceptions like tailwind’s group classes). This has a lot of benefits like eliminating spooky action at a distance and making elements so independent they can just be copy pasted between Tailwind projects.
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.
Probably, I’m just sharing how it feels to use it when you work on frontend once a year.
After some experimenting I found that Tailwind works best with hybrid approach. The essay[1] is correct, that often you have one-of-a-kind blocks, like headers, footers, etc. that you can just fully implement with TW utilities, reducing cognitive load for class naming and structuring. But for more reusable elements, like buttons, links, inputs, popups, it's just much nicer to have them (and their variations) behind simple `btn btn-blue btn-small`. Even when using component-based approach, it's just much simpler to manage all those various states as explicit classes, rather than re-implementing CSS cascade in JS to determine how to combine corresponding TW utilities. I feel like if Tailwind Labs would be less radical in their marketing strategy, it'd receive a bit less of a backlash. Maybe :)
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-...
CSS first configuration is a good change! It seems like it would makes it easier to combine tailwind with regular CSS files which still uses the same design tokens. This is useful e.g. when creating a site with a component architecture where the components are styled with CSS, but some of the content comes from CSS or markdown.
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.
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
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.
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...
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...
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:
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:
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.
Any thoughts on what color space you'd prefer to use? I'm working on a Tailwind palette creator (https://www.inclusivecolors.com/, it's based around letting you visualise the curves you mentioned), which uses HSLuv right now to avoid problem 2 in your list. HSLuv has perceptual uniformity as well (which is great at helping you pick colors that contrast) but it doesn't support P3 unfortunately, similar to Google's HCT color space.
I'm not seeing much demand for P3 at the moment though. Most designers I've spoke to don't know it exists.
i never used Tailwind but i can't wait for the release video clip
for the curious:
- v2 https://www.youtube.com/watch?v=3u_vIdnJYLc
- v3 https://www.youtube.com/watch?v=TmWIrBPE6Bc
I invite (for fun and learning!) anyone here still thinking native CSS provides no efficient solution to the problems Tailwind may have solved 5 years ago to challenge me:
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.
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.
Great questions/problems!
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!
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.
How does Tailwind handle responsive design issues better than CSS? Assuming of course CSS where the devs know how to use clamp.
YMMV but I find ‘lg:…’ to be much better than ‘@media (min-width: 992px) { … }’ at the expense of repeating ‘lg:’ every class. Since most components don’t need too many responsive classes per breakpoint, this is a net benefit most of the time (and nothing is stopping devs from combining utility classes and custom css with media queries).
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.
The clamp() CSS function (and auto-adapting grids) can reduce media query usage to a really loooow minimum. Nowadays I use media queries only for mobile nav and maybe layout grid adaptation. Like 2 to 4-5 media queries per project maximum.
I think that's what the comment you're responding to meant.
I see tailwind as a new form of CSS built for the component age. It’s not a framework or design system.
Yes! This sums it up perfectly. To the latter point, it's more so a tool for building design systems that comes with a [very large and thorough] default implementation.
I prefer scoped css, eg svelte or react with CSS modules. This allows one to closely pair the styles with the component, but still separate out the styling from the html (I cannot stand tailwind/inline syles)
My favourite way too and fwiw not mutually exclusive with Tailwind (in case anyone was wondering).
I see it as a way of granular styling, because there's no cascading. And IMO works great if you style each element (or component) individually.
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.
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...
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.
> 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.
That’s really interesting to think about actually! What kinds of practical things do you think could be enabled by an extremely fast tailwindcss?
Live reloading
LLM trying design using tailwind, stuff like: try to recreate this bitmap image using tailwind utility classes; the iteration speed for that kind of tasks depend on such speed.
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
> 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.
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.
1. Tailwind is just 1 part of a build system, and it all adds up
2. Watch Inventing on Principle if you haven't already. Pushing build times into milliseconds or sub-milliseconds enables new capabilities
If you want to try new things out and move fast with your CSS, you're not building the entire system. It's a partial build and that was already faster than you would even be able to react. Your browser refreshing would take longer.
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?
Given its popularity this can actually get into measurable carbon emission savings. Not world changing. But maybe a few international flights over the lifespan.
The carbon cost of a bloated CSS framework isn't the build time, it's the billions of times the resulting CSS has to be parsed and applied on the web pages where it's used.
Have you examined the build artifacts of a site using tailwind? The size of the CSS is often smaller than the same styling in "normal" hand written CSS. There are a dozen blog posts from large engineering orgs that have confirmed that switching to Tailwind slimmed their builds down. Shopify has been a big proponent of Tailwind and they are absolutely obsessed with shipping as little code as possible because of the scale they operate at.
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...
Yes, I have. I work on browser CSS performance.
Looks good.
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
Looks like the contain utility has been added here [1] and is also available in v4.
[1]: https://github.com/tailwindlabs/tailwindcss/pull/12993
[flagged]
What does that mean?
bros keep eating ...