A while back, I wrote an article about why I was switching to ExtJS from jQuery. This remains one of the top ten pages on the site, despite the fact that I never really did switch. Checking it just now, I am certain that it is the most heavily commented article on the site.
The fact is that I started to switch, did a site or two, and then I quickly changed my mind.
There are four reasons I didn’t end up switching from trusty jQuery. Size, familiarity, purpose, and license.
Size
jQuery is just so small. In these days where it feels like everyone has broadband, it is still important to remember that rendering time is important. That initial delay downloading a big framework can make a significant impression on a new visitor.
Familiarity
I already know jQuery. If I forget something, then there is the excellent VisualJQuery reference site for me to quickly get up to speed. In contrast, learning ExtJS felt like wading through molasses.
Not only that, but I have a significant amount of code I’ve already written for jQuery that I use for clients and for projects in development. Converting that code is a waste of my valuable time if I am not adding new functionality.
Purpose
Most of what I use jQuery for is DOM manipulation, and occasionally a few effects. ExtJS is simply overkill. I do not need to use widgets for most clients or projects, so I do not. Instead, the lightweight jQuery lets me dart in, make a few DOM modifications, add a fade or two, and be done with it.
For example, the ExtJS grid is huge and powerful. I admire it. I just don’t need it. Nor do I want to wade through long tutorials to even begin to use it properly, even if I did have a need. In fact, I can’t think of a single client I’ve ever had who had a requirement which would have been a proper fit for that huge/powerful/gorgeous grid.
License
I do not wish to pay for my javascript framework, nor do I want to be forced to GPL it, as is the only other option available to me if I use ExtJS. I like the BSD license we use for Satchmo, and I am certain that we are not planning to change that any time soon.
Some of my projects such as Invisible Castle are private playgrounds. I regularly contribute and blog about various techniques and libraries I develop for the Castle, but I do not wish to GPL the whole thing, nor to show some of the ugly code I play around with on “playground/testing” sites like that. So now I am going to have to go rip ExtJS out of it. Oh well, it is really only using the DOM manipulations and a few effects. No big deal to replace.
I mostly agree with my analysis in the original article, just not the weighting I gave to the points I make above. For my purposes at this time, jQuery is my most valuable Javascript tool.
Technorati Tags: jquery, extjs
9 responses so far ↓
1 Ovidiu C. // Jun 5, 2008 at 4:46 am
You’re comparing apples to oranges. And the license isn’t really that bad. You only pay once per developer. Dual licenses aren’t that uncommon.
2 Rey Bango // Jun 5, 2008 at 7:35 am
We’re happy you’re still with jQuery and we’re here to help. Look forward to seeing you on the mailing list.
Rey
jQuery Team
3 Filipe Sabella // Jun 5, 2008 at 7:58 am
Apples to oranges it is. The APIs have completely different purposes.
4 Bruce // Jun 5, 2008 at 8:17 am
I agree with that. It just so happens that I need apples much more often than I need oranges.
5 Ryan Gahl // Jun 6, 2008 at 1:15 pm
Good article and good points (e.g. “use the better tool for the job”).
We use Extjs a lot, and have to agree that the grid (and other components) are both beautiful and heavy. But as you mention, the types of applications that are typically built with something like Ext are the bigger projects where the entire app is running within a single page context and there are hundreds of screens/flows/dialogs. The robustness offered by the Ext library truly does stand up to those kinds of rigorous requirements.
just my $.02, and nothing particularly new to add - just like Ext
6 vladimir prieto // Jun 8, 2008 at 5:01 am
more than apple and oranges comparison, i see Bruce has given practical points here.
what we can find at the final stage when diciding wich tools are be using, that is, when start coding.
7 Jay Garcia // Jun 18, 2008 at 8:52 am
I’m glad that you found a solution that made you happy :). Ext for me (and my customers) works beautifully in the intranet space. Obviously size is not much of an issue there.
8 Frank // Jun 19, 2008 at 4:53 am
simple speaking, Extjs is a OO framwork that good for maintain, and other js framwork, just more like script
9 David Castro // Jun 20, 2008 at 3:09 pm
Thank you for the follow-up on your original piece. I happened to see the link to this post from one of your other pages, and immediately went to read it, since I’m about to start a project based largely on extjs, and I wanted to see if there were issues with working with it. It sounds like it’s the right tool for my needs, but wasn’t for yours. Thanks again for the followup!
Leave a Comment