AJAX Apps -- Cleaner Connections, Less Bandwidth? Maybe Not.

Port80 software and a blog post on AJAX Apps – Cleaner Connections, Less Bandwidth? Maybe Not… re-raises some interesting points on the relative server load increase an ajax application might cause vs. the traditional page-by-page web app. Intuitively you might think that the net amount of data transfer would go down as less redundant data is re-sent for each page. But as this post points out, the use of polling via ajax has the potential to actually greatly increase server load.

Of course this is apples to oranges. Polling itself isn’t new with ajax - it might have been done previously with an iframe and a meta-refresh or a javascript reload. What is new is the relative ease with which increasing sophistication of web apps can be attain using ajax. If the application is doing more work, and the user is getting more value, we shouldn’t begrudge the bandwidth used in getting there.

is the DOM ready yet?

This post ( Order of Events @ addresses the need for a better solution than window.onload for DOM scripting. window.onload only fires after all the content on a page (including images) has loaded.. which is frequently significantly after the page has appeared in the browser. Mozilla/Firefox apparenly have the little known “DOMContentLoaded” event. Very handy. Windows IE has the readyState (or, better, the also little known ondocumentready event. Take this and brothercake’s domFunction and there’s a cross-browser solution in there awaiting the motivated developer. Errors and AJAX

Client-side script errors seem to be everywhere, and no-one either knows about them or takes them seriously enough to fix. This article ( Errors and AJAX) proposes a solution (and supplies js code and a sample perl backend) to catch and send errors back to the server. (Of course one irony is that of all things that can go wrong, an XmlHttpRequest implementation is likely to be up there.) The premise is that you include this file or code block on every page of a site (after testing thoroughly). That way if future script errors are introduced, they will show up in your server’s error logs. Anything already watching the error log will see the error (and the appropriate people can be notified, paged in the middle of the night etc.)

As web applications move more functionality to the client, the responsibility also increases. This seems like a good practice to adopt to bring some of the rigour and accountability you’d expect on the backend over to the frontend.

Test case for TBODY/THEAD/TFOOT with overflow

I happenned across this test page while looking into scrollable table implementations: HTML Test Suite for UAAG 1.0 (Draft). I demonstrates how it ought to be done: you assign overflow: auto and a fixed height to the table’s tbody, and you’re done. Sigh.. if only it was that easy.

The test does work in my Firefox 1.0.3, but then there’s the horizontal scrollbar. If you add in a 16px scrollbar, you just hid 16px therefore a horizontal scrollbar is necessary to scroll over to see it. Makes perfect sense but its maddenning, because as of this writing I’m unable to remove the need for it. There are other ways to get there of course, but it want this one to work!

For the record, border-collapse: collapse throws a spanner in the works in mozilla + cousins. Here’s that illustrated: 1, 2.

Perl Design Patterns Wiki

There’s a world of goodness over at the perl design patterns wiki. Take this little snippet:

foreach my $i (qw(name price quantity)) {
my $field = $i;
{"get_$field"} = sub {
my $me = shift;
return $me->{$field};
{"set$field"} = sub {
my $me = shift;
or die "not enough arguments to set_$field, stopped";
$me->{$field} = shift;
return 1;

..All your getters and setters, done. I’m in awe, and I’m dumping php and going back to perl :) This and other wisdom comes from the AccessorPattern page.

Adobe / Macromedia

Well, this is some kind of news. I’m at a loss to see how anyone but possibly some shareholders will benefit though? This is not a sector that really needs consolidation, and (assuming product lines merge) I think most designers and developers will miss the Macromedia alternative.

Does it matter who makes Flash? Dunno. Dreamweaver vs. GoLive? I’d take DW, but I’m not going to pitch my tent outside Adobe’s offices to petition for its continued development. Homesite? I’m still using Allaire’s version. And the silver lining - I guess I can take Fireworks off my must-learn-more-about list.

User defined colors (CSS property values)

I learned something new today… font-family: menu. This should serve (me) as a reminder to go read the specs a little more often (or buy books, or both) as none of this is news. Anyhow, thanks for bringing them all together on one page .jeff


I just saw Dot in action here at work the other day - generating flow charts in SVG on the fly from a database of screen specs and interactions/workflows. Interesting and positively plump with possibilities. Generating and maintaining these kind of documents has been an irritation for me for years - particularly as the information they capture is essentially locked up and only accessible visually.

Implementing a workflow has always meant essentially starting over - with the document serving as a reference only. By flipping this on its head and making your flows output, rather than input, your application logic can stay fluid and be developed independantly. Ideally you would be able to round-trip - so you could model an interaction or workflow in a tool like Visio or Omnigraffle - export or merge into your XML that captures the application logic in its entirety, test, tune, and re-output to a Visio/Omnigraffle importable format for futher refinement. As I understand it this capability exists…

Any opportunity to defer the permanent entanglement of application, business, presentation logic allows for more testing, refinement and interation, at less cost. We don’t necessarily need DotML to do this, but it will help. Once it becomes XML, half the work is already done for me.