If, like me, you were expecting to download a fully bootable ISO, you’re going to be disappointed. The launch consists of:

1. A name change from “Chrome OS” to “Chromium OS”.
2. A new Chromium.org website containing information for UI designers and developers.
3. An early version of the source code.

Google has stated that the OS is a full 12-months away from release. The source code is not a beta or even a pre-alpha. It’s possible to create a build but few people will bother: you need Linux, various developer packages, and a lot of patience.

Screenshots and videos are available, but they’re mostly conceptual line drawings rather than actual footage of real-world use. This video is one of the more informative:

So have we discovered anything that we didn’t know before?

• It’s a pure browser-based OS. It’s essentially the Google Chrome browser with additional pop-up management. Even simple applications such as the calculator appear to be web-based rather than an OS executable.
• The left-most tab shows the Chrome menu which links to standard applications like GMail or panels.
• Small panels can be opened which overlay the main window or can be docked at the side of the screen.

The OS is mostly what I expected, but I’d really hoped to be booting a virtual machine today. It’s great that Google has released the code and is asking for developer contributions, but whipping up frenzied media excitement wasn’t the best move. I can’t help feeling a little underwhelmed.

Have you built or tried Chromium OS?

Related posts:

1. Google Chrome Leaves Beta Just 100 days after launching their Chrome browser, Google has...
2. Chrome Extensions Likely by May The number one most requested feature for Google's Chrome web...
3. Why Google Should Not Give Chrome the Go-Ahead Google has ambitious plans for Go and are considering implementation...

Windows 7 Home Basic and Premium users are unable to use XP Mode. This is unfortunate since the vast majority of new PCs have those editions installed. However, there is a workaround that allows Windows 7 Home developers to use XP Mode integration.

1. Check your PC’s compatibility

XP Mode requires hardware-assisted virtualization (HAV). This is supported by most modern processors, but it may need to be enabled in your BIOS. The BIOS menu is normally accessed by pressing DEL, F2, or ESC immediately after switching on your PC. Microsoft provide a useful HAV detection tool which can help you with BIOS configuration.

2. Download Virtual PC

You must download Virtual PC for Windows 7 from the following location rather than the Microsoft Virtual PC website:

http://www.microsoft.com/downloads/details.aspx?FamilyID=2b6d5c18-1441-47ea-8309-2545b08e11dd

You might be prompted to install Genuine Windows Validation Component in your browser if you’ve not installed it before.

3. Create a new Virtual Machine

Start Virtual PC from Start > Programs > Windows Virtual PC > Virtual Machines then click Create virtual machine on the toolbar.

You will be prompted to enter the name, location, RAM (256MB is enough) and create a new virtual hard disk.

4. Install Windows XP in the VM

You will now need to start your VM and install Windows XP using an original CD or disk image. You will also require an XP licence — you may have one if you’ve scrapped or upgraded a PC.

Alternatively, you’ll need to buy a copy of Windows XP. The OEM versions generally cost less and you might be able to grab a copy on eBay — but ensure it’s legitimate.

You will also need to install the latest updates including SP3. However, do not install IE7 or IE8 just yet!

5. Enable integration

From the VM Tools menu, choose to install the Integration Components. Once installed, click Tools > Enable Integration.

6. Install the Windows XP SP3 RemoteApp upgrade

Within your XP VM guest (NOT the Windows 7 host), you should download and install the RemoteApp upgrade from:

http://www.microsoft.com/downloads/details.aspx?FamilyID=2f376f53-83cf-4e5b-9515-2cb70662a81b

7. Configure the VM resolution and color depth (optional)

By default, IE6 and IE7 will run in 16-bit color mode and your subtly-shaded web application can look a little strange. To fix it, refer to step 3 of Running XP Mode for the First Time at the bottom of the original XP Mode article.

8. Create IE6 and IE7 VMs and desktop shortcuts

You can now follow the instructions on page 2 of the original XP Mode article to create two cloned VMs and Windows 7 desktop shortcuts for IE6 and IE7.

click to enlarge

Many thanks to logic_earth on the SitePoint forums for providing a great solution for Windows 7 Home users.

Are You Considering a Windows 7 Upgrade?

The solution above is ideal if you’re already using Windows 7 Home and have a spare XP licence. However, if you’re considering a Windows 7 upgrade, purchasing the Professional edition may save you time and money.

Prices appear to have reduced a little in the US:

