The ColdFusion 8 AJAX Components Debate
A debate rages on across the ColdFusion development community about the inclusion, and use, of the AJAX driven components and accompanying tags that have been included in the Beta Release of ColdFusion 8. Many examples of their use and benefit have already been posted by the likes of Ray Camden, Ben Nadel, and Ben Forta. No surprise there, as they all are huge proponents of the product, and, like so many of us, are very excited about the upcoming release of our favorite web programming platform.
But there are others still that think that the inclusion of these tags and components don't necessarily belong in the core language set of CFML. Many of these folks are also diehard JavaScripters, who took up writing AJAX early in it's infancy, fashioned their own components, or even contribute to open source libraries like JQuery. They argue that maybe the tags should have been separate CFCs available through the Adobe Developer's Exchange, or that the JavaScript rendered by the ColdFusion engine is too fat, taking up unnecessary bandwidth.
Can't we all just get along?
I, too, love many of these third party JavaScript libraries. I am a huge proponent of JQuery, including it by default in every project. Currently I am running a multi-part tutorial on creating a paging DataGrid using Jack Slocum's ExtJS UI library. I think that using these libraries, or others like them, is the smart thing to do. Not having to reinvent the wheel. Giving developers the ability to create sharp, interactive, and creative user experiences. And I got very excited when I saw that Adobe had created tags for implementing components like these, using the ExtJS UI library for the majority of the components.
"But the scripts are too fat! Why aren't they compressed? They're to big! They take up so much space and bandwidth!" Yes, they do. But I think some people are missing the point as well.
When was the last time you used cfform? Many experienced developers stopped using it years ago, instead rolling their own JavaScript client side validation and ColdFusion server side validation. Rolling our own gave us more control, and allowed us to get more creative, writing our own custom controls (or using someone else's). Some of us learned what to do, and what not to do, by reading through the Macromedia included scripts. The point was, we could use it if we wanted. Have a quick project with no budget? Use cfform instead of writing your own validation. Saves you some time. Quickly prototyping an application for a client? Use cfform. Give them enough to say "I like it, but I want it to do this too," and get them to pony up the dough to spend the time to write it right.
ColdFusion is the language for "Making the hard things easy." The primary focus hasn't changed, it's just gotten an overdue facelift. The same arguments still apply. Ultra-newbie wannabe developers, writing their first site for Ma and Pa's Kountry Kettle, can create a more feature rich site, and user experience, with minimal learning curve. More experienced developers can create quick prototype applications to gain further approval for time and funding approval, or keep it simple to keep it in budget.
Should Adobe compress all of these scripts prior to the final release of ColdFusion 8? Sure they should, and I'd be surprised if they weren't listening very carefully right now to all of the feedback coming in on the Labs Forums. The bandwidth debate rages on, even as connections are getting faster and faster, but there are people still using dial-up connections. But that shouldn't keep these components and tags from being included in the core language set. They are a welcome addition, and benefit every developer, no matter what level, in the robustness of the feature set they offer, and the ability to do what no other server-side engine can currently do out-of-the-box.
So, to those who feel the need to debate, kwitcherbellyakin! Just because the tags and components are there doesn't mean you have to use them, it just means you should in the right situation.
ColdFusion 8. Use It. Love It. Live It.
Only the first time each user requests them. Geez. If you are that bothered, use mod_gzip or compress them yourself.
It's like CFINTERFACE. If you don't want to, don't :-)
Regardless, we, as a community, have been clamoring for someone to give some TLC to the ColdFusion server and the marketing thereof. Adobe has more than stepped up to the plate so far, and we should be supporting them as much as we can, while providing constructive criticism on the down-low, and in the proper "forum", rather than a public outcry.
It's about appearances and assumptions. Some "other" developer, or CIO or development manager, starts researching ColdFusion 8 because of the things they've began to hear or read. They come across these postings and see other ColdFusion developers locked in debate over a feature that is a major selling point for the server. They suddenly say "Huh, even long running CF developers don't like it" and go back to x. That's not the message we, as a community, want conveyed.
I think what you're seeing though is people just voicing opinions on valid concerns. Of course, there are some diehards CF fans that will always fire back because they see no wrong in anything related to CF. I've seen this for the last 10 years and it happens during every major version.
There needs to be a balance so that folks can offer feedback without reprisal. This debate about file size has actually produced some very positive effects including Adobe emphasizing that they will be compressing their libs before final release and even producing what I consider a best practices example of CF8's Ajax code:
http://www.reybango.com/index.cfm/2007/6/6/CF8-Aja...
We can't be dismissive of feedback because people only offer it when they really care. The day that we don't get any feedback is that day that we need to begin looking at other technologies
@Tom: A load of a 1MB page, even on 1 time basis, is not acceptable unless you're in an intranet or in a completely controlled environment where there's an expectation of latency. I focus on the consumer aspect of web development and dial-up is still pervasive. In addition, I've interviewed users who have told me that they use cache cleaners on a consistent basis. Once you clear the cache, its another 1MB download the next time they hit your site.
Luckily, in my conversations with Adobe, they've realized that needs to be addressed and have expressed that they will be compressing their libs and optimizing their components to trim down the size. If Adobe realizes this is an issue, then there must be some substance to the claims.