Web 2.0
It might be a trite buzzword, but there really is a new way of doing things behind it. (I’m not sure that changing development practices will actually lead to a market shift, so ‘Web 2.0 economy’ still sounds over-hyped and stupid to my ears.) I have fully made the transition into the realm of rich clients, distributed computing, and RAD MVC frameworks.
About a year ago, I stumbled across a little project called Ruby on Rails. I had made a few unsuccessful attempts at learning Python at that point, but it had never really stuck. I’d also spent some time slogging through the PHP mines and was rapidly coming to the conclusion that this whole ‘web-based application’ concept was doomed to failure (or banishment to Java-land, which is pretty much the same thing to my mind). Thus, I was on the verge of refocusing more intently than I had before on low-level, we-use-C-because-nothing-else-will-work type programming. Then, as I said, I found Rails. And everything changed. This plucky little framework, written in a language I had read (maybe) two articles about, was winning people over at an atrocious rate. And once they tasted the Kool-Aid none of them were looking back. So I gave it a try, and I was instantly hooked.
Still, reality reared its ugly head and I found myself confined to PHP4. Luckily, a Google search for ‘Ruby on Rails in PHP’ (or something very similar) led me to the CakePHP project. It is my firm belief that Cake is as close as you can get to the holy grail, PHP4 on Rails. Needless to say, I have spent the time since then developing Cake-based applications and enjoying it immensely. (Even more so when I have to make a detour into the tortured realm of Mambo/Joomla. Now, granted, I am biased and the CMSes are a layer above a framework, but every time I build on Joomla it feels clunky and ungainly.)
I kept to that system up until a month ago. I had a small interface requirement that was best served with an AJAX-style callback to the server. So that’s what I built. Specifically, I used Cake’s built-in generator to make a Script.aculo.us-based auto-fill text field. And it worked, perfectly. Then I started poking around the Script.aculo.us site and gaining ideas. Ideas are always dangerous because they have this habit of leading to drastic changes. This situation was no different.
With a working XMLHTTPRequest and dynamic DOM manipulation in play, I decided to rework other areas of the application in the interest of performance. Basically, combine the view and edit screens for objects into a single page with an ‘edit’ button to toggle back and forth. And it was good. Snappy performance and interesting code, what more can a developer ask for? Plenty, it turns out.
In building the infrastructure to fling HTML snippets to the client and form submissions to the server the back way, I had gained a working knowledge of the Prototype library through use and extensive reading of Sergio Pereira’s excellent Prototype documentation. The wonderful thing about Prototype is it’s onion-like quality: every time you get comfortable with it’s functionality, you peel back yet another layer that provides even more powerful utilities. (Of course, Prototype is worth including into any dynamic page for the $() function alone…)
(At this point, I had become much enamoured of JavaScript’s object model. And, luckily for us all, Chris Heilmann has written an ode to the object literal that encapsulates the subject better than I could.)
But, while I was now flinging requests across the ether, and wrapping the DOM around my little finger, I was still getting little chinks of HTML from the server. And while that was fine for the moment, I knew that my ultimate ambition was to completely bifurcate the Client from the Server portions of the code and, at the same time, make it possible to have non-web-based clients. (Specifically, I was, and am, thinking of RealBasic as it is one of the easiest ways to build a Windows application without leaving my Mac.) I knew XML was a nice, generic solution. But my experience with XML in PHP has always been rather clunky. And a little research showed that working with XML in JavaScript was, if anything, worse than working with it in PHP. So my move towards compete bifurcation was stalled.
Enter JSON. A simple, light-weight, text-based object notation that JavaScript already has a built-in parser for. Wow. I’ll say it again because I mean it: Wow. When enough small mentions of JSON had percolated in my head that I actually looked into it, the experience was akin to clouds parting and a beam of light falling on my face. This was exactly what I had been waiting for. Less than an hour passed between the first time I loaded http://www.json.org/ into my browser and my having fully integrated JavaScript- and PHP-based parser/generators into my current project and scarcely more time before I’d started reworking chunks of the inner workings to take advantage of this wonderful technology.
The two biggest objections against JSON that I have encountered are: 1. JSON is not XML, and 2. Running eval() on random text sent to you by some random website is a Very Bad Idea. It may seem odd, but I agree completely with both these statements. JSON is not XML, it is a new technology, and choosing some obscure upstart over the established standard is always a mistake. In this case, however, I think JSON is the better option. The data in question is passed around in very small, very short-lived chunks that get converted from and to native data structures immediately before transmission and immediately after receipt. Why use a verbose syntax like XML when the only thin g that will get a chance to appreciate it’s self documenting wonderfulness is the transport layer? To my mind it makes much more sense to use a more compact, less flexible syntax that does the job. As for running eval() on random text: Don’t do it. JSON.org has a collection of validating parsers for JSON in a number of languages, including JavaScript. Using the validating parser (in combination with JSON’s carefully chosen syntax) allows you to move objects in and out of JSON with confidence.
And that’s where I stand at the moment. My current project is two distinct parts making up one entity. The interface is a small amount of (Cake-backed) PHP on which is hung the JavaScript that does all the real work. The back-end is a much larger collection of PHP that makes far more extensive use of the Cake libraries and spits out nothing but JSON objects. The next logical step is of course to finally break these parts out into independent applications. But, for now, that can wait.
cakephp, json, ajax, ruby on rails, php, php4, javascript, script.aculo.us, prototype
