Coldfusion 8's Catch 22 - Web 2.0 Widgets
Recently a colleague was lamenting the fact that the rich text editor that ships with CF8 seems to load slowly and have a few other problems that are causing consternation for his users. His exact comment was that he wished Adobe would "fix" or "patch" the FCK editor that underpins the rich text editor. I certainly sympathize with his desire to fix the behavior he is experiencing for his users, but I would hasten to point out that the underlying libraries for FCK editor are not from Adobe. Instead, along with copies other script libraries for Ajax, window behaviors and the like, they are open source libraries - many of them from Yahoo.
Of course this is one of the bugaboos of these new "client side" widgets that ship with Coldfusion 8 and in a way they put Adobe in a difficult position. In CF8, Adobe encapsulated a bunch of cool client side functionality into new tags like cfwindow, cfajax, the rich text editor etc. This is not new for Coldfusion - cfform, cfgrid, etc have been around for since the beginning. The biggest difference is that there is a lot more of them and they are exponentially more capable with the advent of Ajax, binding, and Cfajaxyproxy. In fact, Ajax and Cfajaxproxy really continues the trend of blurring the line between the server and the browser - a trend already in full fury in the Flex world. Adobe is seemingly caught between the two worlds of client and server.
While they have a real "WOW" factor, the heavy reliance on JS in these client side implementations presents a problem. In my view Adobe will now be tasked with rolling code patches more quickly to keep up with browsers - a moving target to be sure. Server administrators who see a vendor issuing a copious number of patches will usually take it as something of a black mark and believe the product to be buggy. In the case of client side code "buggy" might mean IE is buggy or Firefox doesn't handle A B or C or Safari doesn't render X or Y. In other words, the bugs in question may have nothing to do with the server at all. Will Adobe development and QA, who are typically tasked with deploying carefully vetted Server patches for stuff like drivers and nuanced performance issues and the like, now need to roll patches every week to keep up with issues (albeit legitimate issues) of client side code?
Developers laud this blurring of the line between the server and the client. But I'm afraid they will fail to see issues with these implementations as part of the rough and tumble world of multiple browsers, security contexts, script settings and operating systems. Instead, the blame will fall to Adobe - in spite of their best efforts at using open source libraries etc (largely from Yahoo). I would note that this is why Yahoo has no phone number for support and why it is impossible to ever get more than a canned response for the email help system :)
I will say this by way of suggestion. Adobe should separate out builds for client side code from "server patches" and make it clear that some "hot fixes" are really new JS files from open source libraries. If it were me, I would not even call them "hotfixes" (which denotes a server bug in my mind). This will make server administrators breath easier. Since there is now so much of this code that ships with the server, it might be cool to see an update tool in the Admin - something like "update scripts directory from repository". Of course I suspect there are already folks out there who have hacked up that scripts directory to "fix" pet problems with these JS implementations - so that might cause more problems than it solves.
10 Comments
-
Great post. I blogged about this when I first heard about it... I like your idea of splitting the server related patches and the client side stuff. We haven't switched to CF8 yet but I'd be hesitant to use any of these features until Adobe addresses patches. I'd just roll my own using the latest and greatest. -
we should keep this in perspective - Microsoft has exactly the same issues with their ASP.NET web controls.
those ASP.NET coders that has pushed MS's Atlas (Ajax) implementations have given up and gone over to common (non MS) Ajax libraries.
if MS had it's way, we'd be coding for IE only and I hate to say it but they're right - you can't please all the browsers all the time. Pick a winner and hang the rest.
this just highlights (my opinion) we've pushed the browser as far as we can/should go. Time to give up and bypass the whole issue with a different solution - Flex forms being one way - as a way of picking that winner. -
@Mark - Nice post. I can see your thought process here, but I also have to give Adobe it's props. In selecting ExtJS, for the majority of it's components, it chose a proven cross-browser implementation. I think you will see hotfix upgrades to the implementation, at some point, but I think those we'll be rolled in with the other standard updates. Browsers will come, though historically on a much longer life cycle than ColdFusion servers (Centaur appears to be slated for a 2009 release, according to Damon's blog and that recent InfoWorld article), so I don't foresee a mad rush of fixes.
More importantly, and as you kinda mentioned in the cf-talk thread, the developer can (and should) "roll their own" scripts. The cfform elements have never been top of the line, and are typically for the totally novice, the simplest implementations, or for rapid prototyping (read: not final product).
Any application will only be as good as the developer who is writing it. -
Mark,
I see your points up to the following,
"fix" pet problems with these JS implementations ...
It's not "pet problems". It's seriously usability problem. And if I do a lot of critical data processing function including formatting on my own, why should I use ColdFusion in the first place, strongly disagree with Steve's nonsense.
Don -
Don,
Client side side code should not be used for "data processing functions" ... you are talking about maintaining compatibility with clients that you have no control over. Even Yahoo's mail client causes errors for me sometimes and it is a smashingly good web based email client with an editor, chat and tons of functionality.
This is the definition of a Gordian knot Don. As far as why you should use CF in the first place - CF's strengths have nothing to do with Javascript. There's nothing you can do in HTML code on the client that you could not do with JS libraries before hand. CF is just giving you a leg up - putting you on the opponents 20 yard line. But the reason we get the big bucks is taking the ball and running it in.
...so I will just have to say we will agree to disagree :) - and go easy on Steve (and all of my readers). He just has a different view that you are not buying... that's fine - but "nonsense" is a strong word that borders on sophistry. Such discourtesy is not usually seen (or welcome) on my blog. Thanks. -
@Don - It's the difference between designing a web site and developing a web application, totally apples and oranges. I completely agree with Mark, in that a good web application is going to have proper validation at both ends, the client and the server. The server side is the most important, as you (the developer) have no true control over what happens at the client side, the variables your server gets sent may not come from your pretty client side JS at all, but rather manipulated data from Firebug, or elsewhere.
It is not Adobe's responsibility to develop your applications for you, only to give you tools with which to help you become a better developer.
And you guys really have to stop. Only my mother calls me 'Steve'. I wouldn't use my full name at all, but every time I would submit an official query to Macromedia/Adobe/Whoever they would say "Who is this Steve guy?" -
Frankly, while I see some cool factor to the AJAX functionality, I'd be completely happy if it were an optional add-on to CF. Some things should be plugins to CF and I feel that client-side things like cfform flash controls, the AJAX widgety stuff should be removable or optionally installed That being said, I have whipped up some quick ajax apps using these components, out of sheer laziness. -
"I'd be completely happy if it were an optional add-on to CF."
well, now you have the opportunity to drive the CFML platform the way you see it - by contributing to the open-sourced version of BlueDragon... -
Adobe should opensource their cf ajax tag library.
Employ the most helpful people on a cf ajax proxy forum (just like the extJs forums)
The new cfExt ideas at riaForge should get official support.
Finally, there needs to be some 'best practice' advice on the YUI and extJs library upgrades. -
On "data processing functions", it's a loose term. The key point is, either server-side scripting (CF) or client side (js), are all about "data capture, data presentation...". When one says Adobe incorporates YUI etc. open source js libraries for some neat ajax functions then they're releaved of responsibility is like saying, a Ford customer has a problem with the Ford steering wheel, and Ford refers his customer to the steering wheel manufacturers (a third party supplier), then, how about seats? How about mirrors? How about?. Technically yes, the third party suppliers produces the wheel, but on the business side, once the wheel is incorporated into a car, it's FORD's RESPONSIBILITY! Same for Adobe's CF8's new ajax-related features.
Then, we got ego-maniac, do this yourself, do that yourself, have you ever heard of the term, "Opportunity Cost"? No, I'm not saying cf8 should be 100% bug-free, impossible! What I was suggesting/ alluding to, was, to design the integration with a high level of flexibility, not the current one-size-fits-all simple method, one better approach would be, as suggested already, to provide options...
In fairness, I do like the ajax-related features, however, overall-speaking, Adobe employs zillions of second class designers and programmers and first-class sales/marketing professionals. They've certainly got the game right!
Sites to Watch
Aggregators
RSS
