Burningbird

This post was lost in the merger. Luckily, it was still cached in Google Reader, so I was able to recover and re-publish. This originally appeared in Mad Techie Woman in February, 2007.

Three comments in my last post highlighted three major issues with widgets: web service optimization, rendering, and JavaScript done poorly. Considered all as one, they define the parameters of widget behavior.

Bud Gibson writes:

Part of the issue with browser based widgets/ mashups can be the rendering time in the browser. Apparently, the next version of firefox is supposed to contain my optimizations for DOM manipulation.

One of the major problems with rendering has to do with managing the difference between browsers. If we didn't have to code in checks for, say, Internet Explorer, in most of my code, it should run a little faster. Additionally, one of the properties used to render page contents, innerHTML, is one 'frowned on', because it's non-standard. We're supposed to use the DOM for all page manipulation, but as any Ajax developer has discovered for themselves: one innerHTML is faster than a dozen or more DOM calls, no matter how efficient the code.

Still, machines are getting faster, and the same problems that would lead to slow rendering of JavaScript lead to slow rendering of the web page, period, as well as an inability to use most modern applications.

One of the biggest rendering problems with widgets is the fact that slow widget loading could impact adversely on a web page that's not designed for widget use–or loading images, either. If you're using HTML tables to manage your web page layout, all the content has to load for the table to render. In other words, widget or not, HTML tables for layout: bad.

There are other design issues. Fred, a VC wrote about slow page loading and a person in comments wrote about his design: he has a two column design, with centered content and widgets in both sidebars. Fred doesn't want to give up widgets, he loves his widgets. What's a widgetophile to do?

The same person who wrote the comment about widgets also mentioned how browsers load top to bottom, left to right. It's been a long established policy to make your web pages more accessible to screen readers by putting the changing material first in the page layout, and then the more static elements. In a weblog, this means putting the content first, and then the sidebars. The bars may appear to the left, but in the actual physical layout design, they should physically exist after the content, so that the content is always first.

Ever since reading that, I've designed my weblog pages to maintain this effect, which not only makes my page more accessible, it also makes it more widget friendly. In other words, if the widgets are loaded after the content, people can be reading content while the widgets are loading. This same applies with larger images, and any other bandwidth intensive goodies.

Fred also provides something rather nice: a fast version of his site. This is one without sidebars, content only, and I imagine no bandwidth intensive YouTube or images. A novel idea, but if one provides a full syndication feed, it doesn't add much beyond the feed. But playing on this idea, another area for optimization is to load your front page down with as many widgets as you want, but to provide a stripped down search, archive, category, and single page. That way you get the goodies, but if people are coming to the page to comment, they don't have to struggle through the slow downloads.

In other words, the widget user has some responsibility for how slow the page loads, and good design decisions can help immeasurably. Additionally, just because a widget exists doesn't mean it has to be planted into our sidebars. Think about why you want to use a widget, what it provides to the web page reader, and balance this with the time to download the widget. If it doesn't balance, toss it. However, you also don't have to adopt a zen-like atmosphere consisting only of text, page, and minimal CSS; you just have to use some common sense.

Returning to the comments in the last post, rev_matt wrote:

I tend to agree with jwz about JavaScript in the same vein with the sentiment that teaching CS students VB causes almost irreparable damage. Both VB and JS are very useful tools when used well, but the overwhelming majority of the time they are used poorly.

For every cool and useful AJAXian widget, there are tens of thousands of crappy javascripts clogging the intarweb.

There's a misunderstanding about JavaScript that it's easy. In actuality, JavaScript is hard. It's too forgiving, which means it's more difficult to spot bugs. The environment is fluid, which means you have to make sure the JS works for IE, Opera, Firefox, Safari, not to mention that whatever effect you create has to work well with screen readers if possible–not to mention providing a graceful way to deal with JavaScript being turned off.

Seriously, working with EJBs is a snap, because this environment is incredibly restrictive: either what you code is correct, or it doesn't work. Even then, you can create crappy EJB applications, and I've seen some C++ that will curl your toes.

I worked with the the EJB 1.0 framework about seven years ago, and last year I had an opportunity to work with the newer EJB 3.0 environment, agile programming, Eclipse: the whole ball of wax. I was out of my element and frustratingly lost: not because I'm a 'bad' developer; but because I hadn't worked within this environment previously, but still needed to hit the ground running. I could deliver code, but I never felt comfortable with what I delivered, because I wasn't completely sure it was optimized for the environment: I was never sure with the code others delivered whether parts of it were essential, or the extra sugar roses that agile programming adds to an application. There is code; there is good code; then there is code that is optimized for a framework and a programming philosophy.

Anyone can do 'bad' code, in any language. There is nothing unique to JS or VB that generates 'bad code', other than most of the bad Java and C++ exist in applications we don't see. I bet they manage your bank account and utility bills, as well as most power plants, dams, and the Department of Homeland Security, though, which should cause all of us sleepless nights.

