jQuery 1.3 Released

Setting a land speed record for transition from Beta->RC->Release, the jQuery project has released version 1.3 of its popular JavaScript framework. All in all, it is a major release for the project and could have easily been dubbed "jQuery 2.0".

The important features of this release are:

  • A rewritten and very fast CSS selector engine: Sizzle. The Sizzle code base is stand-alone has been donated to the Dojo Foundation in an effort to encourage other JavaScript libraries to adopt it.
  • "Live Events" (also referred to as Event Delegation): a new API for binding events to current and future DOM elements. The live() function is used to bind an event to all matched elements, including future matched elements that are added to the DOM. The die() function removes the bound live event.
  • A rewrite of jQuery's event handling. The introduction of a jQuery.Event wrapper object brings jQuery's event model in line with W3C standards and makes events work smoothly across all browsers; the wrapper also allows arbitrary data to be associated with events. All triggered events now "bubble up" the DOM tree, but progress can be halted via a stopPropagation() function.
  • A rewrite of HTML injection (e.g., the append, prepend, before, and after methods) for much greater speed (heavy use of DOM Fragments).
  • A rewrite of the offset() method for better cross-browser compatibility as well as greater speed.
  • No more browser sniffing. As of 1.3, jQuery no longer uses any form of browser/userAgent sniffing internally. Instead, a technique called "feature detection" is used to simulate a browser feature (or bug) internally to see if it exists or behaves as expected. All of these checks are encapsulated in the object.

Anyone doing an upgrade to 1.3 from previous versions should note there are some backward compatibility issues which are noted here (under "Changes"). The full release notes are here.

In other news, there is a new API browser for jQuery (written by Remy Sharp), which is available online or as an AIR application. The project has also decided to join the Software Freedom Conservancy and will continue to be developed under its auspices. John Resig elaborates on the reasons for the move in his blog entry.

The new release can be downloaded from the main page.

jQuery 1.3 Reaches RC1

jQuery 1.3 has officially reached Release Candidate status. There are no release notes for this release, but for those who haven't been following the beta releases, you can read more about the changes in 1.3 here and here.

RC1 can be downloaded here.

Firebug 1.3 Released


The Firebug 1.3 plug-in for Firefox 3.0.x has been released. The release features new tracing capability, used mostly for internal debugging but used to drive improvements in the Net panel as well. There are also numerous bug fixes. The full release notes are here.

The upcoming 1.4 release of Firebug will target Firefox 3.1.

Ajax for the Lazy: Ajaxify


From the "good to know" deptartment: a new jQuery plugin for converting existing links on a page to AJAX load and submit requests is available: Ajaxify.

Some examples:

//The easiest way: binds "click" event to existing "href" attribute
//and loads it into the portion of the page specified by the "target"

//With options
        target: '#container',
        title:'Setting up options',

The Ajaxify plug-in also supports partial loads and forms. A demo page is available here.

jQuery 1.3 Beta 1

The first beta release of jQuery 1.3 is out.

Changes since 1.2.x:

  • New CSS selector engine (Sizzle)
  • Rewrite of DOM manipulation
  • Rewrite of namespaced event handling
  • Rewrite of .offset()
  • And more...

See earlier coverage here for more details.

Get jQuery 1.3 beta 1 here.


John Resig has just publicly announced a new extension/framework for unit testing JavaScript code with Firefox/Firebug called FireUnit. The framework provides a simple API for reporting test results within a new tab in Firebug. It also provides some methods for simulating browser events. Developers can use a local HTTP test server for running unit tests that need to simulate a network communication.

FireUnit requires Firefox 3+ and Firebug 1.2+. You can grab the extension and source code here.

There are some examples of how to write a test case here, and there is a blog entry on FireUnit by the other co-author here.

jQuery Patches for 1.3

