Re-Thinking the Web Framework

Posted on Jul 28, 2010

Since I moved away from rolling everything by hand and hopped on the web framework bandwagon, I haven’t looked back. Having the ORM tied into the URL dispatcher and templating engine in one unified API is really nice. Everything I’ve needed to build in a website is handled.

However, since about the same time I started using framworks AJAX started making a come back. At first most of the clients I worked with didn’t take notice of it. As it gained traction however, the whole thing started to change. Now more than a few years on most clients practically expect it. It’s almost taken for granted.

The thing is, very little of the web sites and applications I build today are page-based. I think this trend is only going to continue. These javascript frameworks are becoming more like thin-clients requesting data from web services. This has forced me to contort my web applications to bend around this idea. The frameworks still think of dispatching a URL and sending out a rendered web page. Now more often than not they just need to spit out some JSON data. Most web sites and applications these days are rather sophisticated client UIs and they don’t make calls to a server for pages. They want data.

While I’m not the biggest fan of AJAX-based clients, I don’t think I’m going to win this one. So I decided to join in and I wrote a JSON-RPC controller class for Pylons. Many javascript frameworks support JSON-RPC so I figured my web framework ought to as well. If you can’t beat them, join them.

I think more frameworks should evolve into JSON-RPC frameworks. Or perhaps new frameworks entirely should spring-up that are based on simply providing data services instead of web pages. Let the javascript clients worry about the UI entirely.