使用Backbone.js路由器进行路由而不是使用服务器端代码的原因

Question

When and why would I use Backbone.js Router for routing instead of routing via server-side code? Could someone elaborate on that since it's my first time exposed to do routing on client-side.

Answer 1

You've presented a false dichotomy. The reality is that there is probably never going to be a situation when you'll use Backbone's router in place of a server-side solution. That said, there is certainly a growing trend toward using client-side routers in general (not specifically Backbone's) to create one-page apps—eg, Ember.js . Here are your options:

Only server-side routes

This is the classic approach that is a big component of frameworks like Rails. It is a mature strategy that draws very bright lines between your models, views, and controllers. It's certainly not going away anytime soon, and for good reason: it's great if you're not developing a one-page app, which most people aren't.

Only client-side routes

This is what things like Ember offer you. You can write all of your routes on the client-side, and then the client is responsible for updating state, throwing old objects away, etc. This requires a robust JavaScript implementation of models, views, and controllers to work properly. Otherwise you're going to quickly end up with a pile of rotten spaghetti. If you're going to do this, do not use Backbone . Backbone's router works best for simple things like state. There is simply no clean way to use vanilla Backbone to replace a server-side router.

Hybrid approach

A hybrid approach is where Backbone's router will shine. You use server-side routes to serve the views/templates, and then you enhance them with Backbone's routes. Here's a few examples of that:

1. A user profile page that has an inline editor. The route might be: /users/me#mode=edit , where /users/me is a typical route served by the server, and #mode=edit is a Backbone route that changes the view to an 'edit' mode where the user can edit his profile info.
2. A calendar that highlights a date. The route might be: /calendars/work#date=today . Here's an example of something you just can't do with a server-side route: highlight a particular cell of the calendar (namely, today ).

Unless you're set on writing a one-page app, it's safe to say that you won't benefit too much from using a client-side router. And even if you are writing a one-pager, you probably shouldn't look to Backbone to do it.

Answer 2

Benefits

• fast, normally you only need to load one portion of the page
• memorable, history is kept page and you can control what goes into history, what's not
• organized, as you are building a client-side application, it's good to have all the necessary logic at client side, including important component like dispatcher (router)
• easy to do, implementaion is almost same as server side, you specify routes and handlers, then links in the anchor href attr.

exception case

• when you want to do form submission consisting files, it's easier to just use action url to handle multi-part data

just my 2-cents

Edit: deleted " as server-side" in memorable line.

Answer 3

It's entirely a matter of preference. It's basically another version of asking when to do an AJAX request rather than a full request. You could use Backbone entirely for routing with a single page app and then just have the back-end represent a pure representation of the model through an API. This would be particularly helpful if pursuing an HTML5 -> Mobile type of solution. I'd recommend a more tempered approach to start with depending on the skill set of you and your colleagues.

The best first step would normally be to make sure to use something like a Backbone router to represent addressable front end state changes that are aligned with the primary application purpose. If the front end is doing things like displaying a detail view which is created from an AJAX request, then rather than implement that through an event handler attached to some UI element, you should implement it using a hash segment and front end routing which the UI element links to. So for instance the UI element would just be a link to something like /#/item/45 and then the router would pick that up and run the handler attached to the pattern like /#/item/{itemId} . This better represents the state and opens the door to leveraging browser history and creating links that use the existing front end code in a clean way.

After starting with this you can implement routers increasingly as desired.

Answer 4

Why I would use it:

• Cleaner UI application code. Centralized approach to the concerns. This plays big role for the complex UI applications .

Next two items are somewhat related to the client side routing (not directly though):

• Ajax requests don't need to get whole page back (though still could).
• Ajax requests can use compact format of the data (such as JSON) that makes request processing even faster.

---

Why I would not use it:

• SEO becomes a little harder to accomplish. Client-side routes mostly map to the client side functions, not URLs. This means, search engine will see links that don't lead to the different content pages. This, obviously, is not desired. To some extent, you can try to overcome it using site maps.
• As another overcome to the above problem, website developers sometimes have to support the same URL structure (routing) on both client-side and server-side. This is more efforts for accomplishing the same end-result . This, in my opinion, is a mistake, because such websites were thought as public in the beginning but were designed as private. In the most cases, such applications could have been designed just having Ajax in mind, but not client-side routing.

---

Conclusion:

That being said, in my opinion, client-side routing makes most sense for rich UI applications that don't need to be crawled (mostly because they are password protected).

eg email, chat, enterprise applications, games, other custom applications.

On the other hand, as you may have noticed, websites intended to be crawled don't use client-side routing.

eg blogs, public websites, wiki pages, etc.

Worth mentioning, you can mix these two approaches in the same application as long as it has different sections falling into different categories mentioned above.

Answer 5

For a single page application, the browser is not redrawing the whole page every time the time user makes an action and content is instead generated by Javascript and injected into the page. Client-side routes maintain state in the address bar so that a user can return to that state directly, which makes those states bookmarkable, sharable, etc.

You still need to do server-side routing. From the Backbone docs:

For example, if you have a route of /documents/100, your web server must be able to serve that page, if the browser visits that URL directly.

Answer 6

You will do server and client side routing.

Requests from your client to the server still needs to be routed on the server. From your server's point of view routing is still done for Ajax requests.

The client side router is used to route #links to your backbone app. So when someone clicks on a # link your router will will pick this up and action it - most probably fire an appropriate event.

The the routers are very different and for now I cannot think of any circumstances where you'll use the one instead of the other.