February 4, 2012

Why I didn't switch from jQuery to ExtJS after all

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.

[tags]jquery,extjs[/tags]

Share and Enjoy:
  • services sprite Why I didn't switch from jQuery to ExtJS after all
  • services sprite Why I didn't switch from jQuery to ExtJS after all
  • services sprite Why I didn't switch from jQuery to ExtJS after all
  • services sprite Why I didn't switch from jQuery to ExtJS after all
  • services sprite Why I didn't switch from jQuery to ExtJS after all
  • services sprite Why I didn't switch from jQuery to ExtJS after all
  • services sprite Why I didn't switch from jQuery to ExtJS after all
  • services sprite Why I didn't switch from jQuery to ExtJS after all

Technorati Tags: , , , ,

Related posts:

  1. Why I'm moving from jQuery to ExtJs Update (21 Nov 2008): I changed my mind a few...
  2. Mootools beats jQuery and Ext for AIR When I recently updated an Adobe AIR app I'd written...
  3. Semitransparent rollovers made easy with JQuery I'm continuing to enjoy working with jQuery....
  4. jQuery Selector Magic I've been working on a Drupal module to automatically make...
  5. Enhancing FAQs with jQuery I’m so pleased by how useful and concise jQuery has...

About Bruce Kroeze

Comments

  1. Ovidiu C. says:

    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 says:

    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 says:

    Apples to oranges it is. The APIs have completely different purposes.

  4. Bruce says:

    I agree with that. It just so happens that I need apples much more often than I need oranges.

  5. Ryan Gahl says:

    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. 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 says:

    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 says:

    simple speaking, Extjs is a OO framwork that good for maintain, and other js framwork, just more like script

  9. David Castro says:

    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!

  10. Asheesh Soni says:

    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/

  11. bbqchickenrobot says:

    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 ;)

  12. Ali Loghmani says:

    Cool, …
    Good analysis, Size is the biggest problem.
    Please keep on blogging on such issues

  13. 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).

  14. Samuel Koh says:

    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.

  15. Herman Bos says:

    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.

  16. Josh says:

    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.

  17. Guest says:

    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.

  18. Guest 2 says:

    @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.

  19. Nitin Pande says:

    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/

  20. Chris Dawes says:

    As this comes up in the google results I need to add:

    In 2010…

    1) Extjs Can be implemented on a widget by widget case, and it’s on Google CDN, so load time is once ever.
    2) Extjs Core is smaller than jQuery and has different licencing to Extjs Full so you can include it in all your projects, it’s also a lot faster than jQuery core
    3) There is a jQuery connector so you don’t have to rewrite any of your existsing code, and you can extend it.
    4)

  21. peter w. says:

    jquery= best for internet applications
    extjs = best for intranet (heavyweight applications)

  22. Erik Reppen says:

    Maintainability is everybody’s selling point nowadays so allow me to put few points against EXTJS on that front:

    * In my recent experience with their grid, I got the impression that the devs responsible didn’t know enough about CSS to know that if you find yourself using JS to solve basic layout problems, you should feel bad about yourself professionally.

    * Bad HTML – loads and loads and loads of div wraps with crap-tons of classes and IDs asserting themselves all over the place. (to be fair, the IDs don’t pop in on elements with existing ones).

    * Bad CSS – Widths on multiple wrapped elements with on average 6-8 framework JS-inserted classes make things real fun if you need to make a tweak or minor modification or just stretch something a touch. Oh no. This is ex-Java dev CYA code at its very best. Don’t mess with MY code mister! I wrote it that way for a reason that I of course never documented. Oh and don’t touch the HTML either. And you better stay away from the CSS too.

    * Border-Box! – I did learn something new! You can change the box-sizing model to a border-based one given all the various modern and IE options nowadays. This is actually very useful in places, especially when you want percentages dictating horizontal sizing. I’m not sure it’s very inter-framework-and-stuff-that-was-already-in-place-before-EXTJS-friendly to apply the non-standard border-box sizing model to EVERY SINGLE ELEMENT ON THE PAGE however. Jesus H. That it didn’t even rub their instincts the wrong way to avoid that little issue kind of blows my mind but it smacks of the sort of giant hammer approach to problems that I’ve seen all over the place. Fixed now apparently, but I couldn’t care less. I’m ripping this code out of our site like a bad tooth. The sooner the better. It’s actually less time-consuming to write my own grid than monkey around with this foolishness.

    JQuery = Sonic screwdriver in capable hands. Build anything you want rapidly if you know what you’re doing without ever touching a plug-in.

    ExtJS = Do stuff you’d never though possible if you’re no good at this stuff. Stay very far away if you’re expecting a great deal of customizing or layout finessing no matter who you are.

    And what in ExtJs core is faster than JQ? It’s not like they both do one operation. If you’re going to compare your compact sedan to the Honda Civic it’s helpful to know whether you’re talking about the engine or the ashtrays.

Speak Your Mind

*