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