On using a fading javascript library

I’ve been building some web stuff recently with a JavaScript library that seems to be well past its prime. A couple of years is a long time in JS-land. I deliberately won’t name the library, because my intention here isn’t to criticize; rather I want to point out some of the challenges of working with fading JavaScript.

In its heyday, this codebase provided a buzzy bit of functionality, which probably drew in contributors at the time, although it seems like these contributors have now mostly moved on to other things. Because it was trendy stuff, it seems like the focus was on iterating quickly, and not really doing much maintenance on the corner cases. The attitude in the GitHub issues seems to be: “if you get stuck, figure it out: you’re a developer.”

Fine. I’m not complaining. In a JavaScripty way, that kind of makes sense. But not all of us have the same use cases for a library. We’re not all chasing buzzy features (or at least we are chasing them a bit less, or a bit belatedly :) and we value stability more than you might. If you build things that sparkle briefly and then burn down quickly, your audience is mostly limited to people also doing the same thing. In my opinion, being a good open source maintainer means accommodating the many, quite varied use cases your code might have, in your immediate community but also in other adjacent communities. But then again maybe I just don’t understand the JS mindset.

This entry was posted in javascript, libraries, software. Bookmark the permalink. Both comments and trackbacks are currently closed.
  • Subscribe to this blog

Skip to toolbar