Three systems are provided for eager client-side developers:

1. The Google Closure Compiler

“Compiler” is a confusing term — this is a Java-powered JavaScript optimizer that reduces file sizes by removing dead code, renaming variables, and removing whitespace and comments.

You can either:

1. download the Closure Compiler, or
2. use the online Closure Compiler tool.

In my brief tests, a 28Kb JavaScript file was reduced to 15Kb (46% reduction) using “Simple” compression to remove white-space and comments. The reduction factor was almost identical to Yahoo’s YUI Compressor.

“Advanced” compression with variable and function renaming reduced the file size to a little under 10Kb (64% reduction). The code continued to work correctly, although a couple JavaScript warnings were generated about uninitialized variables which were not evident in the uncompressed version.

The Closure Compiler is certainly worth trying if you want to speed up your web page’s download speeds. However, be careful to fully test the resulting JavaScript code.

2. The Google Closure Library

The Closure library is an alternative to jQuery or the YUI Library. The usual features are available, e.g. helper functions, Ajax, DOM manipulation, event handlers, CSS control, animation, effects, etc.

The code, comments, and documentation are generally good, although I could not find information about browser support. Some of the examples are a little basic but I suspect they will be improved over time.

Kevin Yank’s recent article features comments from Dmitry Baranovskiy who has expressed concerns about the quality of the code. They are valid criticisms and I doubt the Closure will win over many jQuery aficionados, but choice is always a good thing and the library is will improve now it’s in the public domain.

3. Google Closure Templates

Closure Templates is a templating system for client-side JavaScript and server-side Java. It’s a system that allows you to add small language-neutral components that create a full user interface.

Documentation is sparse and there are few examples. Server-side Java developers may adopt the system, but I’m not convinced it will appeal to ASP.NET or PHP developers.

Will you try Google’s Closure Tools? Or has the choice of tools become so bewildering you’ll stick with what you know?

See also: Google Closure: How not to write JavaScript

Related posts:

1. Google Closure: How not to write JavaScript What if Google released a JavaScript library that sucked, and...
2. Will Server-Side JavaScript ever catch on? Server-side JavaScript appears to be a logical choice for web...
3. Server-side JavaScript Will Be as Common as PHP Despite the fact that JavaScript has been typecast as the...

Having delivered a talk on how to write your own JavaScript library (detailed notes) at the conference, Dmitry shared his thoughts on the new library over breakfast the next morning. “Just what the world needs—another sucky JavaScript library,” he said. When I asked him what made it ‘sucky’, he elaborated. “It’s a JavaScript library written by Java developers who clearly don’t get JavaScript.”

For the rest of the day, to anyone who would listen, Dmitry cited example after example of the terrible code he had found when he went digging through Closure. His biggest fear, he told me, was that people would switch from truly excellent JavaScript libraries like jQuery to Closure on the strength of the Google name.

“I’ll make you a deal,” I told him. “Send me some examples of this terrible code and I’ll publish it on SitePoint.”

The Slow Loop

From array.js, line 63:

