Skip to main content Accessibility Feedback

Ecosystem rot

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!

Native features

Let’s start with where I think Heather is wrong.

JavaScript has gotten a lot of great native features over the last ten years. If you weren’t coding then, you might not realize how damn hard it was to do something like find an element by something other than an ID.

Before querySelector() and 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.

Now, in addition to selector methods, we’ve got amazing array manipulation methods, template literals, destructing, Proxies, Classes, and a whole slew of features that make writing JavaScript so much easier and more powerful than it was a decade ago.

Right now, we’re in a CSS renaissance.

The most exciting stuff I see coming out for browsers isn’t JavaScript-related. It’s all Cascading Style Sheets, and it’s wonderful! Being able to replace JS with CSS is a wonderful feeling.

But from a native language perspective, both CSS and JavaScript are miles better.

I don’t think that’s what Heather was referring to, though.

Libraries

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

  • Nesting
  • Variables
  • Bundling files
  • Color manipulation
  • Functions

I think of them like Babel, but for CSS.

The JavaScript tooling ecosystem, by contrast, went heavy on reinventing the wheel (over and over and over again). We seem to keep undulating between “do all the things on the server” and “do all the things in the browser,” occasionally stopping in this middle place of “what if we did a bit of both?”

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.

The takeaway

I think the JavaScript community would be in a much better place if it learned from how the CSS community has approached tooling.

Augment, don’t replace. Progressively enhance. Grow thoughtfully. Move slowly and fix stuff.