Today’s topic is penguins, how they feed their young and how to apply that to Web development. Now watch my improbable feat of connecting these two topics. Come for the penguins, stay for the Web UI!
I am a father and as all parents know, part of the job description when your kids reach certain age includes suffering through many an animated movie (I am looking at you, Hoodwinked!). On one occasion though, I actually enjoyed the movie, and it happened to be Happy Feet. Those of you who watched it know that young Mumble is fed by his father Memphis eating a big fish, then regurgitating the half-digested food into Mumble’s beak, like so:
This is not from the movie but I don’t want to wrestle with Warner Bros over the copyright for the images.
As I watched the scene, I started thinking about what I like to call ‘naive Ajax’. I already gave Ajax its own blog post so no need to repeat myself here. Suffice to say is that when Ajax was young, making an XHR call to fetch some data was fairly straightforward and powerful. At that time, there were readily available services of the monster variety (Big Bad Services or BBS©). These services often returned horrible XML, and in the ‘all you can eat’ amounts. Developers didn’t want to bother with writing the services themselves, preferring to stay on the client writing JavaScript. They just called the Big Bad Service, suffered through the XML, threw most of it away and built their DOM nodes out of the useful parts.
I think you are starting to see the improbable analogy here: the unprocessed, big data service is like feeding the little Mumbo raw fish – too much for its little beak. Let me count the ways why that is suboptimal:
- Big services normally serve verbose XML with tons of namespace information. If you are lucky and the service supports gzip, it may not be a big problem (XML is insanely compressible), but if it does not, a lot of the bytes are sent down the wire unnecessarily.
- XML is not the optimal format to process on the client. You can let the browser parse it into a DOM tree, and traverse the DOM. However, that means that your JavaScript code needs to be larger because it contains nontrivial amount of logic just to traverse the data and sift it out.
- The data may not be fully digestible (see what I did here) – you may need to derive some of it from what you have received, or make more than one XHR request and sort out the joins in-browser.
- Very often you get way more than you need, which is wasteful because you waited and wasted the bandwidth and traversed a big DOM only to throw it away.
It would be foolish to assume that this is the thing of the past and that modern JSON services are much better and do not suffer from this problem. You may as easily choke your Web UI with a ton of JSON data – the only difference is that you will get huge JavaScript objects instead of an XML DOM tree. The accent is on ‘impedance mismatch’, not on the exchange format.
What is the ‘right way’ then? Use what I call ‘Happy Feet Services’. Write your own service on the presentation server (the one serving the rest of the Web app resources) in a service language of your choice. Make that service call the Big Bad Services, process the response, correlate the data, toss the unused parts away – it will do a much better job on the server. Once you finally bring the data set down to a super tasty little nugget, send it to the browser as gzipped JSON. It will arrive quickly because it is small, it will be turned into a JavaScript object by the browser, and your client JavaScript does not need to be very large because the data set is readily usable – no processing required.
If you feel lucky (punk!), you can go one step further and make your Happy Feet Service even more useful: make it dual-purpose using content negotiation. If you ask for “application/json”, return JSON as described. If you ask for “text/html”, send out the same data already rendered and ready to go as HTML markup – all you need to do is pipe it into a DIV using innerHTML property. You will have dynamic Ajax app with very little JavaScript.
For this realization alone, I would say I got my money’s worth. The only thing I learned from Hoodwinked! is not to give coffee to a squirrel. I knew that already.
© Dejan Glozic, 2013
Dejan Glozic 
Leave a Reply