I'd separate the notion of a framework being "MVC" and of it being "client-side" (or "Thick Client").
MVC in itself is great. It promotes DRY, and can drastically simplify and consolidate your code. No need to wait for that.
"Thick Client" solutions tend to move a lot of the application logic to the client, turning the server into more of a lightly abstracted database. This is good if you are wanting to make a responsive app that can easily go off-line. It's also good if you are looking at reducing hosting costs - after all your server won't be doing a lot 90% of the time.
However it does have its down-sides - you have to worry about syncing, slow clients, and of course people can more easily steal your code.
Personally i think these "Thick Client" solutions are great in theory, but they are not going to be ideal for every type of application. So i'd wait until i was going to implement something that really needed off-line or very responsive functionality before i would actually use them for real.
I would be concerned about the flexibility of coupling between the server side and client side. In other words is the choices in he client side MVC messing up the server side MVC and vetc.
ItÂ´s yet a relatively new topic, but I think client-side mvc frwrks are catching up. To name a few:
- SproutCore: http://www.sproutcore.com/
- TrimPath Junction: http://code.google.com/p/trimpath/wiki/TrimJunction
- Axiom Stack: http://www.axiomstack.com/
- Archetype : http://archetypejs.org/
And now comes the doubts:
- Is it really a good idea to use mvc pattern in the client-side?
- If so, mixing directory structure from some client-side frwrk with RoR will be very confusing
- Maybe the best thing is wait until RoR integrate some of this frwrks?
IÂ´d like to hear some personal opinions in this suject.