Pointless.js (Better) Explained

In my previous post about Backbone I chose not to go into details. Apparently, even though appreciated, the bottom line wasn’t enough. People expect explanations...

So I decided to write another post that better explains why I think Backbone should be avoided as infrastructure for web applications (not web sites). However, since I didn’t want to waste too much time on this, I only included the highlights.

The most important thing to realize about Backbone is that it’s not really an infrastructure but more of a tool for developing infrastructures (not a very good one too). It heavily depends on external code, which is very annoying because one of the things that I expect from an infrastructure is to provide functionality that covers all major of aspects of the kind of applications it is intended for, without loosely depending on additional libraries. 

It doesn't mean that every bit of functionality needs to be developed from scratch by the framework's developers. Using 3rd party libraries is more than fair, however, if this is the case, then the least the framework could do is to bundle everything together instead of sending its users on a search and pick mission. Take a look at the following code snippets that demonstrate the minimal requirements for writing a serious application with AngularJS, Knockout, and  Backbone:


<script type='text/javascript' src='angular.js'></script>


<script type='text/javascript' src='knockout.js'></script>
<script type='text/javascript' data-main='main/js' src='require.js'></script>


<script type='text/javascript' src='jquery.js'></script>
<script type='text/javascript' src='underscore.js'></script>
<script type='text/javascript' src='backbone.js'></script>
<script type='text/javascript' src='backbone.baysitter.js'></script>
<script type='text/javascript' src='backbone.nested.js'></script>
<script type='text/javascript' src='backbone.validation.js'></script>
<script type='text/javascript' src='marionette.js'></script>
<script type='text/javascript' data-main='main/js' src='require.js'></script>


These three example roughly represent the dependencies required for each of the frameworks to provide a decent starting point (I dropped a few of Backbone’s dependencies because these are enough to prove the point). You can imagine how tasks like upgrades and licenses management look like. Every little task becomes an involved operation... This is, BTW, one of the reasons why Backbone is so small (in terms of file size).

Another reason is that the development team will be doing a lot of infrastructural work.
That's right! Getting anywhere with Backbone means writing a lot of code.

For example, while other frameworks handle data binding (one of the most fundamental and repeatable tasks), Backbone leaves this task for its users.
The same is true for data validation, where Backbone goes as far as providing a placeholder for validation code but leaves the work for developers while other frameworks provide a declarative way of enforcing data validity.

Writing all of this code isn’t something you want to do because, aside for having a lot of code being  downloaded to the browser, you’re going to have a considerable amount of testing, debugging and maintenance to take care of.

Add to all of this the fact that there's no clear separation of concerns between framework components and you already have enough to keep you away.

Backbone is a frustrating framework. It is too minimalistic and often requires external solutions that add missing functionality or fix an existing one (like when the backend isn't restful). 


Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com