There's no reason for you to feel like your learning efforts are in vain. Backbone is indeed pretty old, but the ideas behind it are still very solid.

The issues that were addressed initially with Backbone were mainly - “Get your truth out of the DOM”. Because back in the spaghetti/jQuery days, that was the real problem. The idea of managing the truth/data/state properly still applies. Learning this is important.

Another important thing to realise is that Vue and React handle only the view layer. Backbone is a framework to handle Views, Controllers, Collections, Models, Routers, Templates (with Underscore if you will) and talking to anything RESTful. So, learning that separation of concerns is important. Views do some things, Controllers another, Collections and Models another etc. With BB you get to grips with what it means to think in Events (React would say Actions) and if you keep true to how you handle that - your codebase will be beautiful. You would need to learn this no matter what library or framework the buzzing developer community on the web believes to be hip these days.

Backbone has it's very strong companion Marionette, with a vibrant and active community (some 3k users on gitter if I remember correctly) that makes a lot of great decisions for you to nudge you on the right path, if you're building a web UI.

I believe you would only learn good and sane ideas about front-end development if you delve deeper into BB.

I recently read this interesting experience about going from React => Backbone. blog.cloudboost.io/reactbone-lessons-from-react-j…

Personally I am working with React at the moment and I've learned a lot of great things that will enable me to improve my Backbone code more as well. This is another thing about Backbone, you can mess it all up badly, or you can know what you're doing and end up with a great product, it's very un-opinionated.

You are not wasting your time learning Backbone and many large companies are building stuff with it. You would also do well learning Angular, Vue or React etc. No matter what lib you are busy working with, you'll need to learn the same things - managing state, handling view updates, declarative/imperative views, inheritance, events/actions, REST.

My advice would be to continue with Backbone until you're not confused any more. Until you understand what it's trying to help you with. After that you can decide that it's either something to continue with or that it's better to learn Vue.

Incoming super opinionated post...

Run. Far away. A company that actively maintains "legacy" code instead of investing time in a better/modern option shows a lack of understanding regarding the "developer happiness > valuable product" continuum.

Do they show interest in upgrading their tech? 🤔

Do you want to work for a company that is years behind the times? 🤔

The answer to your original question is no, it is not worth it. Its 2017, and Backbone is dead. Learn something valuable like the other options you mentioned.

There are two kinds of software written more than 12 months ago: legacy code and failed products.

From your point of view, Backbone isn't a particularly trendy framework, and doesn't appear to be as actively developed as the examples you gave. I don't really know anything about it, but would be inclined to agree; I certainly wouldn't spend my weekends learning it, based on what I've read as I've been surveying the front-end ecosystem trying to decide on a framework myself.

However, from your employer's point of view, they have a product that makes them money, some of which they use to pay a developer in order that that product will continue to make them money. Their only interest in investing in your education is for the value that your increased skills will add to the company. That's how business works. If the work isn't what you want to do, that's an argument against taking that job, not an argument against having to maintain the code.

If whatever service your site provides persists into the future, there may well come a day when you migrate away from backbone. That process will be time-consuming, and may bring you perilously close to the big rewrite of death_. _Your boss is not going to sanction this change based on how backbone will appear on your CV (and hence improve your bargaining power for salary rises or attractiveness to other companies). Such a big investment of business resources will only be the result of a business decision. A decision like that will only be made when it becomes cheaper to upgrade to something newer than it is to maintain the status quo. When they no longer release security patches, leaving you exposed to some vulnerability a script kiddy can find scanning AWS. When you can no longer find libraries that have the functionality you need that's compatible with your existing codebase, so you waste hours reinventing the wheel. When backbone as you know it has been dead for so long that no-one can be found on stack overflow who remembers it. If none of these things apply, it barely even counts as legacy code.

If it makes you feel any better: In around 2010 Rails developers were hit with a double whammy of a new Rails version (3.0) and a new Ruby version (1.9), both of which introduced majorly breaking changes compared to their predecessors. It took 4 GitHub engineers 6 months to upgrade their (admittedly large) codebase. If you read the article, you'll see the kinds of problems I'm describing that forced them to make that investment. Some companies never even made the switch; one company was contracted to make RailsLTS, basically continuing to release security patches to Rails 2.3, and they're still selling it today.