• US Microsoft Windows 7 Professional Upgrade — $175
• US Microsoft Windows 7 Professional (full version) — $265
• US Microsoft Windows 7 Ultimate Upgrade — $200
• US Microsoft Windows 7 Ultimate (full version) — $292

UK prices have not altered significantly, but the full version price is confusingly similar to the upgrade and less expensive than the US:

• UK Microsoft Windows 7 Professional Upgrade — £150
• UK Microsoft Windows 7 Professional (full version) — £150
• UK Microsoft Windows 7 Ultimate Upgrade — £167
• UK Microsoft Windows 7 Ultimate (full version) — £170

Has Windows 7 XP Mode reduced your IE testing time?

Related posts:

1. Why Windows 7 Will Revolutionize Your Browser Testing Finally, we can run IE6, IE7, IE8 and any other...
2. Windows 7 Pre-Orders Sell Out on Day 1 Pre-orders for Microsoft Windows 7 have sold out on day...
3. IE8 Automatic Update Starting Soon Internet Explorer 8.0 will shortly be rolled out to IE6...

Data Visualization with Flex, Part I is the first in a three part series in which Toby Tremayne will show us how to use Adobe’s Flex Builder to develop sophisticated data visualizations. In Part I, he focuses on extracting a useful subset of data from a huge dataset, and importing it into Flex in a format we can use.

Here’s the cool part: the dataset he’s using is a collection of posts from our very own SitePoint forums! By the time Part III rolls around, we’ll have the tool running live so you can take a look at how different technologies are discussed in the forums. And if you haven’t been to the forums before, this is the perfect opportunity to drop by and introduce yourself!

We’d like to thank Adobe, who are our sponsors for the multiple choice article quiz—if you find the article interesting, be sure to check how closely you paid attention!

Article: Flex Data Visualization Part I
Quiz: Flex Data Visualization Part I Quiz

Related posts:

1. Find Out What’s New and Cool in Flex 4… and Win! Read our brand new article, What’s New in Flex 4?...
2. Announcing The Winners of our Flash Builder Giveaway When we published "What's New and Cool in Flex 4?"...
3. It’s Quiz Time Again, With a Brand New Prize! It’s quiz time again and this around we’ve got a...

I recently looked at Google’s Go programming language. At first glance, it seems to be a good option for desktop or server-side web development, but it appears that Google has more ambitious plans.

According to source code comments and interviews with the development team, Go may be integrated within the Google Native Client (NaCl). NaCl is an open-source plugin which allows native 32-bit x86 code to run directly within a web browser. The code is sandboxed, verified, and restricted to ensure it cannot cause any damage to the browser, other applications, or the underlying OS. Although NaCl is experimental, it is already included (but disabled) in the Chrome web browser and Quake has been converted to demonstrate the technology.

Potentially, Go could be a good fit for NaCl. Developers could deploy compiled executables, or even the raw source code, which would run quickly within the browser. Complex games and processor-intensive applications would be possible.

Do We Need More Plugins?

How many plugins do you have installed? Most people will have Flash, Java, Adobe Reader, and perhaps Silverlight or Google Gears. Novice users who click “Yes” to every prompt probably have dozens.

The web’s main attractions are platform independence and instant deployment. Yet the industry’s obsession with moving every desktop application online is provoking plugin development which negates the advantages:

1. Relying on a plugin violates platform independence. Creating a Go-based client-side application will almost certainly tie you to Google Chrome since NaCl will never be available for all OS and browser combinations. Many web applications still rely on IE because ActiveX was used — even though Chrome and Firefox have ActiveX implementations.
2. NaCl and Go will offer raw speed so games, graphic, and video applications are logical choices. However, complex applications can be hundreds of megabytes in size — instant deployment is unlikely. While I accept NaCl is very clever, processor-intensive applications will certainly run better outside the browser.

Mozilla expressed similar concerns in their recent criticism of Google Chrome Frame. Although Chrome Frame is a niche solution to a known problem, Mozilla is worried that the web could become fragmented if companies eschew web standards in favor of plugin-based solutions.

I’m not saying all plugins are necessarily bad and, in some cases, they provide facilities that will eventually become a browser standard. For example, Flash allows us to view a video today rather than wait a few years for HTML5’s video tag. However, the web and the desktop are different platforms with their own strengths and weaknesses. Although the boundaries are increasingly blurred, is it sensible to use plugins to shoehorn a desktop application into the browser?

If you find yourself becoming increasingly reliant on plugins, perhaps you should consider a redesign so your application exploits web technology. Alternatively, release a desktop application that utilizes web connectivity when necessary.

