Comment by wildmusings | Hacker News Reader

Comment by wildmusings | Hacker News Reader

     True this maybe achieved by refreshing the whole
     comments container   but what if he is also in the 
     middle of replying to another comment? What if we want 
     that new reply to show up in some sort of animation?

You can achieve this pretty easily. You shouldn't be refreshing the entire comments container. If your views are well modularized, the comments container would render many _comment partials. You would simply render a new partial and insert it into the page appropriately. There's no reason to disrupt the rest of the page.

When you do client-side MVC, you end up having to duplicate a lot of your model and controller logic. This happens either explicitly, when you start defining relationships between models and how they should react to changes in associated models (e.g. backbone-relational), or implicitly, when it gets stuffed into view and "routing" logic (and leaving you with spaghetti code that's different but no better than jquery spaghetti). In rails views, you have access to the real model objects and you can still use AJAX to have a "single-page application" without the huge added complexity.

There's obviously a place for client-side MVC and that is RICH APPLICATIONS. Google Docs, Pandora, a photo editor, etc...

I think another factor is what your team looks like. If the person writing the models and controllers is the same guy making the front end, then you should probably stay away from client-side MVC. If you have dedicated frontend/javascript guys, then it might make more sense..

The point is that if you need granular partial refreshment, your javascript needs to be a lot more smart, like what to do when add/update/remove a comment - that is you end-up writing view logic both client-side and server-side. As stated in the article, the view logic needs access to both server-side data and client-side DOM, where it resides depends on which side the view logic requires more communication. The argument is that if you rethink HTML, then most web app should be designed in a way so that UI interaction significantly improves the UX. That's why we need client-side MV* to be an enabler for such re-thinking.

Our main product is at it's heart nothing more than CRUD, except some of the forms are pretty complicated where you have to deal with nested record hell. Initially we just did everything the Rails way (i.e. jQuery and AJAX), but we have been looking to move stuff more MV* client side where possible.

I don't think either solution is really that great at the moment. Doing things MV* client side mean you duplicate views and potentially logic (we use decorators a lot which would need to be duplicated). Doing things via AJAX means you have to wait for the response before the view is updated (things like comments that will succeed - assuming validations are done before the request is made, and the server doesn't break - shouldn't have this delay).

One thing we have done that has helped, is instead of just attaching a load of jQuery events on random elements, is writing our Javascript in a similar style to Backbone views. Instead of writing everything with lots of nested events, we have a 'controller' responsible for each feature. On initialisation it binds to the DOM events it needs, and those call other methods on the controller. It also has it's own (local) state, so if we need to use the same feature multiple times on a page we can do with ease. It has allowed us to separate code better, and more importantly make it more legible. Here is an example:

https://gist.github.com/lucaspiller/5040983

The whole point of node.js/meteor is that you can share the code between client/server, so you dont have to duplicate anything, and have the access to the "real" model.

Reply on news.ycombinator.com