FerretArmy: A Web Developer's Paradise

jQuery 1.4 is officially out now! The jQuery team is in the process of doing a 14-days-of-jQuery-1.4 promotion, which will run through the 28th of January. This is a major release, with much of the jQuery framework being rewritten in addition to a lot of new functionality. The last major release of jQuery was in February 2009, so this has definitely been a long time coming (see my 1.4 preview post here).

There’s a new set of jQuery API documentation, with a new look and some other enhancements. One thing I’m a big fan of is the ability to see when a particular function was added to jQuery – it’s very easy to hone in on the new stuff that way. One thing I feel is still missing is the abilityto jump directly to the function implementation in the library, like how the Google Closure API documentation is setup.

Interestingly, the last day of the 14-days-of-jQuery-1.4 promotion will be the release of jQuery UI 1.8. jQuery UI 1.8 is looking to be a smaller release – a bunch of bugfixes and few somewhat underwhelming plugins, as well as support for jQuery 1.4. There are a ton of great jQuery UI widgets and enhancements that are in the proposal and development stages, but the pace of development has been very slow, which is disappointing. I’d very much like to see jQuery UI development kicked into high gear.

Overall, this is looking to be a great jQuery release. I’m impressed with the performance improvements (addClass is three times as fast now? amazing!), and the new functionality improves the experience dramatically. A lot of functionality that used to have to be gotten through plugins is now in the framework itself, which will be a boon to development. Check it out now!

WordPress 2.9 is out! It’s got some cool new features – a trash bin, better support for video embedding (which has been a major pain in the past), and a bunch of new features. One of the best things I’ve seen in the update documentation is this:

When you’re editing files in the theme and plugin editors it remembers your location and takes you back to that line after you save. (Thank goodness!!!)

The ‘Thank goodness!!!’ was their comment, not mine, which goes to show how annoying that bug was. Other than that, the built-in image editor is a pretty cool feature for on-the-go cropping and rotation, but time will tell whether I end up using it much. Either way, the upgrade process is a cinch, so it’s a no-brainer to get on the latest version of the greatest platform.

So, yet another week, and another fairly large announcement from Google. They’ve been coming pretty fast and furious lately – the open-sourcing of both Closure and Chrome OS are two fairly recent developments. However, the one this post will focus on is the announcement that Google is working on a new application-level protocol, dubbed SPDY.

SPDY (pronounced ’speedy’) is designed as an adjunct to the http protocol, which has been around for nearly twenty years now. SPDY was designed to run atop of tcp/ip, which is the place in the networking stack that the browser talks to the web server. Hence, to be able to utilize SPDY, both the browser and the web server need to understand the protocol. However, the router need not change at all, which will greatly aid in implementation, if it’s standardized as a protocol.

So what are the features of the SPDY protocol? First, it’s faster than standard HTTP through a number of mechanisms. By default, it gzips it’s headers (and all content), making the packets more lightweight. It only needs one channel for data transfer (it multiplexes requests through the channel, which functions as a stream), so there’s a tremendous amount of connection overhead reduction versus standard-fare HTTP. The connection is designed to remain open as long as the client wants, which means that new content can be pushed from the server to the client. Packet prioritization is built into the protocol as well.

The nicest part of SPDY, in my opinion, is that it requires the use of SSL by default. This means that every packet sent over the wire is encrypted. Deep packet injection and packet sniffing are realities in the world, so a switch to secure communication is long overdue.

The roadmap for SPDY seems pretty straightforward. It’s not finished yet, but being an open source effort, a standard could be developed in a few years. Browsers and web servers can build in protocol support as the standard is still being developed. Browsers and can try to handshake in SPDY with a web server, then default back to HTTP if necessary. There aren’t many competing protocols out there, especially ones that don’t require any router firmware updates (which would take a decade to roll out, at least). Even if the web doesn’t decide to run on SPDY, the only reason for that would be someone came up with an even better idea in the meantime. A new protocol is definitely in store for the future of the web.

Google just open sourced Closure, their robust JavaScript library. Closure is used in a variety of Google products, notably GMail and Google Docs. I had a chance to play with it for a few minutes, and I’m posting my first impressions.