Google — have fun with NaCl, but please don’t turn the web into a distribution platform for Go-based binary applications!

What do you think? Is NaCl and Go a great idea? Do we have too many plugins or do they improve the browser experience? Should web browsers be used as an application platform if they continually need bespoke improvement?

Related posts:

1. Google Chrome Frame: the Technical Details Google's Chrome Frame announcement has been surrounded by hype, fabrication,...
2. Mozilla Joins Microsoft in Slamming Google Chrome Frame Mozilla has criticized Google's Chrome Frame plugin for fragmenting the...
3. Microsoft Slams Google Chrome Frame It's hardly surprising, but Microsoft is advising IE users not...

Today, developers are spoiled for choice with PHP, Java, C#, VB, Ruby, Python and a multitude of other platforms and languages. Evidently, Google did not consider that to be enough and have created their own new programming language named ‘Go’.

Go started as one of Google’s 20% projects. Google developers are permitted to spend one day per week on a project of their choice — that idea has led to GMail, AdSense and other successful systems. The Go team’s objective was to build a fast, fun and productive development language. It had to offer the performance and security of compiled programs with the ease and speed of interpreted language development.

Syntactically, the language is reminiscent of Object Orientated C. Here’s the usual “Hello, world” example:

package main
import fmt "fmt" // package implementing formatted I/O.

func main() {
	fmt.Printf("Hello, world\n");
} 

Go offers functions, loops, conditional expressions, pointers (without arithmetic) and all the other structures you would expect. There are a few interesting features:

• End-of-line semi-colons are optional.
• JavaScript-like anonymous / lambda functions and closures.
• Python-like array slices and mapping.
• Support for parallelism (concurrent execution) using “goroutines”. This alone could be an attractive option; few developers delve into multi-threaded coding and Go appears to make it easy.

Compiling

Google provide two compilers: 6g for 64-bit and 8g for x86 systems. Both are designed to be fast and moderately-large applications will compile in under one second. Even the whole package library containing 120,000 lines of code compiles on a standard laptop in less than 10 seconds. There is also an alternative compiler based on GCC called Gccgo.

Unlike Java and .NET, Go compiles to a native binary rather than managed or intermediate code. That’s an unusual decision and many will argue it’s a backward step. In theory, managed code is safer, more portable, and potentially faster because it can be optimized for the processor it’s running on. In practice, few Java and .NET applications are known for their speed.

Does Go Have a Future?

Google are releasing the Go source code under the BSD license and hope an eager development community will evolve.

The language is experimental and is not recommended for production environments — there is no IDE integration, standard libraries are sparse, and there are few code examples. However, the project appears to be mature and the developers used it to build the web server which runs the project’s official website, golang.org.

With Google’s backing and resources, you can be assured Go has a future. Personally, I think the language has potential but it will be some time before it can lure developers away from their current platform of choice. There’s also one option Google are considering which is a little more dubious … see Why Google Should Not Give Chrome the Go-Ahead.

Will you try Go? Is it the future or another minority development language?

Link: The Go Programming Language.

Related posts:

1. Google Releases its JavaScript Closure Tools Do we need more JavaScript libraries and tools? Perhaps not,...
2. Will Server-Side JavaScript ever catch on? Server-side JavaScript appears to be a logical choice for web...
3. Google Offers 3D Rendering in the Browser Google's new O3D project provides a plugin that allows developers...

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. How to Write a Cookie-less Session Library for JavaScript Craig provides the code for a stand-alone JavaScript session variable...
3. Fixing Object Instances in JavaScript Even experienced coders can get caught out by object handling...

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...

A Brief History of Ajax

Ajax is a conceptual technique. The technologies have been available for over 10 years, but Ajax adoption became widespread after Jesse James Garrett’s article in February 2005 which described the techniques and provided a great acronym: Asynchronous JavaScript and XML.

Despite its name, Ajax does not necessarily depend on asynchronous calls, JavaScript or XML. Today, Ajax is a useful term applied to any system that communicates with a back-end web server to update content without requiring a full web page refresh (although many marketing departments confusingly refer to Ajax when describing any type of animation or interactivity!)

Most Ajax systems utilize the XMLHttpRequest object which permits programmatic server communication. It was introduced by Microsoft in March 1999 when Internet Explorer 5.0 was released. The original implementation was an ActiveX object devised specifically for the Outlook Web Access system. Most browser vendors followed Microsoft’s lead and implemented XMLHttpRequest as a native browser object.

