Tag Archives: jquery

New Kid on the Block

On this cloudy Dallas Saturday morning, the ExtJS team announced the availability of Ext Core (beta). Ext Core is the core DOM selection, manipulation and events library of ExtJS which has been extracted out into a separate library released under a more liberal license. They smartly released this under the very permissive MIT license, in contrast to the cancerous GPL used for the full ExtJS.

What makes this interesting is it positions Ext Core as a direct competitor to the popular JQuery library. I really like both ExtJS and JQuery, so I decided to run a quick comparison of the two libraries to see if Ext Core is up to the task of replacing JQuery in my developer toolbox. Since there is so much overlap between the two, it makes no sense to use both.

Round 1 – Size

Library size of the two is pretty close. The minified version of JQuery runs about 56K, while the minified version of Ext Core weighs in at 75K. The 19K difference might matter for an iPhone application, but even then, I would consider it negligible. Both are pretty small libraries, so we’ll call Round 1 a tie and move on to feature comparison.

Round 2 – Load Event

How each of these libraries works the document ready event is more a matter of style. The JQuery convention is to use the dollar sign ($) for for operations, although you can fall back to using the full name (jQuery). Setting up a ready event in JQuery looks like this:

$(document).ready(function() {
    // do cool stuff

Ext Core uses the static Ext class for the same functionality. Like the jQuery object, the Ext object is the heart of Ext Core. Setting up the ready listener in Ext Core looks like this:

Ext.onReady(function() {
    // do cool stuff

One big difference is the onReady method can take an additional parameter specifying the scope in which the onReady method should execute. This is not a big deal in most cases, but shows Ext Core’s attention to support object oriented JavaScript. Since I’ve never actually needed to specify the scope, I’ll call this round a tie too.

Round 3 – Selectors

This is the heart of both libraries, and a full comparison could fill a dozen pages. The short story is they both support basically the same set of CSS3 selectors along with some custom enhancements. From looking at the documentation, I couldn’t find any typical use cases that either couldn’t handle. Like the document ready example above, it just comes down to a matter of convention. For example, here is the code from each to add a class to a set of nodes:

// JQuery

// Ext Core

One major style difference between the two is that Ext Core has a tighter focus in handing elements with ids, since that is critical to the full ExtJS library. For example, Ext Core has the get() method to directly grab an element by ID, along with a memory-friendly fly() method. The fly() method does not create a new element wrapper in memory, and instead reuses a single global element object. This can save a lot of memory when you just need to do quick manipulations of single objects.

// Add a class to the element with ID of 'header'

For the memory saving fly operation, I’ll give the advantage to Ext Core, although they are essentially equal in their DOM selection abilities.

Round 4 – Events

Like the selectors above, there are basically style differences between the two libraries in how they handle basic event use cases. JQuery adds some methods to the jQuery object for registering common events. For example, here is the code to add a click event to a button for each, including the JQuery shortcut:

// JQuery with bind()
$('#myButton').bind('click', function() { alert('Clicked');});
// JQuery with shortcut
$('#myButton').click(function() { alert('Clicked');});
// Ext Core
Ext.fly('myButton').on('click', function() { alert('Clicked');};

JQuery brings some some additional enhancements to the game in the form of “live” events. This provides a way of attaching an event to all current, and future, instances of the selector. JQuery also supports event namespaces, where events can be fired in a hierarchy. Both are powerful concepts, but I’ve never had to use either.

The secret sauce for Ext Core is in extended configuration. With Ext Core events, you can also configure the scope (a common Ext Core theme), along with configuring the event propagation, extra parameters, and a delay. Here is a sample of a click event configured with ‘this’ scoped to the onClick event itself, to only fire once (single), with a delay of 100ms and an additional parameter (forumId) to be passed to the event handler:

el.on('click', this.onClick, this, {
    single: true,
    delay: 100,
    forumId: 4

So again, I’m going to call this round a tie. Both libraries handle simple event binding very easily. If you need the live events, the nod goes to JQuery. If you need the extra configuration options, Ext Core is your best bet.

Round 5 – DOM Manipulation

Once again, the two libraries provide a near complete overlap of basic DOM manipulation functionality. Each can easily create, move, add and insert DOM elements.

JQuery aims for convenience. For example, one feature of JQuery I really appreciate are simple methods to clear the content of a DOM element and set the text. For example, given:

First Message

With JQuery, it is simple to update the text:

$('#message').text('New Message');

The text() method removes all the child nodes of the matching elements and appends a text node containing the specified text. The text() method without a parameter will retrieve the text for a matching element. For Ext Core, you have to drop down to the DOM to set the new text value:

Ext.fly('secret').dom.innerHTML = 'New Message';

The Ext.Element class does not provide simple methods for setting the text or removing all the children of an element, which I find to be an annoying inconsistency.

On the plus side, Ext Core provides a lot more methods for manipulating the DOM. One of the cool ones is the radioClass() method. This method will add a class or classes to an element and remove that same class (or classes) from all the siblings. For example, here is a simple table with a row having the ‘selected’ class:


This one line of Ext Core code will remove the ‘selected’ class from the current TR element and add it to the first row in the table:

Ext.select('table tr:first').radioClass('selected');

So for this round, I’ll give the advantage to JQuery for the more consistent API, especially around manipulating the text nodes of an element. This is something pretty simple for Ext Core to address, which they really should. Ext Core does, however, offer more powerful DOM manipulation options.

Round 6 – Effects

I’m not a big effects junkie, so I won’t have a lot to say about this. Both Ext Core and JQuery provide a very similar set of effects for elements (hide/show, fade, slideIn/Out, etc…). Ext Core provide a more powerful API for creating custom effects, while JQuery addresses this with its rather extensive set of plug-ins. I’m calling this one a tie.

Round 7 – AJAX

Ext Core and JQuery both make AJAX simple, but again, we’ll see that JQuery adds more simplified methods while Ext Core offers more powerful configuration. Here is a sample of an AJAX call that returns JSON data:

// URL returns a JSON object like this: {name: 'Tim'}

// JQuery 
$.getJSON('http://myurl', function(data) {alert(data.name);});
// Ext Core
    url: 'http://myurl', 
    success: function(response) {
        var data = Ext.decode(response.responseText);

JQuery provides the simplified getJSON() method where the parameter to the callback has already been decoded into a JSON object. For Ext Core, the callback receives the XHR response object and you have to decode the text to JSON.

The Ext Core request() method demonstrates a typical ExtJS convention of using a JavaScript configuration object as a parameter instead of using multiple parameters.

Both libraries provide strong AJAX support, so we’ll go with a tie for this round too.

Round 8 – Documentation

There is no contest in the documentation department. While the JQuery documentation has improved, the Ext Core documentation blows it away. From the excellent manual to the high-quality API documentation, Ext Core sets the standard for what all documentation should look like.

Round 9 – Intangibles

For JQuery, the biggest intangibles are its plugins and support from Microsoft. JQuery is intentionally designed to provide a simple core set of functionality and to be easy to extend. There are hundreds of plugins people have written for JQuery in the Plugin Repository. As with all things open source, some are very good and some are kinda crappy, but you can be pretty certain to find a plugin that covers about anything you might be trying to do that is not covered by the core JQuery API.

Microsoft support is also a biggie. They have decided to include JQuery as a base JavaScript library in their web tools going forward. This means you won’t need to get special blessings to use JQuery in large corporate environments — it will be part of the core Microsoft bundle, with support and all.

Ext Core, being brand new, is lacking in both community and support. Ext LLC, the company behind ExtJS and Ext Core is a small software shop trying to get by in a tough economy. While their products are cutting edge, I’m expecting them to be bought out by a larger company before too long. I keep trying to talk my Spring Source contacts into buying them, but I have a feeling they’ll be bought by Adobe.

So from an intangibles perspective, JQuery is the winner. It is guaranteed to have longer legs under it, at least until we see where Ext LLC ends up.


Both Ext Core and JQuery are solid, complete base JavaScript libraries. JQuery leans towards simplicity while Ext Core offers enhanced configuration. The choice of which to use will come down to where you are now.

  • If you use JQuery, and don’t anticipate using ExtJS, stay where you are. You’ve got a winner.
  • If you use ExtJS and have used JQuery as a light weight option for when you didn’t need the widget library, Ext Core is now your library of choice.
  • If you are in search of a JavaScript library, the choice is tougher. Unless there is a particular JQuery plugin you want to use, I recommend going with Ext Core. It starts laying the groundwork for using ExtJS, which you’ll want to do as you get in to building RIAs.
  • If you’re a corporate Microsoft shop, you probably don’t have a choice. JQuery is now something you can slip by the infosec police without making waves.

Ext Core is definitely a winner. In the past, I have used JQuery for projects that need simple DOM manipulation and ExtJS for when I need the widgets, layouts, etc… Now that I have Ext Core, I don’t see using JQuery anymore for the simple cases. I can standardize on using the same API paradigm between Ext Core and ExtJS.

Follow-up #1: Beyond the Core
Follow-up #2: Slick Speed

JQuery…. in action

We finally started a somewhat meaty RIA-ish project at work. My original intent was to use ExtJS for the bling, but it wasn’t through the corporate approval process and the available themes didn’t match the desired corporate color scheme. So instead of ExtJS, we’re using JQuery UI 1.5.

So far, I’ve been extremely impressed. It does not have near the number of UI widgets that ExtJS has, but I haven’t needed them for this web project. One of the most impressive things about JQuery UI is how easy it is to theme. Some silly-smart folks over at Filament Group created an on-line theming engine for JQuery UI called ThemeRoller. With ThemeRoller, I can specify the RGB values to exactly match the desired corporate color scheme and even add some cool effects. There is also a great blog post on how to use the ThemeRoller theme to create your own components.

I still like ExtJS, but I think JQuery and JQuery UI are really starting to get a lot of traction. The ability to create custom tailored themes is pretty huge for corporate and custom development, and right now, JQuery has the leg up on ExtJS in this space.

Flash in the Pan

Apple Insider is running a very interesting series of articles about Adobe Flash and its future. The first article in the Flash Wars series covered the history of Flash. The second part jumps in to all the hurdles and competitors Flash faces, from Microsoft to Apple.

I sat in on most the Flex track at Dallas TechFest, and it is an interesting technology. But I also share the same opinion as the author of the AppleInsider artice — Flash/Flex has a rough road ahead of it. One of the biggest points that I think a lot of folks won’t notice in the article is the suggestion that open standards are a competitor to Flex. By open standards, they mean Ajax, JavaScript, CSS and HTML. I reached the same conclusing after playing with some of the first-rate JavaScript libraries out there like JQuery and ExtJS.

ExtJS, in particular, can do about everything Flex can do, and do it without a browser plug-in. It also has APIs around the non-visual aspect of applications that put Flex to shame. Although ExtJS has licensing issues which I’ve griped about before, if you accept it at face value as a commercial product, it really is the best thing going right now for building RIAs.