Google Closure is a fairly complete JavaScript framework. In that sense, it duplicates a lot of the functionality of existing JavaScript libraries, such as jQuery and YUI. It contains behaviors, AJAX, event handling, selectors, UI components, and more. The syntax is fairly straightforward, but it’s not the same as other libraries, so there’s a learning curve in getting acquainted with it.

Closure has excellent dependency management through a robust loading mechanism. Basically, if you don’t reference a certain piece of the library, rest assured that it’s not going to load (and slow down your page as a result). In addition, it comes with the Closure Compiler, which will walk your JavaScript, determine what libraries you need, then aggregate and compress all the required files. Being able to deploy one file instead of many is a great way of speeding up your site.

One thing that irks me is that there only way to get Closure is through Subversion access to the trunk. If Google wants Closure to be adopted widely, they’re going to need to start offering discrete, packaged versions of it. Many developers (and novices) will be put off by the current distribution method otherwise.

The API is well documented, and has links to the actual code for each method (something that I’ve not really seen before in API documentation). The API itself is very robust, with a ton of methods and accessors on each object. I’m not sure I’m a big fan of the way things are laid out in the API, but I don’t have enough experience with it to say anything definitively here.

One doesn’t have to stretch the imagination to believe that Closure has amazing potential. This is, after all, what GMail is built from. I’m excited that it’s been open-sourced and I can’t wait to use it a bit more. Google has given a grand gift to the developer community with this release.

I use jQuery UI a lot. I’ve used it at work on internal projects, I’ve used it on some pages in ferretarmy.com, and it’s integral to blaqdesign.com. It’s a great set of rich UI controls and behaviors that work well and are easily integrated into a webpage. I can’t say enough about the toolset.

However, there’s a distinct point of failure of jQuery UI – ThemeRoller. ThemeRoller is the tool that’s used to create a jQuery UI theme – without a theme, there’s a lot less to love about jQuery UI. None of the widgets and CSS styling are available (interactions and effects would still be available, though). This past week, though, ThemeRoller was down. Specifically, it was not outputting custom themes, though the default ones were working. It was down for about three days, to be exact. This was a very big deal to me (amongst others, I’m certain) – I had to delay a production release because I couldn’t get a custom theme that I needed at the time.

There are a lot of reasons that ThemeRoller would be down, and it’s understandable that it will probably break at times as updates are made to it. The bad thing is that if ThemeRoller goes down, for whatever reason, there is no alternative available to create themes with. What I would like to see happen is there be established an alternate home for ThemeRoller. In addition, it should have an archive of all production versions of ThemeRoller. That way, if a bum version gets released for a few days, one can always use the previous version, which should work fine.

With these fairly trivial changes, jQuery UI would eliminate a point of failure. What could possibly be better than that?

I just found this preview of jQuery 1.4. I read some of this stuff at the jQuery site, but this is a nice explanation of the proposed functionality of the next major version of jQuery.

I think the new ‘live’ event handlers are going to be great. I can’t stress how much the ‘live’ method has helped my JavaScript development – it makes event binding much less of a chore when dynamically creating page content (especially for trivial things, like bindings for button hover behavior). One of the things I’ve disliked, though, is the change event of dropdowns isn’t able to be live captured, which has led me to use Live Query for those purposes. With 1.4, it can be done with jQuery alone.

It will certainly be interesting to see if the Lazy Load code is included, for on-the-fly .css and .js includes. By conditionally loading javascript and css, a lot of bandwidth could be conserved by choosing to defer file retrieval for little-used site features.

Some of the other cool new features will undoubtedly be radio classes and the offset get/set methods – I can see using those to save a few lines of code. I’m betting that there will also be some performance increases with 1.4, so I’m excited about the release, even if it’s release is still a few months off yet.

Normally, AJAX is limited to retrieving data on the same domain that served the page. This is a limitation of the XMLHttpRequest, done mostly for security purposes. There are several ways to get around this limitation, of course, using a variety of methods and techniques. This is one of the stranger that I’ve come across – CSSHttpRequest.