Many of the dynamic web applications we rely on today would not be possible without Ajax techniques.

Does Eolas Have a Valid Ajax Patent?

Eolas Technologies is the company that fought Microsoft over the use of embedded browser applets, such as Flash. Eolas won that case and were awarded over $500 million in 2003. For several years, IE had to show a ridiculous alert box whenever an embedded object was encountered in the HTML.

Eolas 7,599,985 is a continuation of the original patent and has the snappy title “Distributed hypermedia method and system for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document”. It was filed on 9 August 2002 and describes Ajax-like systems. Here’s an excerpt:

A system allowing user of a browser program on a computer connected to an open distributed hypermedia [web page] to access and execute an embedded programming object. The program object is embedded into a hypermedia document much like data objects.

The user may select the program object from the screen. Once selected the program executes on the user’s (client’s) computer or may execute on a remote server or additional remote computers in a distributed processing arrangement.

After launching the program object, the user is able to interact with the object as the invention provides for ongoing interprocess communication between the application object (program) and the browser program.

The present invention allows a user at a client computer connected to a network to locate, retrieve, and manipulate objects in an interactive way. The invention not only allows the user to use a hypermedia format to locate and retrieve program objects, but also allows the user to interact with an application program located at a remote computer.

Interprocess communication between the hypermedia browser and the embedded application program is ongoing after the program object has been launched. The use is able to use a vast amount of computing power beyond that which is contained in the user’s client computer.

To most developers, the Eolas claim is absurd:

• Ajax is a programming technique — not a technology.
• Eolas did not define the name ‘Ajax’ or provide technical implementation details.
• Ajax technologies and techniques existed before the patent was filed. Microsoft’s first implementation of XMLHttpRequest was developed 40 months before the Eolas patent was filed, although it took several years for developers to realize its power. Prior to XMLHttpRequest, on-page server communication was still achieved using more rudimentary techniques such as IFrames or dynamic script injections.
• Ajax has been adopted by millions of websites — can Eolas file lawsuits against them all?
• The patent is vague and could be applied to a wide range of web page interactions.

However, it has been ruled as valid by the US Patent Office on three separate occasions. If Eolas win their infringement case, there is nothing to stop them taking out a lawsuit against … everyone.

Will Common Sense Prevail?

Who knows what will happen once the lawyers become involved.

I’m no legal expert, but it appears that Eolas have filed a US patent — which does not necessarily apply worldwide. Could we see a situation where US companies hand their web development and hosting to offshore providers to avoid a lawsuit? If that’s the case, perhaps Eolas should consider their impact on the US economy?

Does Eolas have a valid Ajax patent? Is this another good reason to abolish software patents? Read the Eolas Lawsuit press release and decide for yourself.

Related posts:

1. Did Google Just Patent Gears? Why? Gears is the Google-led open source browser plugin that lets...
2. CSIRO Receives $185 Million for Wi-Fi Patent It's official: wi-fi is a patented technology. Several large companies...
3. 5 Reasons Why Browser Sniffing Stinks Opera's recent problem with version 10's user agent has brought...

Our latest tutorial, The Easy Way to Install PHP on Windows sees SitePoint’s own Louis Simoneau putting version 2 of Microsoft’s Web Platform Installer (Web PI) through its paces.

Louis will demonstrate how to install PHP with the Web Platform Installer, and along the way will show how conveniently this tool can pull in different open source software packages and install them for you. You’ll learn, for example, how to grab MySQL, WordPress, and Drupal, and watch the Web PI install them all automatically. And therein lies the beauty of the Web PI—you don’t have to dither around configuring stuff yourself.

Louis also gives us a heads up about some of the other cool features, such as the excellent SEO tool, which can analyze your site or application. It’ll check for broken links and provide recommendations to improve the site’s search engine friendliness and overall performance.

The Web PI also has a caching extension for IIS, which improves web server performance and makes it a serious competitor to Apache for hosting PHP applications. Take a look and see what you think.

A huge thank you to Microsoft, who are our sponsors for the multiple choice quiz for this article—if you find the article interesting, be sure to check how closely you paid attention!

Article: The Easy Way to Install PHP on Windows
Quiz: Web Platform Installer Quiz

Related posts:

1. How to Install PHP on Windows In his final installation tutorial, Craig provides a step-by-step guide...
2. How to Install PHP 5.3 on Windows PHP 5.3 is the most significant update since version 5.0....
3. Free PHP Webinar: How to Increase Performance with Caching Zend are running a free webinar today, with a live...