When A ColdFusion Developer Shouldn’t Use ColdFusion

Share on FacebookTweet about this on TwitterShare on LinkedInGoogle+

Share on FacebookTweet about this on TwitterShare on LinkedInGoogle+

I love ColdFusion. It is my primary development language and it has kept me gainfully employed for about 14 years. I have seen many improvements in the language over the years. However, ColdFusion does not solve every problem. To be clear, ColdFusion is both a server platform and a scripting language. For the purposes of this post, I will be talking about the language side of ColdFusion and when I prefer not to use it. It may sound like heresy for a ColdFusion developer to openly say he doesn’t use ColdFusion for everything, but there are certain tasks where other toolsets are often better and/or faster to use. These tasks are highlighted below.

segue-blog-when-coldfusion-developer-should-not-use-coldfusion

 

CFFORM

The CFFORM tag was supposed to bring a certain aesthetic to an otherwise drab developers skill set. With CFFORM we were promised rich looking forms that could present themselves in HTML, Flash, or XML. It even had support for AJAX. It also made form validation a breeze. The problem? It always felt bloated. Many times I ended up writing my own JavaScript form validation, because it was slimmer and markedly faster. But that too caused issues, because no two people will write form validation the same way.

I started looking for some standards and I found two I really liked. The first standard I adopted was “ValidateThis”, a full featured form validation framework for ColdFusion. Then I discovered that jQuery, the most popular JavaScript library in use today, could do a lot of the validation I needed as well as anything else. Using a jQuery plug-in aptly named “jQuery Validation,” actually allowed me to solve one of the issues that I had when using CFFORM.

The  jQuery solution also helped me give applications more of the “instant response” feel I was looking for without having to use an increasingly unsupported platform like Flash. Since jQuery is widely used across different programming languages, it is easily adopted and supported by most organizations.

ColdFusion as Database Replacement


There are some developers that like to use ColdFusion to do the databases job. They believe all they need to do is get one mega query and then let ColdFusion filter its data by sending it to other queries. My personal favorite is when a developer runs a query, then loops through that query and performs a query on each result set. This query-loop-query method shows to all that the developer never learned how to leverage their SQL server to its maximum benefit. ColdFusion should never be made to do the work of the database. In fact, if your ColdFusion code is slow or non-responsive, chances are you have an issue caused by this bad coding methodology. This is not a new problem. In fact, Adobe evangelist and ColdFusion guru, Ben Forta made a similar plea back in 2006 (see: ColdFusion is not a DBMS!).

Pretty Much Anything Pretty

The display layer is where ColdFusion will most always take a backseat to another toolset. Right now, jQuery is the tool of choice to get you rich looking forms, grids, effects, and more. As HTML5 becomes a standard across browsers, it too will help replace some of the display elements you might be leaning on ColdFusion to do. For example, with HTML5 you can embed videos, create graphics, create local databases per user, and even perform form validation without a JavaScript library. Unfortunately, adoption of the full HTML5 spec is still slow going among the popular browsers, with Internet Explorer lingering behind (as it always seems to do).

ColdFusion is still the best tool for developing applications rapidly, you may just want to combine it with another tool when looking for rich display content. Even Adobe itself is moving away from supporting rich content programming. In their recent announcement of the next version of ColdFusion (ColdFusion 11, codename Splendor), Adobe highlighted some of the specific features in previous versions that failed to become widely adopted. Some of the failures are exactly what I’ve discussed in this blog. Instead, Adobe will be focusing on what it does best, supporting powerful back-end processes and high level coding procedures. Adobe too is realizing that they are best when they focus on what they do best and leave the rich content for other tools.