Why I didn’t switch from jQuery to ExtJS after all
Posted on | June 4, 2008 | 19 Comments
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
Tags: Extjs > Javascript > Jquery > Programming > webdev
Comments
19 Responses to “Why I didn’t switch from jQuery to ExtJS after all”
Leave a Reply
June 5th, 2008 @ 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.
June 5th, 2008 @ 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
June 5th, 2008 @ 7:58 am
Apples to oranges it is. The APIs have completely different purposes.
June 5th, 2008 @ 8:17 am
I agree with that. It just so happens that I need apples much more often than I need oranges.
?June 6th, 2008 @ 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
June 8th, 2008 @ 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.
June 18th, 2008 @ 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.
June 19th, 2008 @ 4:53 am
simple speaking, Extjs is a OO framwork that good for maintain, and other js framwork, just more like script
June 20th, 2008 @ 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!
October 21st, 2008 @ 10:21 pm
Nice article!
For 90% of my projects, jQuery is the best fit. Ext is an overkill. But sometimes, I do feel I should have switched to Ext (when I need super duper grids or controls and can’t find any jQuery plugin for it). But that’s only once in a blue moon.
Since most of our development is in .Net, and ever since Microsoft embraced jQuery, its game over for Ext.
I am glad I never switched from jQuery to Ext.
For those who have been living on Mars:
http://jquery.com/blog/2008/09/28/jquery-microsoft-nokia/
October 27th, 2008 @ 5:23 pm
Why couldn’t they both be used on a single site. Lets say, for example, the public facing site needs a light UI/Ajax abilities but the backend used by internal employees for adminstration, etc… was done using ExtJS…
Apples and Oranges can still fit in a single basket
November 6th, 2008 @ 11:21 am
Cool, …
Good analysis, Size is the biggest problem.
Please keep on blogging on such issues
November 25th, 2008 @ 4:38 am
Great decision, I think size is truly important for the first impression of the customer.
Is nice to have the ext widgets, but the licence is a piece of crap (extjs truly deserve to be paid).
December 8th, 2008 @ 11:07 am
Thanks for the comparison and posts. I’m rather new hacking in jquery but stumbled on Extjs. So I rebuilt our UI based on Ext for a spin. My take is that jquery more elegant and easier to learn. Weight being the final nail in the coffin for Ext, I took the same roller-coaster ride and I’m back to jquery now.
December 14th, 2008 @ 10:51 pm
Funny, I was sort of in the same process as you. ExtJS really looks wonderful but in the end the license made me decide we could not use it.
Even if you pay for the commercial license it just gives a lot of license hassle. If you open source it and other people contribute to it, you can also pay up, at least if you do want a more free license for your software or not be screwed later if you use it under a different license.
February 15th, 2009 @ 2:01 pm
The grid is one of the HUGE differentiators between extjs and other frameworks. My company is developing a corporate ASP.NET site, and we’d love to use one of the “pretty” ASP.NET control frameworks, but their grids just cannot come close to Extjs’s excel-like grid (particularly for editing).
I’d love to use jQuery instead, particularly since ASP.NET supports jQuery, but there’s not a single extension to jQuery that comes close (jqGrid is still WAY too buggy).
For consumer apps, an excel-like editable grid may not be a big deal, but corporate applications and b2b apps use grids heavily. For some reason there just aren’t many options to address these needs, and most corporations end up spending big $$$ to roll their own.
November 24th, 2009 @ 5:05 am
Let me comment on your 4 reasons:
Purpose: Extjs does much much more that JQery. If all you need is DOM manipulation, you should check out Extjs-Core, which is much more tailored to your specific needs.
Licence
Ext-Core is GPL, I think
Size
Ext-Core is small and fast
Familiarity
Of course you have to get used to the new API. However, Extjs has the BEST documentation I have ever seen in a Javascript library. Actualy it has the best documentation I have ever seen at all in 15 years of software development.
December 1st, 2009 @ 9:12 am
@guest: Ext Core is licensed under an MIT License.
At the time of this post, I don’t think Ext Core was available. You could build a subset of Ext JS, but it would have been licensed under the GPL.
The team over at Ext recently did the smart thing and released a based library under a permissive license to remove the confusion when compared to the other libraries.
The one thing that we started to notice was, the size of the lib is of little consequence.
We came across YUI’s seed, and Dojo’s base, jQuery, and many others. The one thing that stood out was to build an actual web page, we were including many additional “plugins” that increased page weight beyond these “base” libraries.
If you are just adding a behavior to an element then these base libs might be enough. I doubt that’s a webpage worth talking about though.
What we found with Ext Core, is a good balance of functionality that enabled good coding practices, with minimal plugins.
The Core Manual is awesome, as are the API docs. Having a company behind the library also made us feel more comfortable with selecting Ext Core.
Might be worth giving Ext Core another look.
January 24th, 2010 @ 10:21 pm
You have some nice points there.
I used some inputs from your article to create a comparison of my own among the various JavaScript frameworks: http://technoticles.com/2010/01/15/javascript-framework-comparison/