I disagree with the title - I don't think this is a sad state at all. This looks very healthy to me. Backbone clearly had a purpose some years ago and it is unequivocally deprecated now. To me, this is a javascript library aging gracefully and opening the way to newer, better libraries. By removing itself from the list of relevant libraries to choose from in the current year, backbone has helped to reduce decision fatigue.
I hope other Javascript libraries and framework follow this trend until we find a handful of "winner" libraries in the same way that each language has its own "winner" MVC library.
I'm using Backbone again, courtesy of CartoDB.js [1] and have no interest in chasing whatever React variant was just pushed to GitHub.
(Un)fortunately I'm an enterprise developer and that means staying a decent distance behind whatever the "state of the art" is.
A recent experience with npm/ruby/grunt has put me off it until I have a chance to sit down for a few hours and unpick what exactly it was doing (can anyone recommend a way to simulate an NTLM proxy?)
Backbone is a fundamentally different paradigm from React, so as you point out it won't always make sense to borrow ideas from React or other one-way frameworks.* I find its usefulness waning these days for big projects, but it's absolutely my go-to for most small apps (I do a lot of client work). It's just easier to work with and less boilerplate when you don't need the strictness that React enforces / encourages.
As others have pointed out, having a stable API is a wonderful thing for a vast majority of projects. Backbone is stable because its ideas are battle-tested and the concepts are all there. People are seeing less usefulness for Marionette / Chaplin / Aurora, and I don't think that's all that bad.
> It's just easier to work with and less boilerplate when you don't need the strictness that React enforces / encourages.
domvm [1] and Mithril [2] promote the same ideas as Backbone, as far as flexibility but with vdom underneath and are far faster than React. domvm is about 2x Mithril performance and both libs are < 20k min. Mithril is more stable and has a much larger userbase, while domvm 1.0 is targeted for 4/1. If anyone is feeling adventurous, feedback and contributions are welcome!
According to Inferno's benchmarks section[1] that lists Mithril, Mithril is actually slower than React when it comes to DBMonster and is slower than all others listed. As an aside, domvm seems to be exceptional in its performance and size. Yes, others are faster, but the library is much smaller. The flexibility of it is also pretty awesome and holds a place in my heart after making my own mini framework years ago.
I love that Mithril has been surfacing as a framework to watch now that the hype cycle around angular/react is bubbling down. It struck me as one to watch years ago, and were it not for the popularity of the aforementioned the case for it could have been quite convincing. I will definitely be looking for opportunities to trial it.
I have been evaluating it vs react for some UI's I am working on and have come away very impressed. Coupled with underscore or lodash and you get most of the niceties of es6+react with a much smaller size.
FWIW, I definitely agree that this is mostly a non-event for small apps. I work on a large, actively developed web application, where the lack of strong actively maintained supporting libraries for things like form validation, rich tables, and other use cases is painful, especially since there were great projects for those use cases that are no longer actively maintained.
Instead of using Backgrid and backbone-validation or alternatives, we've been left creating an in house "tables" approach, and maintaining our own fork of backbone-validation. Neither of those things scale well.
The approach of a small core library with other libraries filling gaps as needed only works when there are good libraries that work well with the small core library :/ For some things its easy to take a "VanillaJS" library and make it work, but for others it really helps to have tight library integration.
Backbone is not maintained at all, and no, cosmetic commits aren't maintenance. Backbone led to messes bigger than jQuery messes, it's full of useless stuff and frankly should be retired and deprecated. What's the point of backbone model? it's useless so one has to use relational. What's the point of the router? it's too basic so people have to use a better one, the view? the view never did anything relevant, Backbone is like an unfinished framework the only reason it became popular is because it came at a time when rubyists were influential. That time is over. People shouldn't use Backbone, AT ALL.
> As others have pointed out, having a stable API is a wonderful thing for a vast majority of projects
Well obviously it didn't change the sad state of backbone ecosystem. Having good API to build things upon is more important than the stability of an API. Backbone is dying because the core libs aren't good enough in 2016.
It must be really rewarding to be the author of an open-source project when you read feedback like this...
Backbone is "dying", if you will, because an awful lot has changed in the last five years, not because it was necessarily fundamentally bad - though, of course, it had its limitations.
Well, I think: 1) "notional" is an odd choice of word since @jashkenas has over 20K karma on here; and 2) it's fine to offer reasoned criticism, but the sort of denigration I was responding to ("messes", "useless", odd comments about Rubyists) really is unnecessary.
1) I'm not sure what you mean, your comment was generalised, implying it has a wider scope than this one author. I'm also not sure what karma has to do with anything..
2) If the rubyist comment is 'odd' to you, how are you sure that it's denigrating? as for 'messes' and 'useless', you've divorced them from context:
> Backbone led to messes bigger than jQuery messes, it's full of useless stuff
> What's the point of backbone model? it's useless so one has to use relational.
Eventually the maintenance developer realises that anger and tears aren't useful, and funnels that into documentation, cleanup and a hell of a lot of printf-debugging.
...and whiskey.
FWIW, it's possible to create messes in Backbone, JQuery, D3, React and plain javascript, if you try hard enough.
Sad state? Not at all. I guess it all depends on the type of coder that you are. Let's say you need a theme/gui for your app. Plan A: get a bootstrap theme, tested, reliable, responsive, modern, etc. You'll be getting a ton of code/features of which you'll probably just need 5%. Plan B: get something ultra simple that gives you structure and add stuff as you need it, something that maybe has grids, buttons and forms (maybe something you even code yourself like I normally do). Backbone is like that: just the structure (hence the name!) with a couple of commonly used features. Angular/React/Ember are like the bootstrap theme. I personally like to have full control of what is added to my code.
Regarding Google Trends, if a framework has big (huge) money behind, it will most likely be more searched-for, sponsored, events held, conferences, hackatons, etc.
Finally, once you set to learn and use a stable tech, you will be profiting from it for a long time. I still have a couple of apps running classic ASP! With JS frameworks I think we can safely assume it will be even longer.
i've also been evaluating reflex css [1] for grids. it's been tiny and excellent so far. BEM syntax [2] is a bit odd at first, but the principles behind it are solid.
> Backbone is like that: just the structure (hence the name!) with a couple of commonly used features.
I had a look at Backbone a few times and liked that it indeed provided a clean structure without too much overhead, though I've never had the opportunity to use it(I guess I won't now).
I'm wondering though, now that Backbone is apparently on the way to be deprecated, is there any good alternative?
I guess I see this as a) not surprising, and b) not a problem.
If you're using Backbone in 2016 (like I am), it probably means you want your "framework" to be simple, stable, and customizable. Given those priorities, using a wide variety of plugins doesn't make much sense.
If you want 3rd-party code to do a ton of stuff for you in an opaque way, you're much better off using Angular or Ember.
It's not sad at all, in fact it's the opposite - Backbone can be considered a stable, battle-tested framework with a "finished" API and features set. What's not to like? Sure, they could turn it into a bloated monster, with constant API changes and new features with new bugs, but Backbone had a clear goal to be as versatile, flexible and easy to use as possible, providing only the most important components, and they've achieved that all right. Seriously, if you've made several big web apps in the past using Backbone than you'll make another one much faster with Backbone, rather than the "new and shiny" which you'll need to learn from scratch.
Several made this point, that Backbone is stable, not abandoned. I agree! I said so in the post. My concern is with the libraries around it. I've elaborated in this followup post: http://benmccormick.org/2016/03/09/stability-vs-decline/
One of the common trends in JavaScript is the proliferation of dependencies...there are 25 listed (+ Backbone makes 26). It's a fragile chain that requires a lot of people to provide attention to maintenance of all that supporting infrastructure. And it requires each of them not to be on the wrong side of a "non-negotiable" feature requirement for each developer making a decision to use it and has to be beloved enough that each maintaining developer is willing to fix bugs and update their library for no other reason than to make it appear "fresh."
I think this is strongly tied to the current fad have having every micro-library be "dependency free". I don't fully understand the appeal.
"Here's my tool that is superior because it has no dependencies. Will you make it your next dependency?"
I understand the appeal when you have a very small set of problems and ultimate flexibility, but this always ends up in a lot of duplication of effort and code (how many libraries have a denounce method, or other general utility method?)
Maybe to rephrase, I understand the benefits, I guess I just don't understand the persistence of the fad in the face all of the drawbacks.
to be clear, I don't think anyone is using all of these libraries in a single project. Most Backbone web apps probably use 2-6 of these repos. So the fact that some of them have gone stale is not in itself a problem, and is normal. The fact that nearly all of them have makes it much more difficult to build sophisticated web apps with Backbone. Everything non-trivial has to be done in an in-house ad-hoc basis, or using lightly maintained 3rd party code.
I didn't read your article as making that case. My riff was more on the exponential size of the dependency space. Even if someone is only using 5 external libraries, if one of them is among the 25 listed, the dependency chain can easily become burdensome.
To a first approximation, I think the default for JavaScript development is to treat taking on dependencies lightly. And because the JavaScript zeitgeist moves from project to project so quickly, there's often no historical base to take on supporting open source projects when the original author moves on. I mean Jeremy Ashkenash can take a motorcycle trip in part because of his decision that Backbone is not evolving quickly. The idea that things must evolve quickly equates to more work and more work is a recipe for burnout.
I think his Google Trends graph is way off. If you use spaces instead of dots (for example, use search terms like "angular js" instead of "angular.js" you will see a very different picture in which Angular passes Backbone early in 2013 and rises to dominance, with React following a similar trajectory below Angular, about 2 years later:
https://www.google.com/trends/explore#q=angular%20js%2C%20ba...
That graph has a better fit to my subjective memory of the popularity of these frameworks. Backbone was never so dominant, and Angular is not flat or in decline, except over the past 6-12 months its growth might be slowing with respect to React.
Frontend is still the Wild West. Programming is still the Wild West. We're still figuring out what ideas don't work, what ideas work and how far up they scale. I can't help but wonder if we are nearing the end state with Functional, or if some huge new ideas are yet to be thought up. Math and physics are kind of like programming and are pretty well figured out by now. There is also Logic programming, I personally don't understand any huge applications of it but the whole world couldn't apply functional until maybe ten years ago. What else is already out there that nobody is paying attention to?
> Math and physics are kind of like programming and are pretty well figured out by now.
I used to think this too. Then I got into machine learning and modern physics. There is still much in both fields left unresolved, both empirically and philosophically. I suspect the same is true of programming. For instance, machine learning aided programming (the next generation of syntax checking, with recommendations) will no doubt open up new ways to be even more productive, and new tools will crop up to support that. Maybe machine-aided debugging gets way better and this leads to bettering ecosystems because it can catch (and maybe fix) breakages better. Right now, I think it's amazing that all these things like npm, pip, and apt hold together as well as they do (but the extent to which they don't is a huge time suck and productivity killer).
- React is off its peak, and may be flat-to-declining
- Angular is declining
- Ember is declining
- Backbone is declining
It looks to me like a consolidation phase.
But, yeah, backbone sure got hammered in the last two years. Having watched a big company make a bet on a client-side library that didn't work out... sorry about that.
Maybe, just maybe, constant movement and change isn't a good thing in a library that has many, many projects depending on it. This article has made me more likely to try Backbone again.
I'm working in Angular now. I miss Backbone, and fully believe the applications we built in it are strong, supportable, tested and expandable. They increased my reputation for fast delivery and high quality.
But, the technologies aren't usually our decisions, and "what's cool" is generally what wins :-(
I enjoyed working with backbone. It was a breath of fresh air back in the day.
I've actually ported it to C++ and Java (implementing an Event emitter for both languages).
And I respect Jeremy, also the author of coffee script, the most expressive language which I also enjoyed working with.
Scaling such a lib for the entire universe and maintaining it is probably quite complicated without strong financial backing, but maybe not all projects are supposed to be scaled.
I still like hacking together quick one-page apps with Backbone, it's too easy to do, although I have to admit that React is much more powerful - in theory.
For many, though, Backbone can still be a very good choice.
I also greatly respect Jeremy for the work he's done on Backbone, CoffeeScript, and Underscore.
I'm confused by his stance on versioning, however: he's very much against semver, which means these tools can be tricky to use with npm (which assumes all packages follow semver).
(From the docs:)
"Backbone is an attempt to discover the minimal set of data-structuring (models and collections) and user interface (views and URLs) primitives that are generally useful when building web applications with JavaScript."
In this respect, I would say it is a great success! The biggest application I have seen is the slick SoundCloud web interface (though I don't know if they've moved on).
Sometimes, you don't need a gigantic ecosystem that pulls in half the internet when you do an "npm install". Just something to give a basic structure .. a backbone .. hey wait :) !
Last time I worked with Backbone I recall there being a schism in the community regarding the use of JQuery under the hood. The author was presented with performance metrics comparing Backbone to a vanilla JS fork which had made substantial improvements to rendering performance. That might've represented a major turning point in the evolution of the framework, but perhaps one of the reasons it stagnated was little to none of that criticism was taken onboard?
I'm not sure what you mean by that last part. We removed the jQuery dependency in View [0] and History [1], and I wrote a small shiim to allow Backbone Views to work with vanilla JS [2]. No schism, just not a huge paradigm shift either (which is a good thing).
The sad indicator for me is the decline of activity around backbone in irc. The channel is all but dead, which means it's hard for people to get help when it is needed.
Most one-off discussion has moved to Gitter. It's not an open platform but the channel is better maintained because Gitter has modern features like email notifications.
Your post is dismissive of Javascript tools, and its only contribution is letting everyone know that you expected Topic A but instead got Topic B. Not very useful.
I hope other Javascript libraries and framework follow this trend until we find a handful of "winner" libraries in the same way that each language has its own "winner" MVC library.