If you use Backbone.js or Spine.js, should you use MVC for all dynamic parts of the view, or just the more complex ones?

Question

I've just started using Spine.js. I like it.

But sometimes I just need to make a simple call to the backend to get JSON data to fill, say, a navigation bar that won't be changing after it gets populated. Here, making a front end model and controller seem like overkill, when I could just use a simple jQuery call and push the JSON response into a template and inject the result into the DOM.

Is there any disadvantage to this hybrid approach, where some of the view gets managed by JavaScript MVC and others just get injected by simple jQuery Ajax code?

Answer 1

The whole idea behind MVC is separation of concerns. A Model handles data, a View handles display, and a Controller handles flow and in some cases business logic. Sure, you could easily make that jQuery call within your view; after all, JavaScript is wide open, and as long as you can get a reference, you're free to do what you want. But doing that defeats the pattern and muddies the waters of the role your view plays. All in all, if you adopt the design pattern, stick to it. It'll make managing your application months or even years from now a lot easier because you won't have to think about the roles of your components.

Answer 2

I say you should do it for all.

I don't think your choice should be a matter of the difficulty of doing so, its that if you establish a standard, stick to it. Doing so usually saves time in the end.

Answer 3

Well, the first question I always ask when confronted with one-time injected JS is whether that shouldn't happen on the back end in the first place.

As for the matter of consistency, if it takes very little effort to do it the 'wrong' way, go ahead and see what happens. It's not like it will be a ton of work to change it later if needed and I really don't see why you'd burn time and/or unnecessary overhead to your app just to be consistent.

The important thing is that you make it obvious you're not handling that via the MVC approach in your code for the next dev. But at the end of the day, the tool is there to help, not hinder you. We all make some exceptions on the separation of concerns where css, html and JavaScript are concerned as well. The important thing is to understand the true value of the rule so you know what the tradeoff is when you break it. In this case, I don't see much of one.