I recently tested some RSS reader websites, and my conclusion is that the response times are not satisfactory for these to replace desktop newsreaders. Bloated code may sometimes be to blame, and anyone who's looked at the output from Apple's iWeb will know what I mean. In one case, I got suspicious and looked more closely; the design did not strike me as overly sophisticated and clearly would be manageable with a small amount of CSS. But here, one humungous chunk of JavaScript gets loaded every time you view a page - 12KB of code that remains the same, and the rest of the page unnecessarily written in DHTML.
The JavaScript could be cached as a separate file by the browser, and the rest should probably be static or cached on the server. In fact, this is a good example of where user event-based caching can be used. Each user has a namespace of urls, which I will call userspace, that he or she can access only after logging in. Hence, these pages can be generated and loaded into cache when the user enters, and purged when he or she logs out, or if the user becomes inactive and there is competition for memory on the server.
But to back away from the technical for a moment, what we are seeing is competition between bandwidth and small footprint of web applications on the one hand [1], and processor speed and application efficiency for desktop applications on the other. It's still a question of time before the web wins out completely, and the browser becomes the operating system.
[1] Don't worry about the servers - they'll be up to scratch if the demand and competition are there (user demand for web services; competition for speed of delivery).
Sunday, April 09, 2006
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment