« Firefox tweak: Spell check any text field | Mozilla Prism to compete with Adobe AIR in the race to the desktop »

August 27, 2007

ColdFusion is the next FrontPage

Web professionals around the world rejoiced when Microsoft recently announced that they were discontinuing their infamous FrontPage WYSIWYG web authoring program. FrontPage, which was designed to make web site creation as easy as word processing, was scorned by web professionals due to the non-standard, proprietary Microsoft spaghetti HTML code that it generated. Many people could identify a web site created with FrontPage at first glance and the program and the sites that it created quickly became synonymous with amateur, wannabe web designers.

Unfortunately, the old FrontPage is now being replaced with a new “FrontPage.” Only this time it’s called Adobe ColdFusion 8. With the recent release of version 8, ColdFusion is being trumpeted as the quickest and easiest way to web applications. Sound familiar? Just replace “web application” with “web site” and you’ve got almost identical product slogans. What FrontPage attempted to do for static web sites, ColdFusion is trying to do for dynamic web applications. But this slogan doesn’t necessarily make ColdFusion a bad thing. Let me explain a little bit…

I use ColdFusion every day at work as a web application developer for the City of Portland. And I love ColdFusion because I honestly do believe that it is the quickest and easiest way to build powerful web applications. So when version 8 was recently released I was thrilled to learn about the new Ajax features designed to make building Ajax enabled applications easier than ever before. Having already built a couple of Ajax enabled web apps “the hard way” I was curious to see how well ColdFusion was able to simplify the process.

So after downloading and installing the developer edition on my computer, the first thing I did was experiment with some of the new Ajax features. I was pleasantly surprised to discover that Adobe had fulfilled their promises and kept to the ColdFusion tradition of abstracting typically difficult tasks into dead-simple and easy to use tags. In just a few lines of CFML code I was able to add an Ajax auto suggest text box. With a few more lines of CFML and little ColdFusion component, I was able to create a “live HTML data grid” complete with automatic paging, dynamic on request record loading, and edit-in-place functionality. Not once did I even have to know a thing about JavaScript or how Ajax functionality works—ColdFusion magically took care of all those details behind the scenes for me.

“Wow!” I said to myself as I hit the view source button in my browser, “Let’s see how they did it…”

It was at this point that the music suddenly stopped, the lights began to dim, and the smile quickly faded from my face. I’m a big advocate of standards-based web development and I usually try to create pages that conform to the XHTML Strict doctype. The first thing that I noticed was that while the HTML code that I’d used was valid, there were several validation errors in the ColdFusion generated code.

What’s worse is that they were all simple, easy to fix errors that could have been avoided had the ColdFusion engineers taken a little more pride in their work and taken the time to verify that they were generating valid code. Maybe you don’t think it’s a big deal if there are minor validation errors “so long as the page looks okay and functions correctly.” Here are two reasons why I feel that it is a big deal. First, if you want to serve your XHTML pages as XML documents (as they are supposed to be served) instead of as “text/html”, the page must be valid. Otherwise the browser will just show the user an ugly XML parse error. Second, due to its ease of use, ColdFusion is used by a lot of novice developers. For these users ColdFusion is often their introduction to HTML, CSS, JavaScript, server-side programming, and all of various technologies that go into creating a web application. Do we really want them using the ColdFusion generated code as a learning tool? Adobe should strive to set a good example by following the industry standards and best practices in their code so that developers using it as a learning tool will learn good habits and learn to do things “the right way.”

The next thing I noticed when looking over my page’s source code was that ColdFusion automatically included a bunch of Yahoo YUI and Ext JS JavaScript files based on the specific requirements of the particular CFML tags used on the page. I think it’s great that the ColdFusion engineers chose to take advantage of some of the great open source JavaScript libraries out there. But this brought up an interesting question to my mind. What if a ColdFusion developer wanted to use those same libraries to develop custom JavaScript functionality in their web application? And let’s say for the sake of this example, that not every page on the web site uses one of the CFML tags that automatically includes the JavaScript libraries. The developer would need to ensure that the libraries are included anyway on those pages to support their own custom JavaScript functionality.

So the developer manually hard codes in links to the JavaScript libraries in an application wide template so that they will be included on every page regardless of the CFML tags used on the page. But what happens on the pages that do use the CFML tags that automatically include the JavaScript libraries? Well, it turns out that the libraries get included twice—once by the developer’s template and again by the ColdFusion tags! This is not good! At the very least the browser will make two HTTP requests for each script file, possibly resulting in many redundant requests. (At least the second time the script should get loaded from the browser’s cache). In the worst case scenario, it could potentially cause the scripts not to function property because each one will get run/initialized twice by the browser. Now, how hard could it be for ColdFusion to verify that the JavaScript libraries are not already being included on the page before automatically including them again?

It seems that when it comes to creating a web site, whether it’s a static web site or a dynamic web application, if you want it done right you’ve got to do it yourself. This includes hand coding your HTML and handling the nitty-gritty details of Ajax enhanced web sites. This brought me to the conclusion that ColdFusion is just the next FrontPage. No doubt the new Ajax features will get used and abused by the less knowledgeable developers looking for the quick and easy solution. But smart developers who care about web standards and take pride in creating clean, semantic, valid HTML will do things the way they’ve always done them in the past—by hand. So the next time your tempted to use on of the new ColdFusion features that magically does everything for you, take a look behind the scenes at what’s really going on and evaluate if it’s really the best way to accomplish your task. You may find yourself joining me and doing it the hard way. But at least it will get done the right way!

P.S. Adobe, if you’re listening, it’s not too late! I’d love to be surprised by the next ColdFusion update to discover that you’ve fixed these issues that you’re putting forth an effort set a good example and do things the right way. If so, I promise I’ll never mention ColdFusion and FrontPage in the same sentence again!

Posted at 8:12 PM in ColdFusion

Comments

1. Raymond Camden says:

I wanted to comment about your "JS issue" specifically. First off - I don't think anyone recommends modifying the core JS files used by CF's AJAX features. I would say if you want to modify them you should be using your own copy. -But- if you do go down that route, you don't have to include them with a script tag. All you need to do is use cfajaximport. That way you can then use your custom code - or use one of the built in tags, and the JS is loaded once.

As for the validation - I'm not going to argue it as I just don't agree that it is as big of a deal as you are making out. But I will point out that the Ajax features are more than just UI elemenets, cfajaxproxy by itself is incredibly powerful and doesn't have a lick of UI to it. Therefore it would not "suffer" from the validation issues. Do not forget you also have Ajax debugging, and you have Ajax-related security items.

Posted on August 28, 2007 at 4:13 AM

2. Anon says:

Silly entry.

CF8 offers great new features but you don't like it because some of the html is not standards compliant? Something most people don't care about in the slightest.

As for making web applications easy argument that is something every new framework and existing languages try to convey. Are they all the next FrontPage as well??

Posted on August 28, 2007 at 5:51 AM

3. Jim Priest says:

Interesting post - I haven't had time to tinker with CF8 yet but did wonder about some of the issues you raised.

Did you happen to notice the file sizes of the js libraries - I know there was some issue with the beta that these were really large - I was curious if the shipping version addressed that by packing them possibly.

I don't think it's a bad thing - how many of started off using cfinsert, cfform, etc - only to later replace it with more streamlined code. The validation errors are a bit hard to overlook though.

Posted on August 28, 2007 at 6:13 AM

4. Raymond says:

I totally agree, and sometimes I feel guilty using coldfusion, because it does so much 'magically' And I've seen the sort of things coldfusion does in the background, things like the dump tables, which have multiple html and javascript errors. I've noticed the same with dreamweaver js functions as well. Granted of course, those were Macromedia's doing. Like you said, the answer really is to just do it yourself, and making your own ajax tags is probably the best option

Posted on August 28, 2007 at 6:36 AM

5. Rich Rein says:

Just a thought...might be worth pointing out exactly which "things" you are talking about...both so that other developers can decide for themselves what they can live with, and so adobe has no excuses for not addressing the issue...

Posted on August 28, 2007 at 7:39 AM

6. Luis Matthews says:

Great post. I firmly agree that making things easy doesn't excuse Adobe from doing things right. Even if it was only novices that use these features, that would still be no excuse. That being said, I don't think it's overly realistic to expect their implementation of AJAX to play well with one you roll yourself. I think that it's an all or nothing venture. If the simple tag works for your specific project, wonderful. Otherwise, roll your own.
I wonder how many people didn't read this based on the title? At first it almost sounded like yet another "CF is Dead" type post.

Posted on August 28, 2007 at 8:14 AM

7. John Dowdell says:

Summary is actually "I wish CF8 HTML/JS/CSS passed certain validators", is that the core of all that text?

If so, then precise documents can be cited for that request at
http://www.adobe.com/go/wish

(I don't think Diggers or Slashdotters will read all that text; it's late summer, they'll probably just riff off your title after trying a few of the subsequent paragraphs.)

jd/adobe

Posted on August 28, 2007 at 8:33 AM

8. Tom Chiverton says:

Sounds like you have some points to make - ooi were you on the CF8 beta ? If not, did you apply ? If not, why not ?

Posted on August 28, 2007 at 8:34 AM

9. Richard Davies says:

@Raymond Camden:
I am aware of the cfajaximport tag and agree that it's a slippery slope if you decide that you want to make any modifications to the core CF JavaScript libraries. The only thing I don't really like about that tag is that you've got to know which CF tags to list to get the specific JS libraries that you need. That doesn't seem like the optimal solution to me. Also, I really do agree that the Ajax proxy is awesome. I didn't mean to imply that all of the new AJAX-related features were bad, but rather that I see some issues with a few of them and that users ought to be aware of what CF is doing behind the scenes.

@Jim Priest:
No, I didn't check out the sizes of the included JS files, although I did notice that using more than one Ajax tag on a page causes the list of included files to get pretty long. So file size is definitely a concern. This is why I think CF should provide a better way to "reuse" those included files for developing custom JS functionality.

@Rich Rein:
I /did/ mention specifically the auto-suggest text box and the live HTML data grid.

@Luis Matthews:
Yes, I realize that it would take some extra work and planning by the CF engineers to provide an easy way for their Ajax implementation to easily integrate with a developer's custom needs. But I think it will be fairly common for developers to want to use the new CF Ajax functionality and augment it with some additional JS features. It seems absurd that the developer should have to include additional JS libraries to support their custom requirements. It should be easy to reuse the libraries included by CF.

@John Dowdell:
Yes, I should submit my requests to the CF wishlist. Thanks for the nudge. (I didn't write this for the Diggers and the Slashdotters... most of them would have trouble reading more than two paragraphs of anything and will jump to the wrong conclusion no matter what I say...)

@Tom Chiverton:
Yes, I was on the CF8 beta. But in all honesty, I was unable to really take a look at CF8 until just recently due to a heavy project load during the beta period. I often daydream of what I'd do if I had all the free time that Raymond Camden and some of the other CF bloggers seem to have... ;-)

Posted on August 28, 2007 at 1:15 PM

10. Dan Wilson says:

While your points are valid, the title is a little extreme and offputting. The CF8 Release is extensive and like all software projects, some things had to be trimmed to make the date. Adobe has been very responsive to items added to the wishlist at
http://www.adobe.com/go/wish. You might get more collaboration by that route. I believe most ColdFusion programmers would prefer their markup to be valid, but not at the expense of leaving out the feature.

The problems with FrontPage were severe Microsoft made 0 attempts to fix them. Adobe, on the other hand, has shown remarkable attention to developer requests.


@4. Raymond Richards point about validity relates to generated code shown to the user, or otherwise used as a deliverable. I do not think the cfdump tag was ever meant for anything apart from developer convenience. Do you really feel like the markup in CFDUMP should be valid?

Posted on August 28, 2007 at 1:23 PM