Why isn't everything as easy as ColdFusion? It's a loaded and obviously rhetorical question ... loaded because I've been using CF for nearly 15 years (gasp!) and rhetorical for, well, pretty much the same reason.
That might seem an odd way to begin a post on the quandary between using jQuery and ExtJS, two powerful and distinct JavaScript frameworks among the many out there. I've used jQuery for a couple of years now, and ExtJS for about a week, and the differences between the two have painted me into quite a corner, development-wise. And please, don't assume this is another "vs" comparison, because it isn't. I really like jQuery, and in my brief introduction am a bit in awe of ExtJS, but having developed for so long I approach every new framework with a healthy amount of trepidation.
First there is jQuery. Fast, simple, relatively small in footprint and with a healthy set of DOM functionality. Throw in jQuery UI and ThemeRoller and you've got yourself a complete RIA framework. Well, almost. If you are building big and handling a lot of data, you need a grid. jqGrid is pretty sophisticated, and Datatables is nice for displaying and sorting.
Here's the problem, though (and this is where ColdFusion comes in): I now have an OS framework with cores from two different groups (jQuery and jQuery UI), a semi-standard or at least semi-respected theme manager in jQuery UI/Themeroller, and two independent UI components managed by two other individuals. All are variously powerful, but each has it's own approach, and especially in jqGrid/Datatables a completely unique and proprietary data in/data out methodology. So, sitting on the table are four sets of documentation, four sets of functionality, four different ... well, you get the idea. On the server side I have literally built three different end-points to my application, one for general jQuery/JSON communication and one each for DataTables and jqGrid. Ack!
Another issue is the lack of some really crucial foundation elements. Having a core data model in a framework is crucial when building a large RIA. So too is a solid templating model. You don't *have* to use either, but having them will add a consistency that others will recognize and be able to build upon when they step into your application. Now, I'm not putting this on jQuery's shoulders. It isn't necessarily the job or responsibility of jQuery to do this, but in reality I haven't found anything that is core and complete in either case (though big props go out to Ben Nadel and his work on corMVC and his new JTML project, and to those others who have been working on similar projects).
Then there is ExtJS. UI maven, FLEX-ala-JS wonder, builder of UI components you could cut glass on. You could build an empire upon their grid component, templating via containers and XTemplate is a wonder, and its baked in extensibility and data "store" model is a dream.
Ah, but let's not so soon forget the first sentence in this post. The first issue I have with ExtJS is the size. If you are doing UI, you are going to be pushing 700K for the JS library. In a word, Ouch! Second, there are some curious omissions in the framework, such as a baked-in method of drag/drop sorting of DOM objects (which sadly is critical to my current application, and which I love jQuery UI for). Another thing I'm not a really big fan of is the insane number of DOM elements that ExtJS creates. The reason they give is for full cross-browser support, but man! A simple ExtJS three-tab box I created had no fewer that 50 html tags created for it. A three-tab box in jQuery: 12. I really hope that with more ExtJS experience I can reign that in a bit.
And then there is licensing and that small undercurrent of unbridled hatred that some in the FOSS community have for ExtJS. Having come in long after the license-switch fiasco, it is hard to feel animosity towards them. They have a dual GPL 3/commercial license, switched from a formerly and more liberal LGPL license, and that has upset those developers who were caught having to buck up for a commercial license when the switch was made and their software wasn't GPL or GPL-compatible. I'm sure there is much more to it, but even with what I've seen it isn't something I can work up the energy to care about. For criminy sake, a royalty-free commercial license is less than $300! You'd have to be seriously cheap to be doing commercial work that relies upon ExtJS and not want to pay them for the many rounds of improvements and wealth of documentation they supply. Just my opinion, is all, and again I'm new to the ExtJS party so I haven't been soaking in the vitriol of those who got burnt by the change.
Anyway, what I'm seeing here is that in many ways ExtJS is to ColdFusion as jQuery is to PHP. In the former, you have a fairly solid and complete development framework sourced from a single company, with a commercial license and commercial support, but an undercurrent of animosity because you will undoubtedly have to pay for it eventually. In the latter you have a completely open framework guided/governed by a few individuals, with important components contributed by various groups who have likewise variously implemented (or not) the general standards of the community. These are generalizations of course, and yes zealots I'm sure I've upset a few of you with this wide brush, but really it is the generalities that I am examining.
As a CF developer, I'm used to *not* having to hunt for third-party plugins to get things done. I'm also used to *not* having to learn a new methodology every time I need one. ColdFusion by its nature has bred a pureness of consistency and formula, meaning even when I turn to frameworks like FW/1 or ColdBox, or tools like Reactor or ColdSpring, the core and meat of what they do will be governed by the standards of ColdFusion, CFCs and common practices. The lack of that structure in PHP and Perl is why I never liked the former and abandoned the latter. Call me spoiled, but CF allows me a certain lazy comfort that I don't give up easily. It's this laziness that makes me fond of ExtJS, which tries (and so far succeeds) to do everything in one neat package. I like developing plugins and functions with jQuery, but I really like that ExtJS doesn't force me to.
Now (six chapters later) to the title of this blog. I should mention that I have quite easily and successfully merged the two into an application already. It was easy and it worked as expected, but of course there are bound to be complications later on and it added around 100K to my already teeth-gritting 700K library size. They may not necessarily *like* one another, but they do seem to at least tolerate each others' existence on the page.
So, what do I hope to accomplish with this variously introspective and semi-ranting journal, other than to clarify my issue? Well, maybe if I'm lucky some wonderful ExtJS guy (or gal) will say "hey, dummy, you do DOM drag/drop sorting via plugin X". Or, some wise and prophetic jQuery guru will point me towards a really solid ExtJS-style "store" or "Ext.Direct"-type model that I will fall in love with. Probably, though, I've just started another little mini Apple vs. PC-type war that will populated by haters and defenders.
Either way, it was nice to get off my chest.
Apr 30, 2010 at 12:35 PM Hi Grant, thanks for sharing your thoughts on this. I'm the lead developer of Ext JS and thought I'd address a couple of your points.
* On DOM node size you're absolutely right - it's pretty strange to see so many elements. In some cases (such as grids) we have no choice - those elements have to be there or things just won't work cross browser. In other cases (such as TabPanels and Toolbars), we've been able to strip out 90% of the DOM nodes needed to generate the components. These changes will be in Ext JS 4.0 and make these components much faster and more flexible.
* Great insight on the data model - this really does underpin a lot of what makes Ext JS so powerful. Again for 4.x we're making it even better.
* We supply a builder which allows you to create a custom build of Ext JS 3.x (see http://www.extjs.com/products/jsbuilder/), including just the functionality you need. We're also looking at reviving the popular online builder we had in 2.x (see http://www.extjs.com/products/js/build/). One of the nice things about Ext JS is that single-page apps which never need to refresh the page are easy to write, so the file size doesn't make such an impact.
It's always a pleasure to read reasoned, insightful comments like this - hearing about any pain points our developers encounter really helps us to improve. Thanks again.
Apr 30, 2010 at 3:03 PM Nice post. I inherited our back office tools when I joint my current company and had to quickly get my head round the Ext JS framework. It was a very steep learning curve but I quickly became very fond of it and it's the full package for developing rich functional apps. I've never used any of the built in CF UI components like CFGrid as I've seen people get caught out using these and would therefore rather use the original source.
The worst thing about Ext JS though? Reading those forums and seeing just how rude one of their top developers is to newbies. Never ever seen anyone behave like that in the CF community.
Apr 30, 2010 at 4:06 PM This is a very insightful post. I just squarely planted myself in the jQuery camp for a current project. This post is going to make me look at corMVC this weekend and try Ext JS on my next project. Thanks again.
Apr 30, 2010 at 6:18 PM @David Cooke
I'm totally agree with this point: "The worst thing about Ext JS though? Reading those forums and seeing just how rude one of their top developers is to newbies."
On one of his Post, he pointed an Extjs beginner (obviously not an js ninja) to an awful ECMAscript page which was one of the less user friendly page i had ever seen.
Somehow, the Extjs forum is full of very interesting dicussion and approach for similar tasks.
Not to mention that the frawework is a real pleasure to work with.
May 1, 2010 at 12:52 PM @Ed, thanks for the input and response. As to library size, that will remain a concern as often components are a mixin with regular HTML forms, so hopefully a very selective library would remain small enough to load repeatedly. As always, this is part of the equation of usability/functionality/performance that has to be resolved for every part of an application.
@David I must say, as a person who has worked through many an issue via support forums, I'm not too surprised. While I don't appreciate or condone somebody being vain or demeaning or dismissive when responding to a thread (the core of any successful community is respect), and while I haven't come across the kind of replies you are talking about in the ExtJS forums (yet, I'll take your word that they are there), I will say I at least understand where they might come from.
As a developer I've always felt responsible for a) attempting to resolve the issue on my own, b) understanding the question that I'm asking and c) expect that any answer I am given is merely a starting point to knowledge, not a direct resolution to my problem. Too often I see questions in forums that have been asked and answered 1000 times before, reveal that the author has put no effort into learning how to do something, or worst of all is in the "please do my work for me" vein. Newbie or not, if you are looking for help in *any* support forum you'll have to develop a thick hide pretty quickly if you are not respecting these three rules. I say this as a complete ExtJS newbie with many questions that will all go through the above process.
As a matter of perspective, I'd suggest reading a blog entry I stumbled upon during my early research on ExtJS: http://blog.extjs.eu/know-how/writing-a-big-application-in-ext-part-2/ (disclaimer: if we happen to be talking about the same guy, it is pure coincidence as I have absolutely no idea who @David's "programmer X" is).
May 1, 2010 at 1:28 PM Good post.
I've used ExtJS since vesion 0.33 and have always played with different configurations (js builder) due to the size of the library. But for the last year or so, I've decided to configure our web servers to better deliver the entire library. Gzipping and caching (today + 2 years) are the primary methods used.
Here are our over the wire filesizes for version 3.1.1:
resources/css/ext-all.css 21.5KB
adapter/ext/ext-base.js 12.1KB
ext-all.js 175.8KB
Other assets like backgrounds, sprites, etc. are loaded as needed and cached by the browser as well.
May 1, 2010 at 2:47 PM @Claude a valid and handy point to keep in mind.
There are a few caveats, though. One, that to a certain degree it just transfers the performance from download speed to client decryption time (though undoubtedly the latter is a much better situation).
The second is that this would generally only apply to hosted applications. If you use ExtJS in a distributed application, users would have make sure their server was configured to gzip the files as well.
One thing I like about Apache is this how easily it can be configured to do this. There's a good discussion on this topic at http://www.extjs.com/forum/showthread.php?1257-gzip-JS-and-CSS-files. It's also important to note that 'caching' is a very important part of the equation; the last thing you want is the web server gzip'ing every mylargefile.js request!
May 1, 2010 at 5:28 PM You're right Grant, caching is key in this setup as it gives the appearance of speed on subsequent requests and also reduces server load, from traffic and compression.
I would not recommend anyone use the software based solutions discussed on the forum thread you mentioned. Instead they should stick with a reliable server platform like Apache and fine tune it for performance. Steve Souders books on performance are great aids, http://stevesouders.com/
May 1, 2010 at 9:51 PM -to David Cooke and Grant about the rude poster on the extjs forum;
I agree with your comment Grant about people asking questions that have been asked 100X times. I can understand the frustration of someone who might admins and answers questions on those types of site being frustrated. However this is not like that...
There might be more than one poster like that on the extjs forums, but I suspect that David is referring to Animal. While Animal may be smart and capable, he goes out of his way to be belligerent and abusive to posters, including noobs. I'll keep my animosity to a minimum, but I felt compelled to post here after reading David's comment. I appreciated that I was not the only one who had noticed. This guy is particularly rude, even by the typical standards of technology forums posting boards.
I enjoyed your blog post - having used both I think you covered a lot of ground. I wholeheartedly agree with your comment about the developer licensing. While so many of us in the dev community are used to getting things for free, the $300 strikes me as a small price to pay for all the tools extjs provides and the work they have done. Using it can mean less time writing code and the ROI (return on investment) in time saved can ultimately make buying the license a worthwhile investment.
Still I favor using jQuery - I think using extjs for a complete single page web based application makes a lot of sense. However incorporating it into a multipage website has been (for me anyway) difficult. Once you do something out of the ordinary with extjs, customizing it in way not covered in the documentation or a book, it can be a real challenge, and rather frustrating. The windows UI styling by default is not designer friendly either.
I have only thing to add - Firefox is my browser of choice, and with it firebug. While I generally love Firefox and it's plugins, the memory management and garbage collection is poor. Coupled with running firebug and the size of the extjs library, and with all the stuff that extjs does in the background, I've seen my computer slow down significantly when using an extjs webpage, especially if it is in more than one page and reloads the library for each page. While most of your potential users don't use firebug, most of them don't have a 2.4ghz chip and 4GB of RAM (which I do).
The memory consumed in processes (in Windows XP) when using extjs routinely exceeds 300K, and on at least 4 occasions in the past has exceeded 1 million K - that is not a typo or a joke. The only way to resolve it is to shut down and reopen firefox. Just be congnizant of what you use it for and the potential problems your client might run into if you opt for using extjs.
May 2, 2010 at 3:05 AM Hi,
nice points that you mention. We are using extjs for some corporate applications because the huge amount of examples make it easy for the lesser skilled developers in our team to deliver nice UIs. BUT in my opinion Dojo is a much better choice for corporate applications because your old code will never stop working in new dojo releases (some of our devs had that with extjs a couple of times) and more importantly there is much more corporate manpower behind Dojo (especially IBM) - if you look at extjs: one car-accident and extjs could be history.
May 2, 2010 at 11:18 AM @Palmer for me FireBug is strictly a debug and development tool, not something I'd leave open while browsing the web. I don't really see this as a ExtJS-specific issue since any js- or DOM-heavy site (Slashdot, CNN, etc.) could potentially fubar Firefox via FireBug. My only real issue here comes when trying to examine a big ExtJS app using FireBug, wherein I have no choice but to suffer the impact.
@Mario, I was amused the thinly veiled "lesser skilled developers" dig. I suppose I could then turn this around into saying "it takes a seasoned developer to deliver a nice UI in Dojo", then? Backwards compatibility is definitely something worth considering, though, and I'll keep an eye out for that.
May 2, 2010 at 2:44 PM @Grant The stuff on extjs.eu is great and has been very useful for people writing their 2.x and 3.x applications. In 4.x we are aiming to provide much more help in getting started, right out of the box.
@Mario our policies on backwards-compatibility have been vastly improved; we do a lot of work between minor and patch releases to make sure that there are no incompatibilities. The car you are referring to would have to be big enough to carry a large number of people - this product is hardly a one man show any more.
May 2, 2010 at 6:02 PM I can sing praises for the ExtJS guys all day, as they made some complex UI decisions very easy for me. But if I had to sum it up in a sentence, I'd say that the Ext guys are VERY considerate people, who obviously are happy loving caring people. I've rarely worked with an API that besides being very well documented, was also so straight forward you rarely needed documentation. What makes sense, usually works even when customizing functionality out of the box.
May 3, 2010 at 11:04 AM @Grant
Nice post and very informative. I am very much like yourself; a CF developer for 11+ years and couple of months back started learning/using ExtJS. After initial stiff learning curve, it has been very smooth ride all along. Excellent API documentation + online Examples + a Book combination is all you need to effectively use this tool.
Many times a day, I just wonder how I would feel going back to HTML only coding.
Now, My CF applications are just lean REST call CFC methods being called by ColdFusion pages. No additional CF framework required. And my CF code is very minimal and can be easily switched with any server side call which can return same JSON data.
Regarding Firebug, I had the similar issue about performance and eventually found the Chrome browser's Developer tools (ctrl+shift+I). The layout is quite different and took me some time to get used to it but now I don't open firefox at all. The JS performance of Chrome is much better and I get all the functionalities of Firebug. It also has timeline & perforamance stats. Try once and you would believe me.
Again, thanks for posting your thoughts, which is very much like reading my own thoughts about ExtJS & comparing with other JS frameworks.
May 4, 2010 at 2:58 AM If you are referring to Animal I must say that whilst he is a little bit lacking in tact, he has an unrivalled grasp of Ext and contributes an enormous amount of his time to helping people.
And, unless I'm mistaken, he isn't a developer of Ext (although alot of his bug fixes and change suggestions have been incorporated into the framework over the years).