for (var i = fromIndex; i < arr.length; i++) {

This for loop looks up the .length property of the array (arr) each time through the loop. Simply by setting a variable to store this number at the start of the loop, you can make the loop run much faster:

for (var i = fromIndex, ii = arr.length; i < ii; i++) {

Google’s developers seem to have figured this trick out later on in the same file. From array.js, line 153:

var l = arr.length;  // must be fixed during loop... see docs
⋮
for (var i = l - 1; i >= 0; --i) {

This loop is better in that it avoids a property lookup each time through the loop, but this particular for loop is so simple that it could be further simplified into a while loop, which will run much faster again:

var i = arr.length;
⋮
while (i--) {

But not all of Closure Library’s performance woes are due to poorly optimized loops. From dom.js, line 797:

switch (node.tagName) {
  case goog.dom.TagName.APPLET:
  case goog.dom.TagName.AREA:
  case goog.dom.TagName.BR:
  case goog.dom.TagName.COL:
  case goog.dom.TagName.FRAME:
  case goog.dom.TagName.HR:
  case goog.dom.TagName.IMG:
  case goog.dom.TagName.INPUT:
  case goog.dom.TagName.IFRAME:
  case goog.dom.TagName.ISINDEX:
  case goog.dom.TagName.LINK:
  case goog.dom.TagName.NOFRAMES:
  case goog.dom.TagName.NOSCRIPT:
  case goog.dom.TagName.META:
  case goog.dom.TagName.OBJECT:
  case goog.dom.TagName.PARAM:
  case goog.dom.TagName.SCRIPT:
  case goog.dom.TagName.STYLE:
    return false;
}
return true;

This kind of code is actually pretty common in Java, and will perform just fine there. In JavaScript, however, this switch statement will perform like a dog each and every time a developer checks if a particular HTML element is allowed to have children.

Experienced JavaScript developers know that it’s much quicker to create an object to encapsulate this logic:

var takesChildren = {}
takesChildren[goog.dom.TagName.APPLET] = 1;
takesChildren[goog.dom.TagName.AREA] = 1;
⋮

With that object set up, the function to check if a tag accepts children can run much quicker:

return !takesChildren[node.tagName];

This code can be further bulletproofed against outside interference using hasOwnProperty (see below for a full explanation of this).

return !takesChildren.hasOwnProperty(node.tagName);

If there’s one thing we expect from Google it’s a focus on performance. Heck, Google released its own browser, Google Chrome, primarily to take JavaScript performance to the next level!

Seeing code like this, one has to wonder if Google could have achieved the same thing by teaching its engineers to write better JavaScript code.

Six Months in a Leaky Boat

It would be unfair to suggest that Google has ignored performance in building Closure. In fact, the library provides a generic method for caching the results of functions that run slowly, but which will always return the same result for a given set of arguments. From memoize.js, line 39:

goog.memoize = function(f, opt_serializer) {
  var functionHash = goog.getHashCode(f);
  var serializer = opt_serializer || goog.memoize.simpleSerializer;
  
  return function() {
    // Maps the serialized list of args to the corresponding return value.
    var cache = this[goog.memoize.CACHE_PROPERTY_];
    if (!cache) {
      cache = this[goog.memoize.CACHE_PROPERTY_] = {};
    }
    var key = serializer(functionHash, arguments);
    if (!(key in cache)) {
      cache[key] = f.apply(this, arguments);
    }
    return cache[key];
  };
};

This is a clever performance trick employed in a number of major JavaScript libraries; the problem is, Google has not provided any means of limiting the size of the cache! This is fine if a cached function is only ever called with a small collection of different arguments, but this is a dangerous assumption to make in general.

Used to cache a function’s results based on, say, the coordinates of the mouse pointer, this code’s memory footprint will rapidly grow out of control, and slow the browser to a crawl.

In Dmitry’s words, “I’m not sure what this pattern is called in Java, but in JavaScript it’s called a ‘memory leak’.”

Code in a Vacuum

In his talk on building JavaScript libraries, Dmitry compared JavaScript’s global scope to a public toilet. “You can’t avoid going in there,” he said. “But try to limit your contact with surfaces when you do.”

For a general-purpose JavaScript library to be reliable, it must not only avoid interfering with any other JavaScript code that might be running alongside it, but it must also protect itself from other scripts that aren’t so polite.

From object.js, line 31:

goog.object.forEach = function(obj, f, opt_obj) {
  for (var key in obj) {
    f.call(opt_obj, obj[key], key, obj);
  }
};

for-in loops like this one are inherently dangerous in JavaScript libraries, because you never know what other JavaScript code might be running in the page, and what it might have added to JavaScript’s standard Object.prototype.

Object.prototype is the JavaScript object that contains the properties shared by all JavaScript objects. Add a new function to Object.prototype, and every JavaScript object running in the page will have that function added to it—even if it was created beforehand! Early JavaScript libraries like Prototype made a big deal of adding all sorts of convenience features to Object.prototype.

Unfortunately, unlike the built-in properties supplied by Object.prototype, custom properties added to Object.prototype will show up as an object property in any for-in loop in the page.

In short, Closure Library cannot coexist with any JavaScript code that adds features to Object.prototype.

Google could have made its code more robust by using hasOwnProperty to check each item in the for-in loop to be sure it belongs to the object itself:

goog.object.forEach = function(obj, f, opt_obj) {
  for (var key in obj) {
    if (obj.hasOwnProperty(key)) {
      f.call(opt_obj, obj[key], key, obj);
    }
  }
};

Here’s another especially fragile bit of Closure Library. From base.js, line 677:

goog.isDef = function(val) {
 return val !== undefined;
};

This function checks if a particular variable has a value defined. Or it does, unless a 3rd party script sets the global undefined variable to something else. This single line of code anywhere in the page will bring Closure Library crashing down:

var undefined = 5;

Relying on the global undefined variable is another rookie mistake for JavaScript library authors.

You might think that anyone who assigns a value to undefined deserves what they get, but the fix in this case is trivial: simply declare a local undefined variable for use within the function!

goog.isDef = function(val) {
  var undefined;
  return val !== undefined;
};

Typical Confusion

One of the most confusing aspects of JavaScript for developers coming from other languages is its system of data types. Closure Library contains plenty of bloopers that further reveal that its authors lack extensive experience with the finer points of JavaScript.

From string.js, line 97:

// We cast to String in case an argument is a Function. …
var replacement = String(arguments[i]).replace(…);

This code converts arguments[i] to a string object using the String conversion function. This is possibly the slowest way to perform such a conversion, although it would be the most obvious to many developers coming from other languages.

Much quicker is to add an empty string ("") to the value you wish to convert:

var replacement = (arguments[i] + "").replace(…);

Here’s some more string-related type confusion. From base.js, line 742:

goog.isString = function(val) {
  return typeof val == 'string';
};

JavaScript actually represents text strings in two different ways—as primitive string values, and as string objects:

var a = "I am a string!";
alert(typeof a); // Will output "string"
var b = new String("I am also a string!");
alert(typeof b); // Will output "object"

Most of the time strings are efficiently represented as primitive values (a above), but to call any of the built-in methods on a string (e.g. toLowerCase) it must first be converted to a string object (b above). JavaScript converts strings back and forth between these two representations automatically as needed. This feature is called “autoboxing”, and appears in many other languages.

Unfortunately for Google’s Java-savvy developers, Java only ever represents strings as objects. That’s my best guess for why Closure Library overlooks the second type of string in JavaScript:

var b = new String("I am also a string!");
alert(goog.isString(b)); // Will output FALSE

Here’s another example of Java-inspired type confusion. From color.js, line 633:

return [
  Math.round(factor * rgb1[0] + (1.0 - factor) * rgb2[0]),
  Math.round(factor * rgb1[1] + (1.0 - factor) * rgb2[1]),
  Math.round(factor * rgb1[2] + (1.0 - factor) * rgb2[2])
];

Those 1.0s are telling. Languages like Java represent integers (1) differently from floating point numbers (1.0). In JavaScript, however, numbers are numbers. (1 - factor) would have worked just as well.

Yet another example of JavaScript code with a whiff of Java about it can be seen in fx.js, line 465:

goog.fx.Animation.prototype.updateCoords_ = function(t) {
  this.coords = new Array(this.startPoint.length);
  for (var i = 0; i < this.startPoint.length; i++) {
    this.coords[i] = (this.endPoint[i] - this.startPoint[i]) * t +
        this.startPoint[i];
  }
};

See how they create an array on the second line?

this.coords = new Array(this.startPoint.length);

Although it is necessary in Java, it is entirely pointless to specify the length of an array ahead of time in JavaScript. It would make just as much sense to create a new variable for storing numbers with var i = new Number(0); instead of var i = 0;.

Rather, you can just set up an empty array and allow it to grow as you fill it in. Not only is the code shorter, but it runs faster too:

this.coords = [];

Oh, and did you spot yet another inefficient for loop in that function?

API Design

If all the low-level code quality nitpicks above don’t convince you, I defy you to try using some of the APIs Google has built into Closure Library.

Closure’s graphics classes, for example, are modeled around the HTML5 canvas API, which is about what you’d expect from a JavaScript API designed by an HTML standards body. In short, it’s repetitive, inefficient, and downright unpleasant to code against.

As the author of Raphaël and gRaphaël, Dmitry has plenty of experience designing usable JavaScript APIs. If you want to grasp the full horror of the canvas API (and by extension, Closure’s graphics API), check out the audio and slides from Dmitry’s Web Directions South 2009 talk on the subject.

Google’s Responsibility to Code Quality

By this point I hope you’re convinced that Closure Library is not a shining example of the best JavaScript code the Web has to offer. If you’re looking for that, might I recommend more established players like jQuery?

But you might be thinking “So what? Google can release crappy code if it wants to—nobody’s forcing you to use it.” And if this were a personal project released by some googler on the side under his or her own name, I’d agree with you, but Google has endorsed Closure Library by stamping it with the Google brand.

The truth is, developers will switch to Closure because it bears the Google name, and that’s the real tragedy here. Like it or not, Google is a trusted name in the development community, and it has a responsibility to that community to do a little homework before deciding a library like Closure deserves public exposure.

Related posts:

1. Google Releases its JavaScript Closure Tools Do we need more JavaScript libraries and tools? Perhaps not,...
2. Fixing Object Instances in JavaScript Even experienced coders can get caught out by object handling...
3. How to Write a Cookie-less Session Library for JavaScript Craig provides the code for a stand-alone JavaScript session variable...

Of course, even the most dedicated SitePoint fan could find it hard to justify a trip to Australia to see me speak; thankfully, the folks at Web Directions were kind enough to share the audio recorded at the event under a Creative Commons license that enables me to share it with you in a richer format.

I am delighted, therefore, to present this video re-creation of the talk including my animated slides, a screencast video demo, and the audio recorded live at Web Directions South 2009. Be sure to visit the Web Directions site for the accumulated audio and slides from the entire conference series!

CSS Frameworks: Make the Right Choice (WDS09) from SitePoint Staff on Vimeo.

SitePoint CTO Kevin Yank presented this talk at Web Directions South 2009 in Sydney, Australia on Friday, October 9th, 2009.

With the proliferation and widespread adoption of JavaScript frameworks, smart developers have wondered if a similar approach to smoothing over the rough spots of CSS might work. Thus, CSS frameworks like Blueprint, YUI Library CSS Tools, Boilerplate, and many others were born. In this session, we will survey the landscape of CSS frameworks and consider how each of them deals with the unique challenge of creating generalised, reusable CSS styles.

There are a number of different approaches, and some are better than others. Choose the right framework and you’ll save yourself a lot of work. Choose the wrong one, and you’ll find your projects weighed down by restrictive assumptions and masses of code that you don’t understand. When it comes to CSS frameworks, making the right choice is everything. By the end of this session, you might just decide that the right framework for you is no framework at all.

Related posts:

1. What’s So Bad About CSS Frameworks? Standards-aware web developers often feel conflicted about using CSS frameworks....
2. CSS Frameworks and Semantic Class Names CSS frameworks often contain crufty, non-semantic code. Does it have...
3. Win Signed SitePoint Books at Web Directions South If you're at the Web Directions South conference in Sydney...

// object constructor
function ObjectConstructor(a, b, c) {

	this.A = a;
	this.B = b;
	this.C = c;
	this.Total = a + b + c;

}

var obj = ObjectConstructor(1, 2, 3);

alert(obj.Total);

Hands up everyone who answered “6.”

Sorry, you’re wrong. The answer is … nothing — or an error stating that ‘obj’ is undefined. So what’s gone wrong?

The simple answer is that we’ve forgotten the ‘new’ operator so an object instance is never created. The statement should be:

var obj = new ObjectConstructor(1, 2, 3);

It’s an easy mistake to make. Novice developers are unlikely to spot the missing operator because the code looks almost identical. Even experienced coders could find it tough to debug (especially since many assume JavaScript is a procedural programming language … which it can be, if you choose to write it that way).

The main problem is that var obj = ObjectConstructor(1, 2, 3); is a perfectly valid JavaScript statement and the interpretor engine will not throw an error. In that context, the value of obj is set to the value returned from the function ObjectConstructor; since no value is returned, obj remains “undefined” (a top-level JavaScript property).

This is unlikely to become a major problem if you’re developing, testing and debugging your own code. However, it could be a different matter when you’re providing a library or API to thousands of third-party developers. At some point, someone, somewhere, will miss that ‘new’ operator and they will blame your code rather than theirs.

Fortunately, JavaScript is a flexible language. We can fix our constructor so an object is correctly created even when the ‘new’ operator is omitted:

// object constructor
function ObjectConstructor(a, b, c) {

	if (!(this instanceof arguments.callee)) {
		return new ObjectConstructor(a, b, c);
	}

	this.A = a;
	this.B = b;
	this.C = c;
	this.Total = a + b + c;

}

The additional ‘if’ statement at the top of the constructor checks whether ‘this’ is an instance of the object and returns one if necessary. The code var obj = ObjectConstructor(1, 2, 3); will now set obj to an object instance and “6″ will be output by the alert statement.

Have you ever encountered this problem in your code or when using another library?

Related posts:

1. Cross-browser JSON Serialization in JavaScript JSON serialization can be incredibly useful, but few browsers support...
2. Truthy and Falsy: When All is Not Equal in JavaScript Anything in JavaScript can be considered to be either truthy...
3. Google Closure: How not to write JavaScript What if Google released a JavaScript library that sucked, and...

One of the most common complaints about CSS frameworks like Blueprint, YUI Grids, and 960.gs is that they require designers to dirty their fingers by adding presentational class names to their HTML documents, like so:

<div class="span-9 last">
<div class="grid_6 alpha">

Class names like "span-9" really bother designers who care about the quality of their HTML code, because they describe the appearance of an element; this should really be left to the CSS properties defined in your site’s style sheets. The problem with presentational class names is explained especially well by the W3C QA tip, Use class with semantics in mind:

Good names don’t change. Think about why you want something to look a certain way, and not really about how it should look. Looks can always change, but the reasons for giving something a look stay the same.

Maybe you’re the pragmatic type who takes no issue with this sort of thing, or decides that it’s a necessary evil given the limitations of the CSS language. Nevertheless, there are plenty of front-end ninjas out there who refuse to use CSS frameworks for this very reason.

It turns out, however, that the latest crop of CSS frameworks provide clever solutions to the problem of presentational class names.

Blueprint CSS, the granddaddy of CSS layout frameworks, now includes a clever Ruby script called compress.rb in its download package. In Blueprint’s compress.rb: A Walkthrough, Blueprint author Joshua Clayton explains how to use the script to generate a custom version of the Blueprint style sheets using your own semantic class names.

The process boils down to writing a simple configuration file that tells the script how to map Blueprint’s presentational class names to your own semantically meaningful class names. The file will look like this:

demo:
  path: /Users/kyank/Documents/myproject
  semantic_classes:
    ".header, .footer": ".span-24, div.span-24"
    ".content": ".span-18, div.span-18"
    ".sidebar": ".span-6, div.span-6,
                 .last, div.last"

The semantic_classes section provides the mapping. In this example, the header and footer classes will be 24 grid units wide and the content class will be 18 grid units wide. The sidebar class will be 6 grid units wide and the last block in its row.

With this configuration file written, you simply run the compress.rb script, and the customized version of the Blueprint style sheet files (screen.css, print.css, and ie.css) will be generated in the specified path. The style sheet will contain rules like this one, that apply the grid dimensions to your custom class names:

/* semantic class names */
.content {float:left;margin-right:10px;
  width:710px;}

… and just like that, you gain all the layout facilities of Blueprint CSS with none of the HTML cruft!

If manually compiling your style sheets with a Ruby script sounds like a bit of a pain (which it can be — especially if you develop on a Windows computer without Ruby installed), a server-side CSS framework might be a better option for you.

CSS frameworks are popping up for all the major server-side programming languages. Two prominent examples include Compass (for Ruby), and Scaffold (for PHP). These frameworks let you write your style sheets with extra language features, and automatically compile them to standard CSS code when sending them to the browser.

Using Scaffold, for example, you could write your style sheet like this:

@grid {
  column-width:30;
  column-count:24;
  right-gutter-width:20;
  baseline:20;
  unit:px;
}
.header, .footer {
  +columns(24);
}
.content {
  +columns(18);
}
.sidebar {
  +columns(6);
  +last;
}

The @grid at-rule sets up the options for Scaffold’s layout plugin, and then lines like +columns(24); (called mixins) are compiled into standard CSS properties when the browser requests the style sheet.

These are just a couple of the ways that the latest CSS frameworks respond to those critics who complain about having to sacrifice HTML code quality to use them. Now you can have all the benefits of a well-tested layout framework, and apply them to your HTML code on your terms.

(photo: Nbauer)

Related posts:

1. What’s So Bad About CSS Frameworks? Standards-aware web developers often feel conflicted about using CSS frameworks....
2. Video: CSS Frameworks – Make the Right Choice Choose the right framework and you’ll save yourself a lot...
3. Add Semantic Richness To Your Markup With (RDF) Ease Meitar takes another look at bleeding edge Semantic Web technologies...

The WSG mailing list gets a lot of CSS layout questions sent to it and last week I noticed this query. Tee wanted to visually reproduce the table layout shown below without adding extra wrapping DIVs or other non-semantic markup.

It’s not quite as simple as it looks.

Anyway, playing around my approach, I came across a CSS property I’ve rarely seen in use: border-spacing.

Now if you’re not super familiar with border-spacing, it’s essentially a better version of the old ‘cellspacing’ table attribute (i.e. <table cellspacing="3px" ..) , and controls the space *between* your table cells. Of course, if you set the table’s border to collapse (i.e. border-collapse:collapse;) there *is* no space between your table cells, so setting border-spacing becomes redundant.

The key advantage that CSS’s border-spacing has over HTML’s cellspacing (besides cleaner markup) is it allows you to set different horizontal and vertical spacing widths — seemingly perfect for creating the 5 pixel row separations required in the example. Cellspacing only accepts a single value.

Guessing the CSS, I didn’t get the result I expected when I tried (try for yourself):

table#grid {
	border-collapse:separate;
	border-spacing:  5px 0px ;
}

Counter-intuitively to the way margin, padding, border and every other CSS property I can think of operates, border-spacing asks for it’s horizontal value before it’s vertical value. Strange.

Other points to note with border-spacing:

• You aren’t able to assign different top, bottom, right and left values. This makes sense if you think about it, as we’re actually talking about an attribute of the TABLE, but I think it’s easy to trick yourself into thinking it’s part of the TD — it wraps around the TD borders after all.
• Support is perfect in all modern browsers, but old IE6 & 7 don’t support this property at all.

Related posts:

1. 5 Rarely-Used CSS Properties It is easy to forget CSS that you don't use...
2. How to Use Operating System Styles in CSS CSS can reference fonts and colors defined for the underlying...
3. Techy Treasures #5: Fudging CSS Counters in Internet Explorer CSS Counters are a useful but under-used feature of CSS2...

Visit the JSNES page…

The emulator is port of the Java-based vNES project. It uses the HTML canvas element for screen rendering (sorry Internet Explorer users) although sound is not supported yet.

There are 17 working games to try. Most will run in Firefox 3.5 or Safari 4, but neither browser offers a playable gaming experience. You’ll be lucky to achieve 10 frames per second on the highest-specification liquid-nitrogen-cooled ninja PC.

The real revelation, however, is Google Chrome — it runs the emulator at full speed (50-60 fps) on a modest PC. Google’s canvas performance optimization appears to be out-pacing the competition by a considerable margin. Both Mozilla and WebKit have raised bugs to investigate why there is such a noticeable speed difference.

Although JSNES is little more than an interesting experiment, it illustrates what can be achieved with modern JavaScript engines, some ingenuity, and lots of caffeine. Ben Firshman — you are a genius. My only question is … why?!!

See also: SitePoint’s Exclusive Interview With Ben Firshman, Creator of JSNES

Related posts:

1. Exclusive Interview With Ben Firshman, Creator of JSNES Craig interviews Ben Firshman, developer of the JavaScript-based NES emulator...
2. Opera Fights Back: Announces Next Gen JavaScript Engine At one time, Opera had the fastest ECMAScript / JavaScript...
3. Google Chrome Frame: the Technical Details Google's Chrome Frame announcement has been surrounded by hype, fabrication,...

And I don’t mean developers, I mean real people — actual users, who are browsing the Web with assistive devices and making use of ARIA enabled applications?

See, when I first researched the question of accessible Ajax for The JavaScript Anthology, back in 2006, there was no such thing as ARIA; there was only the early draft ideas that would eventually become it, based largely on work done at IBM.

And I was unimpressed. Not because of any specific details, but over the entire concept behind it — the idea that all RIAs needed to make them usable for screenreaders is more information seemed naïve.

And now that we have a formal specification, with browsers and screenreaders that have working implementations, I ask the same question — are RIAs really appropriate to assistive devices if only they had that role and state information, or are we trying to force a square peg into a round hole? Are we just adding layers of information on top of a paradigm that is fundamentally incompatible with the target devices?

What my question really comes down to is, can any Ajax-based application which requires an API to give the consuming device enough information to make sense of it, possibly be better than what we had before — where you submit a form and you get a new page in response — something that generations of devices were well able to comprehend.

I’m not trying to dredge up my stop using Ajax argument again — not at all, I accept that Ajax is here to stay, and welcome it as a valuable addition to the programmer’s toolkit. But the hype has yet to calm down, and Ajax is still over-used. The question of to what extent Ajax applications are expected to progressively enhance from static applications is still very much an issue, as the bulk of the comments in one of Craig’s recent posts highlighted all too sharply.

So where are the ARIA users? And what do they think?

It’s an honest question, because I really don’t know. Is there any information? Have any studies been carried out, that convincingly answer the question of whether ARIA enabled applications are a better user experience for people using assistive technologies, compared with conventional post-and-response style applications, that RIAs should otherwise be expected to degrade to?

Is ARIA really the way forward, or is it just a solution looking for a problem?

Related posts:

1. Free Book Giveaway: The Adobe Flash Platform Reference for RIAs Do you develop Rich Internet Applications (RIAs)? Or want to?...
2. Progressive Enhancement and Graceful Degradation: an Overview It is possible to create a fantastic-looking Ajax-powered Internet application...

View the JavaScript session library demonstration page…

The code provides three main methods:

• Session.set(name, object) — store a named session value/object
• Session.get(name) — retrieve a named session value/object
• Session.clear() — reset all the session data

Another Session.dump() method returns all the JSON-encoded session data. This would normally be used for debugging purposes only.

The JavaScript code is loaded just before the closing body tag. First, we load the JSON library:

<script type="text/javascript" src="json-serialization.js"></script>

The JSON library provides cross-browser serialization methods that are required by our Session library. For more information, refer to Cross-browser JSON Serialization in JavaScript.

The session.js file is loaded next. This is stand-alone code that can be implemented in any system — it does not depend on jQuery or any other JavaScript library. Working through the code:

 if (JSON && JSON.stringify && JSON.parse) var Session = Session || (function() {

	// window object
	var win = window.top || window;

	// session store
	var store = (win.name ? JSON.parse(win.name) : {});

The first line defines our Session module. However, it will only be defined if the JSON library has been loaded and there are no other conflicting Session variables or functions.

The second line sets win to ‘window.top’. It is set to ‘window’ if that is not available (perhaps if the browser does not support frames).

Next, we define a ’store’ object to hold all our session data. Exisiting JSON-encoded data in the window.name property is parsed but, if that is not available, ’store’ is set to an empty object.

	// save store on page unload
	function Save() {
		win.name = JSON.stringify(store);
	};

	// page unload event
	if (window.addEventListener) window.addEventListener("unload", Save, false);
	else if (window.attachEvent) window.attachEvent("onunload", Save);
	else window.onunload = Save;

The private Save() function assigns the serialized the ’store’ object string to the window .name property. The following three lines define a cross-browser event which calls the Save function when the page is unloaded. Your pages can therefore modify the ’store’ as much as necessary, but the heavy work of serializing and saving only occurs at the last possible moment.

	// public methods
	return {

		// set a session variable
		set: function(name, value) {
			store[name] = value;
		},

		// get a session value
		get: function(name) {
			return (store[name] ? store[name] : undefined);
		},

		// clear session
		clear: function() { store = {}; },

		// dump session data
		dump: function() { return JSON.stringify(store); }

	};

 })();

Finally, we have our four public set, get, clear and dump functions which handle the store object accordingly. The Session.get() method will return a JavaScript ‘undefined’ value if a session name can not be found.

I hope you find the code useful. Feel free to use it in your own projects.

Useful resources:

• JavaScript session variables demonstration page
• Full JavaScript session.js code
• Download full code in a ZIP file

See also:

• Cookie-less Session Variables in JavaScript
• Cross-browser JSON Serialization in JavaScript
• How To Develop a jQuery Plugin
• How to Build an Auto-Expanding Textarea jQuery Plugin

Related posts:

1. Cookie-less Session Variables in JavaScript Cookies may be delicious, but they can be clumsy if...
2. Cross-browser JSON Serialization in JavaScript JSON serialization can be incredibly useful, but few browsers support...
3. Google Closure: How not to write JavaScript What if Google released a JavaScript library that sucked, and...

Fortunately, there is a solution that allows you to store JavaScript data within the browser. The data is retained between page loads, it’ll survive page back/next events (even away from the domain), it does not require plugins or off-line storage facilities, it’ll hold at several megabytes of information, it is never transmitted to the server, and works in every browser. Bizarrely, it works by exploiting the window.name property (or window.top.name if you’re using multiple frames).

It’s rare for developers set the window.name property. Generally, it’s only required when you’re manipulating frames or pop-up windows. Even though I’d hope you weren’t doing that, you do not normally need to define a name for an application’s starting window. Although the name property is still a string, it can hold several megabytes of data. Some versions of Opera limit it to around 2Mb but most browsers offer 10MB or more.

It’s easy to try for yourself. Insert the following JavaScript code into a page on your site:

window.name = "This message will survive between page loads.";

Now add the following code to any other page:

alert(window.name);

Navigate from the first page to the second and you’ll find that the message data is retained.

As normal, there are a number of caveats:

1. The window.name property can be analysed and changed if you navigate to page on another website. That’s easily thwarted by not providing external links within your application’s main window. However, to be on the safe side, don’t use window.name for storing secure data (unlikely to be a major problem for a client-side-only temporary data store).
2. window.name can only store strings. What if we need to save other data types or even complex objects? Serialization is the answer and, fortunately, we have already developed cross-browser code to generate JSON strings from any JavaScript object.

See also: How to Write a Cookie-less Session Library for JavaScript.

Related posts:

1. How to Write a Cookie-less Session Library for JavaScript Craig provides the code for a stand-alone JavaScript session variable...
2. Server-side JavaScript Will Be as Common as PHP Despite the fact that JavaScript has been typecast as the...
3. Cross-browser JSON Serialization in JavaScript JSON serialization can be incredibly useful, but few browsers support...