I think some tools are a good idea. But as few as possible, and the easier they are to stop using, the better.
Now Michelle asks:
Suppose we want to stop using Tailwind one day?
Turns out it’s a bit of a roach motel, much like most JavaScript frameworks: you can get in but you can’t easily get out.
So whenever possible, the safest, and most future-proof bet is to use the native features of the web platform.
This is a spot-on analysis of how CSS-in-JS failed to deliver on any of its promises:
CSS-in-JS was born out of good intentions — modularity, predictability and componentization. But what we got was complexity disguised as progress.
This is a really thoughtful look at the evolution of CSS and the ever-present need to balance power with learnability.
It would be much harder for a 15-year-old today to View Source and understand the code structure that built the website they’re on. Every site is layered with analytics, code snippets, javascript plugins, CMS data, and more.
This is why the simplicity of HTML and CSS now feels like a radical act. To build a website with just these tools is a small protest against platform capitalism: a way to assert sustainability, independence, longevity.
Heydon does a very good job of explaining why throwing away the power of selectors makes no sense.
Utility-first detractors complain a lot about how verbose this is and, consequently, how ugly. And it is indeed. But you’d forgive it that if it actually solved a problem, which it doesn’t. It is unequivocally an inferior way of making things which are alike look alike, as you should. It is and can only be useful for reproducing inconsistent design, wherein all those repeated values would instead differ.
He’s also right on the nose in explaining why something as awful at Tailwind could get so popular:
But CSS isn’t new, it’s only good. And in this backwards, bullshit-optimized economy of garbage and nonsense, good isn’t bad enough.
I suspect most people on opposing sides of the Tailwind debate actually complete agree on Tailwind itself. I don’t think we disagree on atomic CSS, or utility classes; I think our contention comes from the valuations we made long before we ever chose our tools. Where one of us sees a selling point, the other sees a flaw.
This is very much in line with what I’ve been talking about in my presentation on declarative design.
As Jeremy Keith put it so well: where it comes to styling, Builders want imperative programming; they want to specify what they want, where they want, how they want it. No surprises.
Crafters instead want declarative programming; they understand how to wield the power of creating rules of governance within a complex system, and wish to use that power, rather than micromanaging the browser.
Reminding myself just how much you can do with CSS these days.
Try writing your HTML in HTML, your CSS in CSS, and your JavaScript in JavaScript.
A tale of two principles.
Day fifty one.
How Apple’s penchant for breaking the web has given me more empathy towards developers who are suspicious of the web platform.