Stability vs Decline
My post on the sad state of the Backbone ecosystem from this weekend was surprisingly popular. I got a lot of responses pointing out some things I got wrong, sharing my concerns, or pushing back on my main points. Objections to the post came in 2 primary forms, which I want to quickly address. The first concern is that the Backbone ecosystem doesn’t matter. The second concern is that the trend I’m identifying as decline and decay is actually stability.
Does Backbone’s ecosystem matter?
The first concern came in 2 main forms. The first (and more polite) form was from commenters who shared their experience and said that they’d found Backbone’s core to be enough when combined with their own code. The second group was a generalization of that, effectively saying that Backbone is a minimal framework, and real programmers can write their own code on top of that. I’m sympathetic to the first framing, much less so to the second.
One of the beauties of Backbone is that it can be used in a variety of ways. Its small and simple enough that you can pull it in and use only part of it (maybe just the models or event system for instance), but it has been scaled to be used for large web applications like Trello, Rdio, Backbone, Bitbucket and others. Some of those use cases quite frankly, don’t need anything else most of the time. If you’re writing a very simple single screen piece of interactive behavior with Backbone, you don’t need any special extra libraries for that.
I personally work on a large scale web application (~200 Backbone Views) that has been developed for over 3 years and will continue to be developed (hopefully) for a long time. In that situation, having well documented, tested and supported third party libraries for common tasks like rich tables, form validation, UI component libraries, and integrations with other tools is tremendously useful. As an experienced developer, I’m capable of writing all of these things myself, but doing so takes time, and the result is likely to be less stable, less well documented, and less well thought through than a popular open source solution. To be clear, nobody is obligated to write these things for me. I’m merely making a factual statement that the experience of writing a large web application in Backbone becomes more difficult as the community around the library shrinks.
Is Backbone just stable?
The second disagreement (and the most common theme on Hacker News) was that the current state of Backbone and its ecosystem is not sad at all. Backbone is stable, and thats something to be celebrated. In some cases this echoed what I actually said in the post. I specifically called out the core Backbone library as a good example of stable software:
I’m starting with Backbone itself to give an idea what a stable mature project graph looks like. Backbone isn’t getting the activity it used to, but there’s still a steady flow of bug fixes and documentation updates, and issues are being worked through.
Backbone is stable, and in a vacuum that is something to be happy about. Stability has not prevented it from having an active team of contributors who are continuing to refine it and make small improvements. This is great, and on it’s own would make me incredibly pleased as a user. The problem comes with the libraries around it. Excepting Marionette, which appears to be getting ready to launch their long awaited version 3, activity in the ecosystem has stagnated in a different way than Backbone core.
Unlike Backbone core, secondary libraries have important issues requested by several people being ignored. I’ve chosen to avoid calling out specific projects because I don’t think anyone has a responsibility to fix other people’s open source problems and don’t want to add to open source guilt. But it is not hard to find examples of this if you browse through popular Backbone packages on Github.
A healthy stable project ought to be able to check off 3 boxes.
It meets the goals of its authors
Major bugs are fixed as they’re reported.
It is maintained to the extent that as new issues come in, they are responded to and dealt with
That definition could mean that a library handles a single use cases, and there is rare activity because nobody ever encounters any problems. But for larger projects, this likely means refinements to fix small issues, documentation changes, and an occasional big bugfix over time. Its these things that make the difference between stable software and abandonware.
What does it matter in the end?