I’m sure I’m not the first to suggest this, but here goes.

Ever since somebody first thought of applying the Model-View-Controller paradigm to the web, we’ve had this:

The View is a conflation of HTML and JavaScript. JavaScript is an afterthought, a gimmick to make pages “dynamic.” All the real action is in the Controller, which talks to the database, processes the internal application logic, and renders templates before sending complete pages back to the client.

But what if we implement the Controller entirely in JavaScript?



Now we can put the Controller on the client, and build a RESTful HTTP interface to communicate with the database.

Obviously there are many issues to consider. First and foremost is making sure that rogue clients cannot do anything to the database they’re not supposed to. But that’s a manageable problem — Amazon S3 is a good example. Apps that run entirely in the client can even be made more secure than their server-based counterparts, because encryption can be implemented entirely in the client, so that the server never sees the unencrypted data. (Clipperz, an password-storage service, calls this a zero-knowledge web app.)

There are some interesting possibilities. For example, the entire application, including the current state of the model, can be downloaded as a single web page for off-line use. (Clipperz supports this.) Also, the same application could connect to multiple data sources. And as with any RESTful architecture, back-end scaling is relatively easy.

Update July 10, 2008: I’m always amazed when one of my posts show up on Reddit. Maybe it was the diagrams. In any case, thanks to everyone who sent in comments. A couple responses:

Yes, in a sense I’ve described Ajax. But most Ajax-related code around the web these days is still in the “dynamic view” mode rather than the “client-side controller” mode. I like Sun’s MVC diagram in which the View takes an active role in rendering the model rather than being just a template. It’s actually quite similar to what I’m suggesting here. Some MVC frameworks, such as Ruby on Rails, insist that logic in the View is bad, but then they include all these Ajax view helpers, so it’s a bit of a mixed message. I’m not insisting that all business logic be implemented client-side. Rather, I’m assuming some kind of “smart” database, with a RESTful front-end, that’s capable of containing business logic. Back in the day, these were SQL stored procedures. Now it’s probably something like CouchDB. Yes, this design is bad for search engines, bookmarks, and deep linking. But there are plenty of cases where those don’t matter. Look at Google Mail, for example. It basically follows the design I’ve laid out here: the entire app is one HTML page (or a very few pages) with behavior implemented in client-side JavaScript.

Update August 7, 2008: This is an example of the code-on-demand style described in Roy Fielding’s REST thesis. Link from Joe Gregorio.