Rails has a means to update its presentation layer via js files and js.erb files, what are some of the specific benefits of using a framework like Backbone.js?
相关问题
- Carriage Return (ASCII chr 13) is missing from tex
- Question marks after images and js/css files in ra
- How to fix IE ClearType + jQuery opacity problem i
- jQuery add and remove delay
- Using :remote => true with hover event
Here are a couple reasons:
1) Backbone was built specifically with Rails in mind, and integrates easily with the help of backbone-on-rails. While the Model-View-View Model (MVVM) patterns of Knockout and Angular could easily be incorporated into a Rails app rather unobtrusively, Backbone's MVC architecture provides a level of organization that really seems necessary if your app has a lot of asynchronous page updates. Take this Stack Overflow page for a quick example:
If you were building this question view in Rails, you'd have your question show.html.erb, question_show.js, show.js.erb, and all other js.erb files that pertain to asynchronously updating the content on this page (actions such as up/down-voting, favoriting, commenting, etc.).
In Backbone, a view is not a markup template like show.html.erb, instead, it contains all relevant code to that markup resource in one spot. So, instead of defining all your event listeners in a remote, question_show.js file and handling all your AJAX updates in various js.erb files, all event listening and publishing relevant to the questions show resource is contained in one place, the Backbone question show view. Granted, comment could have its own view and comments their own collection, as well as other MVC elements I'm not mentioning. But point being, Backbone helps you define front-end resources.
2) Choosing a JavaScript framework like Backbone helps take some of the load off your server for code that really doesn't need to be executed server-side. Why render all your markup elements in html.erb templates on the server when it could be done in the client's browser. In response to questions of security, you have the ability to whitelist/blacklist database object attributes when formatting your database object as JSON and shipping it to the client.
3) Backbone (specifically) seems to give a good amount of freedom. It provides a set of conventions to help organize your application, but at the end of the day it's your framework you're developing. The MVC framework of Backbone is less one-way than Rails, yet the solid conventions persist.
4) With Backbone (not speaking for or against other frameworks), pushState is easily implemented into a framework that expects its use cases. However, pushState has its downsides in terms of crawlers accessing your content, and requires some server-side rendering to be incorporated in a crawler-friendly way. What's great though, is that you can attain the same history/degradability in using Backbone out-of-box; their url fragments allow for the same functionality, they just have an extra # in there.
There are plenty of other reasons to use a framework like Backbone, and it really seems like there are a lot of alternatives because one framework does not fit all. But for what I can attest to, Backbone seems to be a great framework if you're building an app from scratch. And it also seems very doable if you want to incorporate it into an existing application.
Source: Backbone.js on Rails