The Future of ColdFusion: Part 1 - The Changing Landscape

In the Beginning . . .
I started working with Cold Fusion 2.0 in early 1997. A client required me to use it on a site and within a week I was a convert - even though I was using Visual Basic for my offline projects at the time. It kicked classic asp's ass (and as for IDC and HTX files for anyone who remembers those . . .).

At that time I was just happy to find an easy way to take stuff from a database and use it to dynamically generate websites. The fact that sending emails, scheduling tasks and a bunch of other things were also easy (and I don't remember the timeline, so I can't say which of these were in which release) was great as I could just focus on coming up with web based marketing solutions for my clients knowing that the implementation wouldn't be too much of a pain.

Things have changed a lot in the last ten years. I still occasionally get simple projects where putting the form processing, queries and the presentation logic in the same screen or into a couple of cfm's can make sense, but most of the projects I develop now are quite a bit more complex and I use an in-house Object Oriented framework for building most of my apps.

The Problems with Progress
While there are still a large number of developers who build simple sites in ColdFusion (or more often, stretch simple approaches to build more complex applications), there has been a growing interest in frameworks and/or code generatiom over the last couple of years. (I'm going to lump the two together as frameworks and code generation are really just two different techniques for allowing you to write your code more concisely - they can often be interchanged. For example, you might replace CRUD generated via Illudium with an implementation of the Transfer ORM or Transfer with a set of generated code from Illudium with suitably customized templates). The challenge for ColdFusion is that while CF makes many things simple, frameworks/code generation can potentially negate some of those benefits by providing access to a higher level of abstraction, making some of the traditionally useful tags less relevant.

For example, in my framework I only have one cfquery and one cfmail in the whole system. One is wrapped in a BaseDAO method and the other is encapsulated within a NotificationService in my model. I'm sure that anyone developing with Transfer has also noticed they aren't making as much use of cfquery as they used to.

Then the question arises - if you use a framework to encapsulate persistence and notification, how much more work is it to write them in a less efficient language? Sure you might have two write an extra ten lines of code for handling things like opening and closing connections and file streams, but if you only ever have to write the code once how bad is that?

I don't know whether most ColdFusion developers are having this experience yet as many are still just dipping their toes into the MVC framework world. MVC frameworks like Model Glue, Mach-II and ColdBox are great tools for starting to structure your applications better, but they don't provide the productivity of full stack frameworks like Rails in the Ruby world or Django in the Python community. I think as CF developers start to do more with ORMs like Transfer and eventually start to develop and use rich full stack frameworks they are going to find that they get less benefit from many of the "everyday" tags in ColdFusion as they'll be encapsulated by the generated/framework code that will provide a simple interface irrespective of the underlying language being used.

Scripting the JVM
One of the many visionary moves made by the ColdFusion team over the years was porting CF to Java for the MX release. ColdFusion provided a dynamic scripting language on the JVM (a killer combination of RAD development with enterprise tools for deployment) way before it was cool. I often find myself selling CF in part because of the fact that it gives you a productive language on a proven deployment stack.

However, with JSR-223 and a bunch of dynamically typed scripting languages now available on the JVM including Groovy and JRuby, ColdFusion is no longer the only kid on that block.

Tag Based View Templates
ColdFusion started off as a tag based templating language. It is still one of the best templating languages for HTML available. I know a number of Java and Ruby developers who would still like to be able to use ColdFusion for their view templates.

One of the goals of the Railo announcement is to take ColdFusion to the Java world as a better replacement for JSPs and it will certainly be interesting to see how that plays out.

RIA Integration
Adobe also owns the RIA space so as more projects start to use Flex, AIR and LCDS, it isn't hard to work with them in other languages, but it continues to be easier to create and deploy RIA based solutions using CF.

I think that as people start to see the potential of AIR apps and the power of LCDS (such as the online/offline integration in 2.6) many more people are going to start to use the free LCDS Express that comes bundled with CF. In the simplest case, no configuration, no learning about Java servers - just install ColdFusion and start building online/offline apps using AIR and LCDS.

Of course, there is nothing that CF allows for RIAs that is impossible in other languages, but the combination of the ease of ColdFusion and the integration of the LCDS server along with the fact that ColdFusion and Flex/AIR are being evangelized by the same team means that some of the RIA halo is going to help the ColdFusion market to grow.

Making Hard Things Easy
In addition to dynamic scripting on the JVM, a kick ass templating language and RIA integration, ColdFusion still makes many other hard things easy. With standard you get the power of a Java server without having to have a Java hosting guru in-house (most of the time). And with all of the editions there is a very powerful set of tags for solving hard problems quickly. For example, anyone who has used ColdFusion and any other language to work with web services knows how much quicker they can be to work with in CF. Depending on your needs, the PDF, presentation, AJAX and .NET integration are only some of the things that ColdFusion can make easier.

Losing and Gaining . . .
It's always interesting to me to see where a language is losing and gaining developers. Obviously there are times where an IT shop makes a business level decision to (say) standardize on .NET or Java, but on the whole I'm seeing more RIA developers at least considering CF as a back end and some of the more advanced CF developers try alternate languages - especially for their model. Hence the growing interest in using ColdFusion views and controllers with Java or Groovy models.

Whither ColdFusion?
I continue to be extremely excited about the present reality and the future opportunities of the ColdFusion market. Over the next couple of postings I want to look at what both Railo and Adobe are bringing to the table before in my final posting looking at how things might shake out for the community as a whole.