Dear Backbone, it's not you...it's us. We still love you.
by Cloudoki team
Here at Cloudoki we take pride in trying to work with as many technologies and frameworks possible. So much that we even have that guy, that usually gets all the tricky projects (shout out to Delio, the Hero). All fun and games, really.
Despite having a curious and naturally dynamic team, we still rely on some good "old" reliable pieces of code and frameworks to get some things going, like Backbone.
Let me just stop here and say something. It's not that Backbone is old (ok, it's not new), or that it stopped making sense in the web world, far from it. It still is my favorite piece of framework to work with.
Picture you're having guests over for dinner, and you are quite the Chef at all sorts of things, but you know that there is always that dish. That's Backbone for us.
Over this past year we've trimmed, expanded and completely explored Backbone in, we believe, every way possible. I think we can say that we've kinda mastered Backbone, as much as anyone can master a framework. We've created countless custom modules, integrations and boilerplates over time, and kept updating and improving on those as we went.
Does it really make sense moving away?
Why Backbone in the first place?
It's a simple, light, small, data-focused library type MVC. Backbone gives us a way to gracefully deal with requests, data that comes from those and a couple more SPA (single page app) features. That's it.
Why break its heart?
Drama aside, we are not cutting relations with Backbone all together. We still have lots of projects running on it, and we will most definitely continue to develop on it in the future. There hasn't been one project where we said "we're going to need a different framework for this".
It is however time to concentrate our efforts into something else and start seeing other people, for a few reasons:
New frameworks bring new features
Usually one can always argue in favor of a specific framework and get away with it. There isn't one correct or better framework. That's why at the end of the day, sometimes it gets down to personal preference.... well, depends.
There are several valid and awesome frameworks out there and most of them use different methods to achieve the same thing, so, chose your method. But then, some new frameworks start to popup and they bring complicated concepts like two-way data binding, custom directives, virtual-dom, and a whole bag of new cool name sounding features, that are actually redefining how we should be working with frameworks right now.
When talking about cars, it always comes down to personal preference, sure. But a plane? That's always faster. And that's cool.
We've learned what needed to be learned
Why do we like to be challenged? Because we breach walls, learn new things and become just a tiny bit better than we were. When reaching a point where you are no longer moving forward with some technology, we strongly believe that it is time to open up new horizons.
Also, let's face it, "kinda new" is old in IT terms.
Cutting edge is fun
At the end of the day, cursing and punching the table after a 5 hour session of documentation and tutorial reading, trying to figure out why the code is breaking and finally fixing it, is what this is all about.
Why React and Angular2?
The internet is filled with specific "why Angular2" and "why React" posts. I'm sure we'll write our own take on it eventually but, for what this article is concerned, all that is important is that those are proven to be amazing and that they do represent the next stage in web development.
Those reasons are more than enough for us. We would do it just for the fun of it.
Both Angular (and Angular2) and React are not new to our ranks. We've worked on these before and love them, each in its own way. Of corse, not on a Backbone level.
Like said above, we've build countless content for Backbone and are now trying to grow past it. It is time to take React, Angular2 and other frameworks to the same development stage.
No knowledge will be harmed or lost in this transition.