We see more bad JavaScript because it's an outwardly looking language. Yes, it is quicker to get up and running in JavaScript. In Mike Arrington's post about "my site is hammered, who should I blame", there was a junior high schooler talking about the company he and his friends are running, and I'll bet you that Ajax is involved in that company. Boggles the mind that kids are writing code and running companies when they can barely form legible English. But the web encourages this, as does JavaScript. What's nice about the web? It's open, it's easy. What's bad about the web? It's open, it's easy.

I bet you dollars to donuts that if we could see the PHP behind a lot of sites, we'd shudder in our shoes at the crap that runs on our web. However, we don't 'see' the PHP, we do see the JS, so we see more 'bad' JS than PHP.

The thing about widgets, though, is trust. You have to trust the source. This is more than just trusting that the source isn't going to deliberately cause harm; you have to trust that they won't indirectly cause harm.

Would you trust a widget that came from, say, Google? Probably, and people who use Google ads do. But didn't Google have problems with security breaks in cookies and GMail this last year? Would you trust a widget that came from Yahoo? How about flickr? Chances are you would, because you know that, like with Google, if a security breach does occur, the company would be on it immediately.

There is no such thing as perfect code. Our code gets better primarily because we make mistakes and learn from such. A widget that's posted for public consumption, especially one that's published via a weblog entry, typically has comments from other developers highlighting where the widget breaks. This isn't a oneupmanship: this is developers helping developers. This leads to an iterative development cycle:

release code-> get feedback -> fix code -> release code -> get feedback -> release code, and so on.

Either the widget developer gets with this program, in which case you can feel pretty comfortable about the code used in the widget; or they don't, in which case, give the widget a pass.

In his comment, Aristotle Pagaltizis wrote:

"Pushing this stuff on to the server doesn't change the problem: if you have a PHP program that's waiting on ten services, it's not going to be much better than ten different JavaScript clients waiting on ten different sources."

Well yeah, except that you can actually implement caching and conditional GETs and all manner of such on the server side, which is conceptionally impossible if you punt resposibility to the client.

Aristotle also has a good point: there are techniques we can use on the server to increase performance, such as caching of data. But then, let's look at the behavior associated with widgets.

For most widgets, there is an associated 'freshness' component to the object, which presumes that the latest and greatest data is being delivered. For the Flickr badge, it's the latest pictures either in your queue, or the latest of all your friends. For the MyBlogLog thing, it's the latest visitor, in which case when you see it, it would show you. A weather widget shows the current weather; a feed widget shows the most recent update from the aggregated feeds, and so on.

Caching makes little sense with many of these widgets, because the assumption behind them is a) the data being delivered is always changing and b) it only makes sense to deliver a snapshot of the data that exists when the web page with the widget is accessed.

How about instances where caching does make sense, such as ads that don't change frequently?

Contrary to myth, Ajax does incorporate caching, which can actually cause problems if you don't want the browser to cache the request. If you lookup "Ajax" and "cache" in your favorite search engine, you'll see dozens of articles on Ajax and caching, how to prevent, and how to utilize. Here's an interesting page on caching and Ajax requests including an extensive caching test page that sees how your browser does under certain caching conditions. The Ajax Patterns book caching page is also a good read.

If you're delivering a web application that uses Ajax, you might need to consider caching frequently accessed but infrequently updated data for later access across sessions. The use of cookies and even the Flash Shared Object can be used to 'cache' data across sessions. Bruce Perry wrote an article on Ajax caching in this type of situation.

Does any of this make sense, though, when considering widgets? Sometimes, though I would frown on widgets making excessive use of locally stored data. The thing to keep in mind is that widget behavior is biased more towards freshness than efficiency, and it doesn't matter if the functionality is embedded in your page using PHP, or managed client-side with JavaScript: chances are the service request is going to be made based on the page being loaded. To go much beyond this is to go beyond the entire concept of widget, which is a small, lightweight beastie, meant to be easily incorporated into a web page, without the page owner having to know how to code. Cut and paste.

This leads then to the biggest problem with widgets: it's not the client that's the problem, it's the server. I have found that weblogs that utilize the Technorati link count widget to be abysmally slow. Not only is the widget being utilitized with every post, it's to a server that is known to, at times, have scaling and performance problems.

Then there are the widgets that download enormous chunks of data, rendered in intricate styling, using methods such as document.writeln that prevent your page from being served as XHTML and so on–these aren't widgets; these are the spawn of the devil. You don't remove them from your page, your exorcise them.

If a widget makes a request to a server that quickly returns a small amount of data, which is simply rendered and doesn't impact on the page layout or loads, or how the page validates, it is a good widget: use it proudly; use it often. If it somehow also gracefully degrades when scripting is turned off, pet it nicely, give it a warm home, feed it chocolate and call it 'dear', 'honey', and 'my cute wittle squidgy widgey'.

However, if a widget makes a request to a server that takes forever, which returns huge chunks of data, requiring intricate code to render, not to mention screwing up your site's validation or layout, and also does this every ten seconds: run, run like a rabbit from the hungry foxes; fall, fall on your web page, like a comrade in arms falling on the grenade to protect his or her buddies. Think of the widget as the cad, and your page the Pauline in Peril and the train is coming…