Essentially, this small JavaScript library exploits the fact that CSS stylesheets are not subject to the same domain policy, which enables cross-domain POST requests for .css files. This allows you to pull CSS rules from remote domains – rules that contain name-value pairs embedded in valid CSS styles. The particular technique used is to return name-value pairs in background url fields for fake style rules, as such:

#c0 { background: url(data:,Hello%20World!); }

The client-side applies these style rules when they return from the remote domain, then JavaScript is used to read the property values and turn them into essentially JSON data ready for client consumption.

Of course, there’s a reason that the same origin policy is enforced. Normally, resources on the same domain are considered trusted, while external resources are not. With a library like this, essentially, if you’re vulnerable to JavaScript injection, there’s not much you can do to keep someone from embedding CSSHttpRequest on your page then using it to pull content from a remote domain. Nasty trick, but it’s totally possible and even trivial to some extent.

There are certainly legitimate reasons to need cross-domain AJAX. However, I wouldn’t think to use such a technique on a public site – it has the feel of a hack since (AJAX isn’t supposed to cross domains, after all), and the potential erosion of public trust is not worth the benefits. As an exercise of an interesting technique, it’s very cool, though.

Steve Ballmer has, in the past, stated that he would be open to the idea of Internet Explorer dropping the Trident rendering engine in favor of the open-source Webkit. I, for one, would love it if this happens – Trident is the bane of web developers around the world. Simply stated, it is holding the web back from it’s true potential. Well, it looks like Google has done the work for Microsoft, with Google Chrome Frame for IE.

Essentially, Chrome Frame replaces all of the guts of IE with Chrome technologies. This extends beyond the rendering engine – it replaces the JavaScript engine as well, and whatever other parts needed swapping out. Using Chrome Frame, IE can immediately start to render HTML5 (canvas, audio, video), CSS3, and more. Even better, under Chrome Frame, all IE rendering quirks would cease to be an issue. Oh yeah, and it also makes IE faster – ten times faster for JavaScript performance, even in this beta stage.

To utilize Chrome Frame on your site, all that is needed is a single meta tag – if Chrome Frame is installed, IE will use it, and if not, the page will still render. This is very nice, unobtrusive behavior indeed.

<meta http-equiv="X-UA-Compatible" content="chrome=1">

Google developed Chrome Frame primarily for their upcoming Google Wave communication software. It probably became quickly evident to Google that they would never be able to offer the rich functionality that Wave requires under IE. I would expect that the release of Chrome Frame is ruffling some feathers at Microsoft – Google seems to be getting on the nerves of some it’s major tech competitors lately using similar tactics. Still, it’s hard to see how consumers lose with this move – to some extent, it’s the best thing that could happen to Internet Explorer.

I’ve just released my latest plugin, the jQuery UI Image Carousel! The plugin is a standard-fare image carousel, and it’s also fully compatible with jQuery UI. It’s got a few options that make it fairly versatile – from a minimal look all the way to a collapsible version with a custom header.

The JavaScript itself wasn’t that daunting – version 1.0 clocks in at around 180 lines. Most of it is presentation management as well – making sure that the correct jQuery UI classes are applied to the markup, and so forth. In total, it was a bit of a longer exercise – there was a lot of work to insure compatibility with older versions of IE, for instance. I hope you enjoy, and if you use it, please take a sec to leave a comment with your page URL.

Most of the time when you want to cancel an action on a web page, such as a button click, you’d return false in the client-side button event handler, as such:

<a href="blah..." onclick="return DoAction();">Link</a>

...

function DoAction() { /*Do Something */ return false; };

However, there’s a better way, using the event.preventDefault() method. I had the need to use this recently, when I was fixing a trivial issue with the Filament Group jQuery UI buttons – my ‘a href’ styled buttons were still clickable when they were disabled. An easy solution to this problem is to capture the click and prevent the default action. I hooked this action to all disabled buttons, as such.

$(".ui-state-disabled").click(function(event) { event.preventDefault(); });

This code isn’t that robust – if you were to add or remove the ui-state-disabled class after page load (which I didn’t have to), you’d want to make sure to handle it appropriately. Either way, preventDefault() is definitely an elegant solution to disabling a click action.