Thoughts On Ajax Frameworks And ColdFusion/Adobe
A reader (ironically named Todd) commented on my post yesterday:
I'd also like to see some discussion about Ext vs. Spry.Dreamweaver CS3 seems to have settled on Spry while CF8 has settled on Ext (1.0). Apparently, Adobe divisions do not talk to each other.
I can't decide between them. I find Ext (at least teh 1.0 version used in CF) to be difficult and frustrating to use. Prototype.js was easy. I haven't yet tried Spry.
RSS
The bottom line is that Spry is already incredibly simple to use in Dreamweaver. We couldn't make it any easier with CF. On the other hand, we saw an opportunity to make Ext JS alot easier to use.
ColdFusion 8 does offer native support for Spry datasets with <cfsprydataset> so you can easily work with CF queries in Spry.
I asked for "discussion" because I'm totally unfamiliar with Spry. I have deliverables to deliver and don't have tremendous amounts of time to research the hundreds of packages out there to find exactly the right one. Nor do I have the time (nor will my clients pay for the time) for me to roll my own. Hence the question.
I know Dreamweaver is not a ColdFusion product, but it is an Adobe product, and as Adobe claims to be a company with a goal of making all their products into a seamless suite, I thought I'd take them at their word. Part of being a seamless suite is actually being aware of the other products. If that's not the case, they shouldn't claim it. I pay a boatload for these products and that part of the value I expect in paying these prices.
<asside>
I take great exception to Adobe's claim that their customers are not cost constrained (or whatever the exact words were.
</asside>
I know there are always issues with timing in the release of products: trying to get the right versions compatible with each other, especially w/r/t documentation.
<asside>
Dreamweaver's Coldfusion documentation seems to have had no QA done on it whatsoever. CF8's documentation has had precious little, and the search function is now completely missing. A huge step backwards, making it far less useful that CF7 docs. Thanks the goddesses for http://www.coldfusiondocs.com/app/
</asside>
But back to Ext.
I've had lots of problems with it and have given up on various aspects as I've just been unable to get them to work. Apart from the fact that the various includes can swell the page size to unconscionable levels, the CF application framework seems to throw a curve ball at Ext in some cases and prevents it from working in any way at all. Specifically, using <cfajaximport> together with <cf$ajaxy_whatever> can fail (and possibly direct inclusion of Ext components not included in <cf$whatever>), and fail in a silent, undebugable way.
You ask: "Why wouldn't you expose developers writing PHP, ASP, etc to your Ajax framework?" The answer you give is, obviously, the right one. But that's the wrong question. The real question is why would you (DW, an Adobe) not support the other framework upon which CF8 (another Adobe product) has settled on? Additionally, that is, not in lieu of. Even if it's an Extension. I mean, if you can handle CF and PHP and JSP and ASP and ActionScript, &c, surely you can handle the two AJAX frameworks used in the two Adobe products.
Dan Vega: You /have/ to pick a side for a project. Ext/YUI can add 150k+ to a page. At that size, you can't include more than one framework and have the site usable. I'm not trying to determine whether one is canonically better than another, I'm trying to determine whether one is better than another /for a specific application/ without spending tens of thousands of dollars in client money trying to decide. I need to rely on others to help make that determination. There's a whole industry built around that (ask Ben Forta). If you were not to decide on one over another, the obvious extension of that would be to write some pages of your application in CF, others in PHP, and others in Python, and so on. That's just crazy talk.
Andrew Powell: Yes: "settled on." I was unaware the DW people developed Spry. But that's orthogonal to the issue. Regardless of who developed it, DW settled on Spry. Fact. Full stop. DW is for both designers AND developers. There are even two supplied "Workspace Layouts", so clearly, it's not /just/ for use by non-coding designers.
Adrock: I'd totally forgotten about <cfspry...>. Thanks.
I guess the biggest question I've been unable to find an answer for deals with upgrading the framework. It seems to me any Ext update has to come from Adobe through a CF upgrade. Surely one can't just drop the 2.0 js files on top of the 1.0 ones (or specify a directory containing 2.0 with the scriptSrc= parameter) and have it "just work". If it does, let me know and I'll have your baby!
As for your last statement - as flattered as I am at your offer I think I'll pass on the 'having my baby' thing, but I just tested this and it worked. Copy /CFIDE/Scripts/ajax to a test directory, replace the Ext folder with the contents of Ext 2.0 and run the following code:
<cfajaximport scriptsrc="/test8/misc/testExt2/">
<cfsavecontent variable="stylesheet">
<link href="ajax/ext/resources/css/xtheme-aero.css" rel="stylesheet" type="text/css">
</cfsavecontent>
<cfhtmlhead text="#stylesheet#" />
<cflayout type="border" name="borderLayout">
<cflayoutarea position="left" size="250" closable="true" collapsible="true">
left
</cflayoutarea>
<cflayoutarea position="center">
center
</cflayoutarea>
</cflayout>
<cfwindow name="win" initShow="true" title="test win" center="true" closable="true">testwin</cfwindow>
It "just works"...
Now I'm sure there are some bits that are broken, but if you really want Ext 2.0, as I said above you do have other options. Hell, even the GWT/Ext2.0 bits could be taken advantage of with CF (since it's all Java).
"The Spry framework for Ajax is a JavaScript library that provides easy-to-use yet powerful Ajax functionality that allows designers to build pages that provide a richer experience for their users. It is designed to take the complexity out of Ajax and allow designers to easily create Web 2.0 pages."
I don't know about you, but that makes it pretty clear to me who they are aiming at.
You can easily, as TS has shown, upgrade any of the frameworks. Is it the vendor's responsibility to keep on the bleeding edge of technology? I would say no. I think that a new revision to Ext or Spry should only be added after thorough testing and proof that existing implementations will not break. There's no need to upgrade for the sake having the latest and greatest.
Granted, I do think that the way that cfsprydataset has been implemented leaves much to be desired (very bloated and lots of unnecessary code). However, the goal is bringing AJAX to the server-side developer who does not have the JS skills to do it by hand in the views. With that in mind, I think there have to be some trade-offs (bloated implementations, etc) when looking for the middle ground as a vendor. Those that don't want to use the built in implementations and want it to be lean and mean will do so by hand. Those who are not as comfortable have the option to let CF do the heavy lifting. There are always trade-offs if you want someone else to do the work for you.
At my 9-to-5 job, I don't have access to Dreamweaver, so I learned jQuery, because I needed to manipulate data. I fell in love with it because I could write my own plug-ins. I think this is why moo-tools, jQuery, ext, etc. have done well with the developer/programmers.
On the other hand, I've shown designers the "simple" jQuery/ext/etc code, and they freak. I don't think they would do that so much with Spry.
And, no, it's not the vendor's responsibility to maintain the bleeding edge. That said, Macromedia didn't have the greatest record for keeping up with bug fixes, &c., and my experience with Adobe is that they're even worse (I'm looking at YOU <cfdocument>). But I'm willing to be convinced otherwise.
I guess what I'm really saying is that as both of these products are for rapid application development, lots of the "rapid" is immediately useless if one wants to keep abreast of things. Like, if I want to use <cfwindow> or whatever, I then have /no alternative/ than to wait for Adobe to fix a bug (assuming there is one) or update the thing. (I mean, it was almost 3 YEARS between CF7 and CF8.) That leads me to believe that it's not worth the risk of using any of the CF ajax taqs.
I mean, at least with a third party package, I can update the package independently of CF. And if I pick the right 3d party package, I can get the source code and fix any problems myself. (Assuming I'm good enough to do it!) :>
But it's a HUGE thing to have it built right into the framework. That makes my application development really, really rapid. I mean, <cftooltip> alone has save me all kinds of time. But the minute I use it, I'm tied to Ext/YUI 1.0. That makes me a little uncomfortable.
When I started this, as I say, I was just looking for some insight into when to use which package when. Like, "spry is good for large data intensive things", or "Ext is great for whizbang interactivity" or, you know, whatever. That's all.
I know you don't need DW to use Spry. But I do use DW, and Spry is built in, so it's an implied endorsement. I like to use endorsed products whenever possible as at least they've been vetted.
That said, I've used others. mxAjax for one. Prototype.js, for another. It depends.
I use DW because I've used it for a long time and I'm comfortable with it. It's what my clients use (at least those that use anything at all) and other clients use Contribute, which integrates well (for certain definitions of "well") with DW.
The project management and the proofing tools are nice as well. I mean I've got (counting...) 38 total project of which about 20 are on-going that I need to keep track of. It works reasonably well and integrates with the other products in the suite to an acceptable degree. And CS3 is an improvement over previous versions.
But this is about CF, so I'll shut up about that.
walter wimberly | 2/13/08 5:55 PM:
Thanks, that's the kind of insight I'm looking for!
"Quite simply, the ColdFusion 8 Ajaxy UI components give you a very easy way to roll dynamic, powerful UI."
I pushed out a full ajax UI the other week very quickly and easily.
"Ext/YUI can add 150k+ to a page. At that size, you can't include more than one framework and have the site usable."
I think you need to clarify this statement. This is totally based on your target audience. Ext's biggest benefit is the desktop-like feel and rest-assured that the people that are using it not only use Ext but other JS libs as well, and do so effectively. The key is the target audience. How do I know this? Because I'm part of the Ext team and I chat with our users daily. I know what's being built and where the limitations are.
I also benefit from being part of the jQuery project and seeing how that fits into consumer-facing sites which need to smaller file size to ensure good performance upon initial page views.
So i think your original statement was just a little too broad.
Finally, if you've had problems with Ext, could you clarify if you've had problems w/ the library itself or integrating other libs within CF's implementation of Ext? There's a critical distinction here as CF loads much more than Ext when using the CF8 tags
@Todd Sharp: I just want to caution users with simply dropping Ext 2.0 into the CF ajax folder. Ext 2.0 has some big differences in the API and in my discussions with Adobe, they've made it clear that upgrading isn't possible. With that said, you can always risk it to see what happens.
Bottom line - if you wan't 2.0 and all the good/bad/indifferent that comes with it - roll ya own...agreed?