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'td.age').addClass('someclass');

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''header').addClass('someclass');

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'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:'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:'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(;});
// 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

38 thoughts on “New Kid on the Block”

  1. Hello Tim,

    Thanks for writing up this great comparison so quickly! I think you managed to point out the differences very well. Ext Core aims to give you great flexibility by giving you full control over configuration.

    Regarding the .text() method, Ext Core provides a convenience method for this aswell. Its called .update().‘some-el-id’).update(‘New innerHTML contents’);

    I also think that one of the bigger advantages of Ext Core over jQuery, is the OO structured code it helps you to write. Just open up a Ext Core example and compare the readability (and maintainability) to a typical jQuery plugin.

    Kinds regards,
    Tommy Maintz

  2. Thanks, Tommy. I’ve used update() with the regular ExtJS, but was surprised to not see it in the API docs for Ext Core. Since I know you’ve been shuffling around classes to still keep some secret sauce, I wasn’t sure this made it in. Add this to the list of fixes for the documentation.

    There is still not a API method to return the text contents or clear child nodes like JQuery’s empty() method. Those would be nice additions.

    I agree on the OO advantage. I really appreciate the solid OO concepts Ext puts in to place.

  3. Although you are only comparing equivalent features of the two libraries and left out the OO aspect of Ext Core, you’ve laid it out quite well. Good job. I also noticed that the documentation is not complete. Some class members are returned by the search but not listed when you open that class. However since this release of Ext Core is announced as beta I expect changes and improvements.

  4. Thanks, Eugene. Ext Core definitely has stronger OO functionality, but it wouldn’t be fair to pummel JQuery for a less OO approach since I think the typical use cases for each library are pretty straight forward and a lot of users won’t even get in to the OO.

    The documentation has some holes. If you find things, there is a forum thread over at the ExtJS Forums you can add them to.

  5. An excellent comparison and certainly something to keep a eye on.

    My question would be, in releasing something new, why they have gone down the route of adding ANOTHER selector engine to the mix, rather than implementing and contributing to John Resig’s MIT-licenced Sizzle engine ( which is used in jQuery (but is not part of jQuery) as well as MochiKit, Prototype and Dojo. I think it would have made more sense in the long run as it allows libs to standardise over the mix of browsers.

  6. Ironically, that was one of first questions that popped in to my head too — does it use Sizzle. I’m sure there was a reason they didn’t use it, and I plan on asking about it at the ExtJS Conference.

  7. Very good comparison. Thank you for spending the time to writing it. I am a big JQuery user and fan.

    Yes, I agree that it would make total sense for Adobe to buy ExtJS. However, it is remain to be seen whether Adobe would adopt an aggressive OpenWeb strategy. Right now, their Web strategy has been mostly focused on the Plugin front (Flash w/ Flex), although AIR does provide a good HTML/AJAX support (thanks to WebKit).

    Also, about Ext Licensing, I would say that while the Ext Core is a friendly open source license, it paves the path for the cancerous one. GPL for AJAX/Client libraries is the most restrictive and convoluted license model you can find. I am surprised that developers uses Ext JS with this license. Even if you plan to buy the commercial version, you always want (IMO) to make sure you can still use the library freely.

  8. Thanks, Jeremy. Yes, an Adobe – ExtLLC shotgun wedding would be interesting. I’ve been a very vocal Flash/Plugin critic. With things like ExtJS, you don’t need plugins to build a good RIA. Where I see the synergy is with Air. You can bring your nicely crafted ExtJS application offline.
    As for ExtJS and the GPL, I got over my feelings on this by just considering ExtJS to be a top-notch commercial library. $289 is dirt cheap for what it buys you and the time it saves you. I bought my license and quit caring about the GPL side of it.

  9. Since you’re just looking at minified versions, have you looked at packed version using Packer? I know that JQuery has a prepackaged packed version that has a mere 17k footprint, can ExtCore be packed successfully that would be a big deal if it couldn’t be.

  10. I ran Ext Core through Packer and it got down to 24K, but would not run. There appears to be a missing semicolon which is hosing it up. The minified version, gzip’d by Apache on the way out, goes down to 27K. By comparison, the JQuery minified version shrinks to 20K with the Apache gzip deflation.
    I’m expecting the Ext Core guys to have everything fixed in the final version, so 24K is probably an accurate number.

  11. Have you looked at doing any speed or memory benchmark comparisons?

    I like the idea of the memory-saving ‘fly’ method. How does this compare to just using a better JS intreperter like V8 or traceMonkey?

    Also, $.ajax( has the same functionality (specify all options as one object) it just has some shortcut function calls that have different option sets enabled, or specify some other callback actions.

    Great post.

  12. Thanks, Issac. I intentionally stayed away from performance because of the rapidly changing landscape. With the constant one-upmanship going on between Chrome, Firefox and WebKit with their JavaScript engines, it is probably safe to say nearly any JavaScript library will perform well in a modern browser. I just wish IE would jump on the bandwagon.
    I didn’t do any memory benchmarking. Conceptually, the flyweight fly() object should make a difference in a large RIA application. For decorating simpler HTML pages which are called via full page refreshed, it probably in inconsequential.

  13. FYI, a few jQuery tips:

    The jQuery ready shortcut:
    $( function() {
    //document ready code

    jQuery’s equivalent to radioClass is toggleClass:

    You can also use the jQuery.Ajax function OO-style, as Ext does:

    Also, if you like jQuery and OO, check out LowPro for jQuery:

    Cheers, and enjoy jQuery! The community will keep it going strong for a long time.

  14. I’ve looked at both and although extJS has more well-defined widgets, the license prohibits their users from developing their own software libraries. IMHO the philosophy and community of jQuery far outweighs any benefit that extJS might provide, regardless of cost.


  15. Cool, Charles. Thanks! One note — radioClass() does more than toggleClass(). It not only toggles the class(es), but it removes the same classes from sibling nodes. Yes, would just be an extra line in JQuery, but pretty cool to shortcut it. I’ll check out LowPro.

  16. I don’t think radioClass() toggles anything. It *adds* the class to the selected element(s) and removes it from sibling elements.

    In jQuery you might implement it something like this:

    jQuery.fn.radioClass = function( cls ) {
    return this;

    (Please don’t tell me your comment system will mangle that!)

    The Ext Core documentation does seem to be well written, but I don’t like that viewer page at all. It is annoying and really gets in the way. I don’t want a fading yellow highlight every time I click a section name. I know I just clicked it! After I click something I want to be able to use the up and down arrow keys to scroll through it. They don’t work unless I then click a second time within the viewer panel. And when I expand several items in the tree on the left, the viewer panel becomes tall enough that the entire page gets a vertical scroll bar. Now I have two scroll bars I have to use: The one in the viewer panel and the one in the page. Good grief.

    The jQuery documentation has its own usability problems: The site redesign a few months ago made everything hard to read for many people including myself, but there is a Stylish sheet that fixes the worst of the problems.

    One other thing that bugs me in the Ext Core doc is the persistent misuse of the word “scope”. JavaScript has something called “scope”, and it is not what the Ext doc uses the word for. Scope in JavaScript refers to the lexical nesting of functions. Ext uses “scope” to describe what the value of “this” is when a function is called. Wrong – and very confusing to someone who knows what scope really means in JavaScript.

  17. @ James: I think you are confusing Ext Core with Ext JS. The former is a core low-level Javascript library released under the permissive MIT license, while the latter is a full-blown RIA development framework released under the GPL license.

    @ Michael: I actually agree that the manual still has some usability issues we will address in the final release. You make some very valid points, and it is great to get some feedback. I still think that in its current state it is a very valuable resource for getting up to speed with Ext Core, and we will keep improving it like we have been doing with the API docs.

    @ Charles: Although you are correct on most points, except for the radioClass being equivalent to toggleClass, I wanted to add that Ext has a very strong community aswell. Ext has over 70k registered community forum members, and over 200,000 developers visit more than 3 times a week.

    Having used jQuery in a project for two years before joining the Ext Team – Ext Core did not exist yet – I came to appreciate a few of the clever stuff that jQuery incorporates. I did have had some bad experiences though trying to scale my jQuery code base because of it becoming hard to understand for colleagues and often even finding it hard to understand mysel what was going on when coming back to change or maintain code.

    I actually wrote a few dozen plugins for jQuery, and because of that I only became more and more appreciative of Ext Core’s elegant coding style when creating the examples. It saved me a lot of time and headaches trying to create the compelling user interactive extensions. I hope it will help you as it did me.

    We released Ext Core as a lightweight library to enhance webpages. A designer wanting to add some dynamic magic to its webpage might be inclined to go for jQuery, while a more serious web developer will probably love Ext Core more because of its more robust and traditional style of coding.

  18. @Tim Fair point about the licensing.

    I am actually a big fan of Flash and been involved with Flex. However, I still think that Adobe could and should have a more aggressive OpenWeb strategy.

    To summarize my view, I think that Flash/Flex model is great for “on client” applications, while the true Web model (HTML/CSS/JavaScript) is better for “on demand” applications.

  19. “Ext Core does, however, offer more powerful DOM manipulation options.”

    Disagree. While I only have direct experience with jQuery, I’d say that, based purely on your examination, I’m pretty unconvinced that Ext’s DOM tricks are better. I’d suggest you look over jQuery’s API further.

    For example, you completely missed that it has a direct equivalent to radioClass:

  20. @Nate: jQuery’s toggleClass() is not the same thing as Ext’s radioClass(). In fact, Ext has a toggleClass() that is just like jQuery’s.

    toggleClass() is like a checkbox: it toggles a classname off or on each time you call it.

    radioClass() is like a group of radio buttons (thus the name): It turns the classname *on* (no toggling) on the selected element(s), and the same classname *off* on all sibling elements.

    See my previous comment for a jQuery implementation of toggleClass().

  21. Ah… And now I see that Charles had already posted a jQuery implemention of radioClass(), complete with a demo page. See his link for more details.

  22. I think this article is little biased towards JQUery. I use ExtJS and JQuery both. But this article is about ExtJs core and Jquery so lets talk about that.

    1) Documentation -> Author said that ExtJS core documentation is far much better than JQuery. This is something I heavily and strongly disagree upon. Jquery documentation have both explanation with an example which ExtJS don’t have. Just having fancy widget does not make it more informational…

    2) DOM Selector -> I think Jquery DOM manipulation is equally as powerful as ExtCore. May be you don’t know that JQuery selector is faster than ExtCore. Checkout for Sizzle

    3) Simplicity -> I think Jquery is much easier to learn than ExtJS. However that does not mean that learning ExtJS is tough.

    Conclusion -> If you use ExtJS then use ExtCore since it is more suitable I think. As you don’t have to learn two framework. If not then you can use JQuery. Jquery is also more stable than ExtCore even though it not like comparing Apple and Apple since ExtCore is still in Beta.

  23. I asked the Ext team about Sizzle at the Ext Conference this past week in Florida. For what it is worth, they said they didn’t use Sizzle because it is too large and too slow. I’ll have to fish around for some benchmarks to see how they really compare.


  24. I’m a Microsoft guy and I totally love ExtJS Core and Full ExtJS. I don’t know Jquery so can’t really comment on that but I love the consistency of ExtJS through their entire stack (right down do the core)

  25. I have use a lot of library out there, this including prototype/scriptaculous, jquery, extjs, yui, dojo, mootools, etc..
    JQuery dom manipulation is very straighforward and simple so it’s for me better than ExtJS. JQuery can do OOP but it’s seem like more like a feature than a base concept.

    ExtJS is OOP base and take inspiration from YUI and Java. So the OOP concept is far stronger than JQuery (guys who know WWT/Swing will almost seem to be at home).

    So in the end, the use of jquery or extjs will be influenced by the need of your project.

    Personnaly, I often use ExtJS (not core) and JQuery as adapter as I can combine simplicity and strong oop, organized widget of extjs and simple standalone widget from jquery strong plugin architecture !

  26. I’ve yet to see any ExtJS implementation that looks beautiful. It’s dry and boring. jQuery, on the other hand, has lent itself to hundreds of visually gorgeous implementations. Art matters.

  27. i have been using Extjs (not core)extensively within last two years. I have been looking at jquery recently and I am disappointed that I can’t find the Extjs Layout Managers in jquery. Yeah, there is a plugin, but forget about embedding any widgets inside..(tons of problems). That’s like 1,2,3 in extjs. And Extjs widgets are beautiful. I thought to myself, yeah i can use jquery with Extjs, but what for. There is nothing missing in Extjs that would make me go over to jquery.

  28. There are more when you consider which of the libraries to use than coding. Speed is also a factor. Availability of plugins and legal things matter, too.

    Personally I would pick jQuery any day over ExtJS. ExtJS Core might be free but once you need to do more, you’ll have to shell out money and accept a restrictive license for the full ExtJS.

    Thanks, but no thanks.

  29. This is the best unbaised blog about Jquery n Ext Js , i have seen so far. I would be happy if you include yui3 also comparing with the above two. So that people will get overall comparison of all the best frameworks on the web.

Leave a Reply

Your email address will not be published. Required fields are marked *