Hookbox (via). For most web projects, I believe implementing any real-time comet features on a separate stack from the rest of the application makes sense—keep using Rails, Django or PHP for the bulk of the application logic, and offload any WebSocket or Comet requests to a separate stack built on top of something like Node.js, Twisted, EventMachine or Jetty. Hookbox is the best example of that philosophy I’ve yet seen—it’s a Comet server that makes WebHook requests back to your regular application stack to check if a user has permission to publish or subscribe to a given channel. “The key insight is that all application development with hookbox happens either in JavaScript or in the native language of the web application itself”.

canto.js: An Improved HTML5 Canvas API (via). Improved is an understatement: canto adds jQuery-style method chaining, the ability to multiple coordinates to e.g. lineTo at once, relative coordinate methods (regular Canvas does everything in terms of absolute coordinates), the ability to use degrees instead of radians, a rounded corner shortcut, a more convenient .revert() method and a simple parser that can understand SVG path expressions! The only catch: it uses getters and setters so won’t work in IE.

nodejitsu’s node-http-proxy (via). Exactly what I’ve been waiting for—a robust HTTP proxy library for Node that makes it trivial to proxy requests to a backend with custom proxy behaviour added in JavaScript. The example app adds an artificial delay to every request to simulate a slow connection, but other exciting potential use cases could include rate limiting, API key restriction, logging, load balancing, lint testing and more besides.

One of the most basic tests developers perform in JavaScript is whether or not a particular property exists on an object. Since feature detection is the preferred method of code forking, developers are encouraged to test for the existence of properties before using them. There is a lot of buggy JavaScript code out there as inexperienced developers try to use feature detection. A lot of the problems reside with a lack of understanding as to the nature of object properties in JavaScript.

Where do properties come from?

Before attempting to detect properties, it’s important to understand from where they originate. There are two basic types of properties in JavaScript: those that exist on the object (also known as “own” properties) and those that are inherited through the prototype chain (often called “prototype” properties). Consider the following:

var person = {
    name: "Nicholas"
};

alert(person.name);        //"Nicholas"
alert(person.toString());  //"[object Object]"

In this code, the object person has only one own property, which is name. You can still access other methods on the object such as toString(), but these are inherited through the prototype chain. Object literals inherit from the Object type, so all of the basic methods of Object are accessible on the instance.

The big difference between own properties and prototype properties is the difference between unique and shared values. Own properties belong to that single object instance and can’t be affected by other instances of the same type; prototype properties belong to the prototype of the object, and since the prototype can be shared amongst multiple instances, these properties are also shared amongst multiple instances. Here’s another example:

var person2 = Object.create(person);
var person3 = Object.create(person);

alert(person2.name);   //"Nicholas"
alert(person3.name);   //"Nicholas"

person.name = "Adam";

alert(person2.name);    //"Adam"
alert(person3.name);    //"Adam"

This example uses the Object.create() method from ECMAScript 5 to create two objects, person2 and person3, that inherit from person. The prototype for both person2 and person3 is person, and so name is actually a prototype property that is accessible through person2 and person3. This is why displaying the values of name on both objects results in the same value: they are both sharing the prototype property name. That means when person.name is changed directly, the change is accessible from the instances.

It’s important to understand that name is a prototype property for both person2 and person3, but it’s an own property for person. You can only assign values to own properties, so attempting to assign a value to a prototype property actually causes a new own property of the same name to be created. Example:

alert(person2.name);    //"Nicholas"
alert(person3.name);    //"Nicholas"

person2.name = "Adam";

alert(person2.name);    //"Adam"
alert(person3.name);    //"Nicholas"

Since you can’t assign to prototype properties, assigning a new value to person2.name actually creates a new own property on person2 called name. Own properties always shadow prototype properties, so the next time you access person2.name, you’re accessing the own property instead of the prototype property. That will continue until the own property is removed using delete, such as:

delete person2.name;

alert(person2.name);    //"Nicholas"

You can only call delete on an own property to remove it (calling on a prototype property does nothing). Once the own property name is removed, there is nothing shadowing the prototype property name and so person2.name now refers to the prototype property.

Note: While all native object types (Array, Boolean, Date, all Error variants, Function, Number, RegExp, and String) inherit from Object, non-native object types, such as those that represent the DOM in browsers, don’t necessarily inherit from Object in all browsers.

Detecting properties

Let’s say you want to determine if a given object has a property of name. In experienced developers tend to write code like this:

//doesn't accurately test for existence
if (person.name){
    //yay! property exists!
}

