How do js mvc libraries like spine, backbone, jsmvc integrate into a Server based MVC framework like lithium or zend?

Question

My specific question is that I would like links to references so that I can learn/research the question title, not spark a debate about the features or which one is better. I have found jsMVC , spine , and EJS but am not familiar with what place they hold in the MVC pattern. Aren't they basically just views themselves since they handle rendering ? so does that mean a client MVC is like a sub pattern with the V of the server MVC ? Links that provide background and theory on how these client side libraries work inside/with a traditional server side framework would be helpful.

Thanks!

As I was writing this I read this answer and this type of answer helps, more like it with reference links would be great.

Answer 1

Client side MVC can handle the entire MVC stack. If your using both server and client side MVC then your duplication your models and routes.

Client side MVC basically allows you to bridge your server and client together. Why should your server send views? Why not send the model as json and load it into a client side model and have the client render that view.

You can even go further with the routing. Why have the routing handled by the server? The client can do this. Just allow the client access to your RESTful database and you don't need any serverside MVC.

Of course if you want to support non-javascript then you need server side MVC.

Personally I use a heavy client / heavy server setup. I use the entire serverside mvc for the first page load. From then on the client upgrade itself to only use clientside MVC if it can with javascript. If it can't it continues to use serverside MVC.

This kind of development is made a lot easier by having SSJS so your models, collections and views are a shared codebase and only maintained in one place.

Answer 2

Utilizing a client-side MVC framework can be useful for code organization when dealing with very large, Ajax-reliant applications. Consider a client-side Model layer that consistently talks to one or more services provided by individual applications in a Service-Oriented Architecture. The individual service providers may implement their services with an MVC or not, but there's an advantage in having client-side Models to consume that data.

Keep in mind, too, that Javascript frameworks - whether jQuery, Mootools, Node.js - are going to implement an event-driven control workflow, where a single event can trigger callbacks that cascade into other callbacks. Typically on the server-side, at least where the HTTP request-response cycle is concerned, we want to create discrete, atomic tasks that generate a quick and redictable response and may trigger or enqueue some other asynchronous event on the server, because the response is blockking the user from making another request and continuing his workflow. Not so for client-side Javascript.

Adding a full client-side MVC to the stack when you're already utilizing a MVC framework server-side can be overkill and may lead to a duplication of effort. It can be done correctly. Specialize your server-side code into access control and CRUD operations, returning JSON instead of HTML views. Specialize your client-side code into view processing and event handling using light-weight models expecting a JSON data store with conventional, ReST-ful routing. Use them for what they're both good for to get the most mileage.