Offering a sneak peak of what will be in the new version, John Resig has released the first in a series of patches to jQuery in preparation for the 1.3 beta release. They are:

  • A patch to the .domManip method to use DocumentFragments, resulting in manipulation code (append, prepend, etc.) that is about 15x faster.
  • Addition of a .closest(selector) method which starts with the current node and traverses the parents in the DOM tree to match the selector (think "first self or ancestor"):
    closest: function( selector ) {
              return {
                  var cur = this;
                  while ( cur && cur.ownerDocument ) {
                       if ( jQuery(cur).is(selector) )
                          return cur;
                       cur = cur.parentNode;
  • A patch to the seminal DOM ready() method that backs off attempting to detect the loading of stylesheets (apparently not possible according to Resig) to normal "document ready" functionality.
  • Addition of multiple-namespace support for events.
  • A new internal property that keeps track of the selector chain (mainly for use by plug-in authors).

The new jQuery 1.3 will also feature the Sizzle JavaScript CSS selector engine as well as revamped implementations of all the selector-based methods.

You can read all about the new patches in Resig's original post here.

Update: the new Sizzle engine has been added to the 1.3 trunk.

Ext GWT 1.2 Released

Ext GWT, a library for integrating Ext JS with Google Web Toolkit, has released version 1.2. New features include Drag and Drop (with support for Grids, Trees, and Lists), Form Data Binding, and File Upload.

It can be downloaded here.



In August of 2008, John Resig started the Sizzle project, a new JavaScript CSS selector engine, with the goal of providing a small (about 4k) and fast core that could be leveraged by jQuery as well as other libraries (such as Dojo, MooTools, etc.). According to Resig, the new library is about 4 times faster than other selector engines in all major browsers. Resig has also been active in courting other framework designers, asking them to adopt Sizzle in their libraries.

While some have many have expressed great excitement at the idea of having a common selector engine, not all are enthusiastic about the idea. Valerio Proietti from the MooTools project has written a blog detailing why he won't be using Sizzle, and even going so far as to say it discourage competition in the JavaScript framework arena.

I’m not saying that John Resig seeks a monopoly over CSS selector engines, but that’s sure what it looks like. Competition and innovation will stop if everyone uses the same piece of code. Yes, competition and innovation[...]

So, if using one shared selector engine is ok, where do we draw the line? Is it ok to use a shared DOM manipulation library, or a shared event library? What makes our framework ours? If we start replacing core parts by outsourcing them to Dojo, our frameworks will just be a dull layer for code we didn’t even write, and we will lose credibility.

While one has to respect Valerio's decision to stick to his own code, I think that he misses some of the potential benefits of having a common selector core across multiple frameworks: elimination of code duplication, consistency of behavior, and robustness (if multiple libraries use a common core, bugs get squashed quicker). After over a decade, JavaScript is finally "growing up" as a language: frameworks like Dojo, Prototype, and jQuery have been a big part of this, allowing developers to get much more done in a much faster time frame than was possible before. It is only natural during this process that common pieces of infra-structure get built to allow framework designers to focus on other things.

If Resig does a great job with Sizzle, why should a new JavaScript library re-invent the wheel? Claiming Resig is somehow seeking a "monopoly" over JavaScript selector engines seems a bit silly and far-fetched. I think the real issue is an (understandable) pride is his own code, and a reluctance to throw it away in favor of someone else's...

JSON - 3D Proof of Concept

A few weeks ago I wrote a post on the concept of using JSON for creating 3-D models (You can read the first JSON 3D post here). I have created a proof of concept based on MooCanvas to allow for IE support. This proof of concept is also based on the 3D cube demo for MooCanvas with some modifications.

For this proof of concept the important function is Load3D which loads and translates the JSON 3D object.

 		function Load3D(obj, translateX, translateY, translateZ){
			scene.shapes[(obj.type + ObjectCounter + "")] = new Shape();
			var p = scene.shapes[(obj.type + ObjectCounter + "")].points; // for convenience
			for(var a=0; a<obj.vrt.length; a++){
				p[a] = new Point(((obj.vrt[a][0])+translateX), ((obj.vrt[a][1])+translateY), ((obj.vrt[a][2])+translateZ));
			// Create Shape From Points
			for(var a=0; a<obj.fac.length; a++){
					scene.shapes[(obj.type + ObjectCounter + "")].polygons.push(new Polygon(
					[ p[obj.fac[a][0]], p[obj.fac[a][1]], p[obj.fac[a][2]], p[obj.fac[a][3]] ],
					new Point(obj.nrm[a][0], obj.nrm[a][1], obj.nrm[a][2]),
					true /* double-sided */,
					[obj.mat[a][0], obj.mat[a][1], obj.mat[a][2]]


For the JSON 3D object you would pass it into the Load3D function. While in this example I have put the JSON 3D object in the HTML, you would load the JSON 3D using Ajax (or a script tag) in the real world.

			var ThreeDobj = {
			Load3D(ThreeDobj, 0, 0, 0);

You can see the proof of concept here.

The proof of concept has been tested on Google Chrome, FireFox 3 and IE 7. It may work on other browsers (it should work on Safari and Opera), but has not been tested.

Syndicate content