Javascript – Patterns for ajax-heavy web applications

ajaxdesign-patternsjavascriptmvc

Up until now, I've been a great fan of the MVC pattern for developing web applications. For the web, I've developed mostly in PHP (with the Kohana and CodeIgniter frameworks) and Ruby (RoR).

As my applications become heavier on the Ajax side (single-page apps etc) I noticed that I can't help but betray the very basic concepts of MVC: Javascript is doing most of the works; calling controllers just to ask for views or more js/json code seems wrong.

After striving for keeping all the routing jobs in the controllers, now I've fundamentally split it between them and Javascript (that is, from the framework's PoV, part of the views). When asking for json the MVC subversion looks even more obvious: the js code doing the request is the controller; the framework's controller is merely acting as proxy for the model's data – what I'm actually asking for.

So, what should I look into?

I was thinking about pure-javascript applications, for instance with backbone.js and a document-based, json-spitting database (couchDB) as backend, but I love my relational databases.

Another option would be the following: I'd just make "routed models" in PHP/ruby/go/whatnot. Those will analyse the request, call the db, give back some json.

This approach looks interesting to me but it lacks any substantial documentation or academic analysis, so I'm a little afraid of the leap.

Ideas?

Best Answer

If there isn't any academic analysis, do it yourself. Just experiment on your next small scale project, and see how you like it. Read Paul Graham's essay on why he choose Lisp for his startup, even though it wasn't commonly used. http://www.paulgraham.com/avg.html

There are plenty of MVC javascript frameworks out there. If you want to build a primarily javascript application, then do it.

Just build a restful API in rails or whatever framework you use that is just a wrapper for the database, and you won't have to give up you're relational database. Just call the api like you would call the database if this were a server based logic application.

Additionally, if you build your app this way, you can build in offline support very easily.