Intro
Backbone.JS is not a new kid in town and is being discussed during the previous year.
Gordon L. Hempton has reviewed its' competitors with the conclusion that Ember.JS is the only framework that has everything out of a box.
I just want to analyze when Backbone is good choice for an enterprise product.
Borders of Backbone
By saying "borders" I meant limitations of Backbone.JS implementation and use cases, so this will define a comfort zone for this framework.
Aspects of usage
Firstly, Backbone.JS is an web framework for single-page web-applications that have view-states. Each state could be represented by hash-route. This means that application could be reloaded with a given hash-route as an entry point. Unlike Adobe Flex it does not provide native support for state-management infrastructure out of a box. So it's up to you how to implement the state handling mechanism.
Secondly, BB is not a MVC framework in it's classic way. View class acts as the view and the controller at the same time. You have no special guidelines to class itself but when rendering is not linked to model changes by using events view acts as a passive representer of data and it's not clear when to trigger render method.
Thirdly, this framework is highly-adopted to a flat domain model architecture. It provides us with model and collection classes for organization of business logic and domain model. For more complex cases when deep and nested models are required you will need to use the Backbone-Nested plug-in. I would not recommend you to reinwent a wheel in your projects cause in the end you will come to the same idea.
Fourthly, Backbone is designed to de used with a single data provider, REST web server with JSON output by default. If you have legacy backend that is not designed for REST API and/or uses XML as an output, then you will need to implement custom sync mecanhism. If you have more than one data-provider beside this, you might consider usage of Backbone.localStorage or Backbone.WebSQL plugins as helpers.
And finally, Backbone is not a dictator that allows only way to build an application. It provides you with a skeleton and it's up to you how to organize muscles, nerves and bones.
What need to be considered before to start
- UI components library usage vs custom components via templates and CSS.
- DOM library: jQuery or Zepto.JS
- Underscore templating or something more advanced
- Synchronization with the backend
- Caching of data for offline usage
- Localization: Moment.JS for date/time stuff, i18n aspects are covered here
- Modularity: LAB.js and Require.JS
- ORM when you need to implment persitence of data
- Global events pub/sub: offline, change locale at runtime, login/logout, etc..
So what?
As you can see you need to pay the price for the freedom of choice when you are composing your backbone based stack for your application. Again, backbone does not provide you with a single proven way to build an app. So, let's describe cases when it's worth to use Backbone.JS stack and when to look into the other side of the moon.
When to use it
- The requirements are changing frequently and you ned to adopt your architecture to them
- The UI is based on templates and you just need to react on standard events in views. Usage of UI components is an advanced topic and will not be covered here.
- The server provides client with the REST API. Exotic legacy servers that were designed for native apps need to be discussed separately.
- You are comfortable with the getters/setters and the events concepts.
- You are comfortable with the BB implementation of OOP via prototype.
- And the main one: you have time for the research
Outro
I'm going to write more about this framework and it's usage for building cross-browser mobile web apps.
Further reading
Plugins
- Backbone.Marionette - first plugin I ever met that allows to implement application without mess of own infrastructure classes.
- Backbone.Nested - plugin for organization of complex models
Немає коментарів:
Дописати коментар