At first glance, this seems okay. However, understanding how JavaScript works reveals some problems with this approach. First, this will only succeed if the value of person.name is truthy, meaning it’s an object, a non-empty string, a non-zero number that’s not NaN, true, and not null or undefined. That means if person.name is the empty string (”"), this check will fail. Failing, in this case, doesn’t mean that the property doesn’t exist. In fact, the property does exist and contains a value, but the value is falsy and so doesn’t pass this test.

Detecting own properties

Keeping in mind that this is about testing for the existence of the property and not for the usability or data type, there are a couple of options. The first option is to detect own properties, and it comes via a method on the Object type called hasOwnProperty(). Since native objects inherit from Object, this property is inherited by these objects and can be used to detect the existence of own properties:

alert(person.hasOwnProperty("name"));   //true
alert(person2.hasOwnProperty("name"));    //false

person2.name = "Adam";

alert(person2.hasOwnProperty("name"));    //true

delete person2.name;

alert(person2.hasOwnProperty("name"));    //false

Initially, person2 has a prototype property name, so hasOwnProperty() returns false. Once an own property is created, calling hasOwnProperty() returns true. And after the property is removed via delete, this method again returns false.

JSON serialization works only for own properties, and non-native JSON serialization utilities used hasOwnProperty() to ensure that only the properties defined on object literals were included in the resulting string.

Detecting all properties

If you only care that the object has a property and don’t care whether it’s an own property or a prototype property, you can use the in operator to determine the existence of the property. Example:

if ("name" in person){
    //property exists
}

The in operator returns true when the named property exists on the object. In many cases, the in operator is all that you’ll need (especially when dealing with DOM objects). In fact, Mark Pilgrim’s All-In-One Almost-Alphabetical No-Bullshit Guide to Detecting Everything for HTML5 makes extensive use of in for detecting the new HTML5 features on DOM objects.

Conclusion

If you just want to check for the existence of properties, and not necessarily what their value might be, then you have two safe options: hasOwnProperty() and the in operator. The hasOwnProperty() property method should be used if you want to detect own properties only. If you want to test property existence and don’t care if it’s an own property or an object property, then the in operator is the one to use.

Update (27 July 2010): Added false and NaN to list of falsy values.

Update (29 July 2010): Fixed description of truthy/falsy values.
Related posts

• Feature detection is not browser detection
• Naked JavaScript objects
• Get the JavaScript global
• Good object-oriented design in JavaScript
• Feature detection != browser detection
• Browser detection versus feature detection

P.S. My new book, High Performance JavaScript is now out! If you want more than performance, check out Professional JavaScript, 2nd Edition.

Side-by-side versions of different browsers are critical for us webdevs. On some browsers, it’s because multi-year-old versions are still prevalent (luckily, you can start ignoring them). In the case of Chrome, nearly all users are up-to-date with the very latest Stable release. Being the forward thinking chap/gal you are you want to try out new stuff like WebGL that’s only available in the Dev channel. But you don’t want to mistakenly build something that uses features users don’t have yet. What to do? Side-by-side installs, a.k.a. the Canary channel! Now you can test with Stable while plotting world domination on Dev. Awesome.

This new version will auto-update with the new hotness at roughly the same rate as today’s Dev channel but will allow you to install and run it alongside a Stable channel version of Chrome. This new channel is Windows-only for now, but you have VMs for testing anyway, right? Happy testing!

I know, it’s been too long. What can I say? I’ve been busy. Really, really busy. A few weeks ago Cloudera announced our latest release of our Hadoop Distribution and the open sourcing of numerous projects that are part of that distribution. If you’re reading my blog because you care about JavaScript and stuff, this won’t [...]

You can get yours here. Note that these are Dev Channel builds, so they contain the new hotness. Also, the new bugs. Caveat emptor.

Huge props to Robert Shield who has been working through the endless details of this effort for months.

Multi-node: Concurrent NodeJS HTTP Server. Kris Zyp’s library for spawning multiple Node child processes (one per core is suggested) for concurrent request handling, taking advantage of Node’s child_process module. This alleviates the need to run multiple Node instances behind an nginx load balancer in order to take advantage of multiple cores.

Frequent readers will remember my mission to stop browsers from making automatic requests when an empty string URL is reference in script. My mission began with a post entitled, Empty image src can destroy your site, in which I explained just how devastating this browser quirk can be to an enterprise system. After that point, I started contacting browser vendors and discussing the issue on the WHAT-WG mailing list. I also did some research only to find that there were other tags besides <img> that suffered the same effects in some browsers, though in very inconsistent ways. I posted a followup on the progress I’d made in various arenas, including getting HTML5 updated to say that automatic downloads of resources should not happen for empty string URLs.

It’s been eight months since my original post and from when I started contacting people about this issue, so I thought it would be good to update the current state. Keep in mind that Opera is intentionally left off of this list because they never have initiated a request for an empty string URL (hooray Opera!).

Firefox

Firefox 3.5 fixed the issue with <img src=""> so that it did not fire off a request as it did in previous versions. Unfortunately, it still fires a request for <script src=""> and <link href="">. I filed a bug with Mozilla about this (the one that started the WHAT-WG discussion) and while a patch has been submitted on the bug, it hasn’t yet been incorporated into a build. There hasn’t been any movement in over a month, so perhaps it’s time to nudge them again.

Safari and Chrome

When I first went through and looked at the WebKit bug queue, I found an existing bug mentioning this issue. I added my comments as discussions continued with various people. Unfortunately, there wasn’t much movement on the issue, which is particularly dismaying because WebKit made requests for <img src="">, <script src="">, and <link href="">, making it the worst current browser engine for this issue.

Seeing a lack of movement, I filed a bug against Chrome, hoping that they could apply some pressure. It took a little while, but the Chrome team eventually came back and said they would fix the issue. You can follow the conversation from the Chrome bug back onto the WebKit bug, where a patch has now been submitted for this issue. The Chrome bug indicates that this is scheduled to get fixed in Chrome 6 and there is no word yet on when it’s scheduled for Safari.

Internet Explorer

Being the least transparent of all browsers, it was difficult getting contacts to people who could make a difference. My initial attempts to get some movement failed, and I had to go back through my personal network to find another contact before I could make any progress. Finally, I got confirmation that the team believed fixing this issue was the right thing to do and that it would make it into a future build. They couldn’t tell me what version or build this would be fixed in (corporate policy) but did assure me that it would be addressed in the future.

While sitting in the Internet Explorer 9 talk at Velocity, there was a slide featuring a bunch of performance-related fixes made in IE9. Towards the bottom of the slide was a bullet saying that <img src=""> will no longer fire a request. When I got home, I setup the Internet Explorer 9 Platform Preview 3 to find that the issue had been fixed. So Internet Explorer 9 will definitely not fire these requests any more.

Conclusion

We’re not completely out of the woods yet, but with changes to HTML5 and all browsers now on the path towards resolving this issue, we could very well have seen the last of this issue by the end of 2010. I think this is a testament to just how great the web community is: to be able to take an issue in front of the people who can resolve it and see such amazing progress. I’d like to thank each of the browser vendors from responding to this issue. We’re almost there!
Related posts

• History of the user-agent string
• Empty-string URLs in HTML - A followup
• Protect IE from empty img src
• And so the HTML 5 trouble begins
• Cross-domain XHR removed from Firefox 3
• The Web could be heading for another dark age

P.S. My new book, High Performance JavaScript is now out! If you want more than performance, check out Professional JavaScript, 2nd Edition.

In this post I will show how to check currently loaded jQuery UI version on the page. Unlike checking loaded jQuery version ( $().jquery ), checking jQuery UI version is a bit different. Checking currently loaded jQuery UI version on the page: // Returns jQuery UI version (ex: 1.8.2) or undefined $.ui.version // Alternatively jQuery.ui.version You would most probably use it in the if

DNode: Asynchronous Remote Method Invocation for Node.js and the Browser. Mind-bendingly clever. DNode lets you expose a JavaScript function so that it can be called from another machine using a simple JSON-based network protocol. That’s relatively straight-forward... but DNode is designed for asynchronous environments, and so also lets you pass callback functions which will be translated in to references and used to make remote method invocations back to your original client. And to top it off, there’s a browser client library so you can perform the same trick over a WebSocket between a browser and a server.

Diffable: only download the deltas. JavaScript library for detecting and serving diffs to JavaScript rather than downloading large scripts every time a few lines of code are changed. “Using Diffable has reduced page load times in Google Maps by more than 1200 milliseconds (~25%). Note that this benefit only affects users that have an older version of the script in cache. For Google Maps that’s 20-25% of users.”

getlatlon.com commit dae961a.... I’ve finally added an OpenStreetMap tab to getlatlon.com—here’s the diff, it turns out adding a custom OpenStreetMap layer to an existing Google Maps application only takes a few lines of boilerplate code.

Most of us have to make our web pages work in The Big Five browsers, so I thought it was about time I introduce you to the debugging tools for each of those browsers with a couple of tips thrown in to the mix. Watch Watch Debuggers screencast (Alternative flash version) QuickTime version is approximately 100Mb, flash version [...]

I was sitting in a talk given by Facebook’s Jason Sobel at Velocity this year, when I was a bit surprised by an impassioned plea that he made at the tail end of the talk. To paraphrase, Jason said that CSS sprites require too much work for average web developers and that we should be pressuring the browser vendors to make this process easier. I was perplexed for a moment. First, I don’t think CSS sprites are all that complicated anymore, especially with tools like the online CSS Sprite Generator readily available. Second, CSS sprites only really have to be used for older browsers (looking at you, IE6 and IE7), as this problem is easily solved in other browsers by using data URIs. Jason’s epilogue made it even clearer to me that people still don’t understand the true power of data URIs and how they’ll transform web development going forward.

The purpose of CSS sprites

Before getting into how data URIs make CSS sprites obsolete, it helps to examine the problem that CSS sprites solved. The problem is that HTTP requests are a major performance bottleneck for web pages. The more requests you have, the longer it takes your page to load and the slower it is, so every little image you load onto a page fights against you in your quest for page speed.

CSS sprites solved this problem by combining multiple images into a single file, thus collapsing all of those extra HTTP requests into a single request and vastly speeding up the page. The downside is the overhead of planning for and using CSS sprite images, as the images need to be arranged in a certain order, perhaps with some extra blank space in between. That typically meant that someone had to write down the location of each individual image within the larger sprite image so that CSS could be used to position the image in the correct spot to show the correct image. For more information see Dave Shea’s article, CSS Sprites: Image Slicing’s Kiss of Death.

Basic CSS sprite usage

The pattern I use the most for CSS sprites is relatively straightforward and has the goal of ensuring CSS maintainability. There is a single class that contains a reference to the CSS sprite image and several other classes that simply move the background into different positions. For example:

.mysprite {
    background: url(mysprite.png) no-repeat;
}

.icon1 {
    background-position: 16px 16px;
}

.icon2 {
    background-position: 32px 16px;
}

Suppose you were making a progressively enhanced toolbar with this CSS, so there’s an unordered list with each item representing a button. Imagine that these are styled such that the text is hidden and each list item link simply becomes an image to click on. The HTML for such an example would look like this:

<ul class="toolbar">
    <li class="mysprite icon1"><a href="/save">Save</a></li>
    <li class="mysprite icon2"><a href="/open">Open</a></li>
</ul>

For any element that wants to use the master sprite image, the class of mysprite is applied. Then, a second class is applied to move the sprite into position. Note that there are alternate techniques that have the same result; the reason I like this one is because the URL is only ever referenced once (good for maintainability) and it’s able to be used anywhere on the page.

In terms of performance, the benefit to this technique grows as the number of images in the same file increases. You can end up with one very large image file, but that is still better than making multiple requests for a bunch of small images. You make a single request for the sprite image and after that point it’s cached by the browser, so you no longer have to worry about making a request. Note also that if the CSS is in an external file, it too will be cached.

Using data URIs instead

A little while back, I wrote about what data URIs are and how to use them. In short, data URIs allow you to embed images (and other files) directly into HTML and CSS. Since all of the data is represented locally, there is no extra HTTP request required to access the information.

Remember that the original problem that CSS sprites solved was having too many HTTP requests for images. Data URIs also solve that problem, and solve it in a much more manageable way. Instead of using a single extra request to get the large sprite image, you use zero extra requests to get the images to use. What’s more, there’s no need to combine all of the images - you can keep the images separate and use them as normal background images. The CSS doesn’t really change all that much (full data URIs omitted for space):

.mysprite {
    /* no longer needed */
}

.icon1 {
    background: url(data:image/png;base64,<data>) no-repeat;
}

.icon2 {
    background: url(data:image/png;base64,<data>) no-repeat;
}

Here, the mysprite class actually becomes unnecessary as the image data now resides in each icon class. The HTML doesn’t need to change (though you can remove mysprite if you so desire) in order to create the same effect.

At first glance, this may seem strange to you. The first question that people tend to ask when I describe this approach is that I’m dramatically increasing the size of the CSS by embedding the image data, doesn’t that hurt performance? The answer is no, so long as the CSS lives in an external file and is gzipped and cacheable by the browser. Base64 encoding, which is how the image data is represented, compresses remarkably well when gzipped, ultimately resulting in roughly the same amount of bytes being transferred over the write as compared to downloading the original image file. The added benefit is that you’re making zero extra calls for all of the images. And since these are in your external CSS files, they are also cached, so the next time the user comes to the page the CSS file is pulled from cache with the images already inside.

Automatic transformation

Because I believe in this technique so much, I wrote a tool called CSSEmbed (read the announcement) that makes it trivial to update your image-based CSS into data URI-based CSS. This frees you up to write CSS code like this:

.icon1 {
    background: url(icon1.png) no-repeat;
}

.icon2 {
    background: url(icon2.png) no-repeat;
}

So you write CSS in the old-fashioned, non-performant way with individual images, run it through the tool, and you automatically get a CSS file with data URIs embedded. That’s it, no more arranging images into a single file or keeping track of coordinates.

Note: CSSEmbed also supports an MHTML mode to make IE6 and IE7 compatible stylesheets that use internal images similar to data URIs.

Conclusion

CSS sprites were a solution to the problem of multiple HTTP requests to download multiple images. Data URIs allow you to embed images directly into your CSS files, solving the same problem in a much more elegant and maintainable way. Although we still need CSS sprites for older versions of Internet Explorer, that shouldn’t prevent you from investigating the use of data URIs as a better alternative to CSS sprites. Once IE6 and IE7 go away for good (some day), there really shouldn’t be the need to use CSS sprites so heavily if at all.
Related posts

• Automatic data URI embedding in CSS files
• Data URIs explained
• Internet Explorer 8 document and browser modes
• Writing maintainable code
• New site design
• Wanted: Browser debug mode

P.S. My new book, High Performance JavaScript is now out! If you want more than performance, check out Professional JavaScript, 2nd Edition.

Escaping regular expression characters in JavaScript (updated). The JavaScript regular expression meta-character escaping code I posted back in 2006 has some serious flaws—I’ve just posted an update to the original post.

So you’re making the new shiny — ’cause that’s how you roll — and you’re thinking to yourself “hrm, I’ve told users of legacy browsers to get Chrome Frame or upgrade, but there’s this new awesome feature in the Chrome Developer Channel…but it’s not in the version of Chrome Frame I’m testing with. I thought I was on the Dev channel?”

Indeed, if you installed GCF prior to the Beta release, you would have been on the Dev version, but when the Beta was pushed, all existing GCF users were moved to it as a one-time transition. That means you might not be getting the new shiny features we’re pouring into Dev as quickly as you anticipated…but fear not! There’s a new Dev Channel Release available. If you’re developing sites with GCF and you want to see what’s coming, I highly recommend getting and testing against this version. You won’t be moved to Beta again, so this uninstall/reinstall is a one-time change.

As folks begin to use and test with GCF, one of the first many try is to use the OptInUrls registry key to over-ride a site’s preference about which renderer to use. This tends to cause confusion and spurious bug reports because many sites employ server-side User-Agent detection to send different content to different browsers. Since GCF uses IE’s network stack and reports a slightly modified IE User-Agent instead of Chrome’s UA, server-side detection may send IE-specialized content instead of Chrome-friendly content. This includes many large sites like Yahoo, GMail, and most sites built with GWT’s server-side detection.

These are not bugs.

Those sites are working as intended and GCF is operating correctly. What’s happening, instead, is that by adding sites to the OptInUrls list that do not understand GCF, you’re breaking the contract at the core of how GCF works: existing content works the way it always has. It’s only when you’re sure that a site is sending browser-neutral content (usually when it’s your site) that you should ever add a site to the OptInUrls list for your system or organization. As usual, if you’ve got questions about GCF that aren’t answered in the FAQs or docs, you can ask them on the Google Group for the project. The whole team is subscribed to the list and we’re focused on helping you make awesome apps, so stop by, say howdy, and let us know how it’s going.

When it comes to AJAX and WebSockets, it's hard to think about client-server interaction without eventually thinking about Chat. Chat applications are probably one of the first ways in which we ever experienced remote communication outside of the traditional web-based, request-response life cycle. As such, I think there is a certain romance with the chat paradigm - something about it just feels special in a way that I can't quite articulate. So it should come as no real surprise that I wanted ... Read More »

jQuery.queueFn. “Execute any jQuery method or arbitrary function in the animation queue”. I’m surprised this isn’t baked in to jQuery itself—the plugin is only a few lines of code.

Yesterday, I started playing around with Pusher , a realtime push notification web service that allows your server to "push" updates to the client using native HTML5 or Flash-based WebSockets. If you don't know what WebSockets are (neither did I), they provide a way for the client to open up a direct line of communication with the server. The server can then send information back to the client at any time without the client having to constant ... Read More »