Last week on Mastodon, Heather Buchel wrote…
If I think back to like, 10 years ago, the progression in the world of CSS has DRASTICALLY changed the way I build a UI for a website as a huge net positive good. Less code. Less images. Less clunky weird code. I really do not feel the same way about the advancements in JS UI libraries. I really don’t think there has been a net positive good. Drastically different? Yeah, sure. But drastically BETTER? No, I don’t think so.
I think there’s a bit of nuance missing here (it’s just a toot, after all), but on the whole, I agree with Heather.
Today, I wanted to unpack this a bit. Let’s dig in!
Let’s start with where I think Heather is wrong.
querySelectorAll() came along, it used to require a lot of looping and regex patterns to find elements by things like a class or data attribute, or some complex set of selectors. jQuery was created in large part to address issues like that.
Right now, we’re in a CSS renaissance.
I don’t think that’s what Heather was referring to, though.
I’m pretty sure Heather was talking about developer culture and library ecosystems, and this is where CSS developers have done a much better job than JS developers.
Tools like Less, Sass, and PostCSS were designed to augment native CSS with features it doesn’t have natively yet, or that aren’t widely supported (for the most part)…
- Bundling files
- Color manipulation
I think of them like Babel, but for CSS.
CSS isn’t totally immune from this.
Tailwind is quite popular (though, in my opinion, mostly among the JS developer crowd), and it’s whole value proposition is “CSS is broken lets fix it.”
But the CSS community has taken an approach to tooling that’s most “augment what we can do natively already,” whereas the JS ecosystem is more “let’s build complex non-native syntax with the native stuff.”
It’s a subtle but important difference.
A graveyard of tooling
As part of her Mastodon thread, Heather also wrote…
“Don’t you remember how awful it is having jQuery slung every where and trying to keep everything in sync and the mess of code it created?” YEAH HAVE YOU SEEN WHAT PEOPLE ARE DOING NOW? LMAO please.
I do remember the fun of occasional jQuery version collisions when a developer would load two (or more) versions on the same site for some reason.
But I also remember that the jQuery team was very thoughtful about upgrades and breaking changes. They were slow to update (in a good way), and a lot of the changes were under-the-hood updates that improved performance rather than breaking API changes.
Contrast that with the modern JS ecosystem, where libraries introduce breaking version upgrades frequently.
The web is littered with abandoned versions of old state-based UI frameworks. Working on an older code base means spending hours fixing and upgrading NPM packages first.
This is a net negative, not a win.
Augment, don’t replace. Progressively enhance. Grow thoughtfully. Move slowly and fix stuff.