Yesterday we quietly rolled out two important enhancements to the Adobe Developer Center.

The first change is community powered search (you'll see a new search box on the upper right side of the page), which basically means that searches now includes content from a wider array of sources, including community sources like relevant blogs. The second change is that logged in users can now post comments on articles, these comments are posted live immediately, but are also moderated (and will be scrubbed as needed).

While these new features are tested and tweaked they'll only be available in the Flex Developer Center. But we'll add these to additional ADC sections in the future.

Yesterday I received an interesting question from an individual who used ColdFusion extensively in the CF3-CF5 era, but has no experience with ColdFusion MX or later. He is now getting back into ColdFusion development, and wanted to know what it is he needs to know about ColdFusion today. It's an intriguing question, and I decided to blog my response because A) others might be interested in the same thing, and B) others may have different answers, and I'd like to see them myself. So, comment away, and here is my response ...

Hi,

You've asked an important question. ColdFusion went through a significant metamorphosis going from CF5 to CFMX, and while you can still write code exactly as you used to, I strongly believe that you should not be doing so. Despite being able to run the same old CFML, ColdFusion (as of CFMX) is a radically different product from what it was previously, and being able to fully take advantage of it does require learning some new skills. So, here is where I'd like you to concentrate (in no particular order):

• ColdFusion MX and later (all the way to ColdFusion 8.x today) is all Java internally. While there is actually no need to know Java to be able to successfully use ColdFusion, understanding the ColdFusion Java relationship is very useful. Just knowing what ColdFusion's Java underpinnings make possible ensures that you'll know what your options are in the future, whatever that future may be.
• ColdFusion Components are the most important change to the CFML language since, well, since we created CFML. While it is entirely possible to build reusable, organized, structured, manageable, and scalable code without CFCs, I'd not advise doing so. ColdFusion Components are clean, simple, and sophisticated, and form the basis of just about any structured ColdFusion development. (They also are they key to working with Web Services, Flash and Flex integration, using gateways, Ajax integration, and more). While CFML is not an object oriented language, ColdFusion Components provide CFML developers with some of the core benefits of objects, without much of the complexity typically associated with OOP development. Simply stated, ColdFusion Components encourage (and even reward) better development practices. And not using CFCs nowadays raises a major red flag for me.
• Understand frameworks, methodologies, and more. And no, I am not going to get into a Mach-II vs. Fusebox vs. Model-Glue debate, nor am I going to enumerate all of the invaluable community projects and initiatives in this space. The fact of the matter is that I don't care what framework or methodology or data abstraction layer or standards or best practices you use. I just care that you use something. If one of the established projects works for you, great, use it. If not, then roll your own. You may truly need the discipline encouraged by MVC implementations, or you may just need a document that clearly lays out your rules for variable naming and code organization and more, or you may need something in between, or some combination of options. There is no one size fits all, and what works for one project won't necessarily be right for your next project. What you use is far less important then understanding why structure and organization is necessary in the first place. The just-start-writing-code-and-then-figure-it-out-as-you-go mentality of the 90's is thankfully long gone. And nowadays developers understand that the planning and structure that was the norm pre the instant-gratification .com era is still as important and relevant as ever. That's a good thing indeed.
• Way back in the late 90's I wrote a column entitled "When Not To Use ColdFusion" that argued that the best ColdFusion apps are not pure ColdFusion apps. Rather, they know when to take advantage of other systems and options, be in SQL stored procedures, Java code, and more. And nowadays this is more true than ever. ColdFusion provides an amazing array of integration options, from Java object invocation to web services support to JMS connectivity to all sorts of gateways to new .NET integration and more. ColdFusion is great at lots of things, but is not ever going to be the best at everything. As an example, just about every DBMS can sort, process, group, summarize, and manipulate data far more efficiently than ColdFusion ever will. In addition, lots of what you may need in your apps may already exist elsewhere, and you should be able to leverage the best-of-breed whenever appropriate. This kind of goes back to my first point, it pays to understand what options are available, so that you'll be ready to use them when needed. The best ColdFusion developers I know are skilled in more than just ColdFusion. They may indeed create and deploy projects that are all ColdFusion, and that is often completely appropriate. But they also know when and how to pull all sorts of pieces together to craft the best possible solution to any problem.

The bottom line is that ColdFusion is richer, more powerful, and far more mature than it was back in the 90's. You can do exactly what you did before, and you'll probably be successful. But, that would be kind of like buying the latest top of the line gaming system and using it to play Pong. Ok, maybe not that extreme, but you get the idea.

Welcome back, there has never been a better time to be a ColdFusion developer!

--- Ben