Ben Forta

In the interests of full disclosure, I’ll state upfront that I am not a fan of . At least, not in its current form, and not how it has evolved since first introduced back in 1998.
Which is probably a good place to start this discussion, back in 1998. Cold Fusion 3.x (yes, with a space) was an important release. The truth is, with the exception of the introduction of Cold Fusion Studio, Cold Fusion 3 itself was rather anti-climactic, it did not add that much over Cold Fusion 2 (which had been a massive overhaul of the original Cold Fusion). What made Cold Fusion 3 so important was the fact that it was released in mid-1997 and early 1998 (versions 3 and 3.1 respectively), right when the .com juggernaut was in high gear, and right when building sites quickly (so as to go public a week later) was the mission of the day. Cold Fusion rode the .com wave magnificently, and (for better or worse) a huge number of the .com successes (and failures) were powered by Cold Fusion.
Which brings us to the Cold Fusion 4 planning sessions in the first half of 1998. We identified two areas of focus for Cold Fusion 4. First, apps were starting to become more complex and more critical, the term “enterprise” was being used in the same sentence as “web” for the first time, and words like “scalability” and “redundancy” and “clustering” and “failover” suddenly peppered every conversation. For Cold Fusion this translated into an acquisition in the clustering space, which then facilitated the release of ColdFusion Enterprise, and that in turn made it possible to raise the price of a Cold Fusion offering (as the lower price was becoming an obstacle to being taken seriously in larger organizations and deployments). Second, with Perl quickly falling out of favor for web development, and with ASP 2 just released and PHP starting to pick up steam among developers used to more traditional languages, we decided to introduce a scripting syntax to Cold Fusion for the sole purpose of trying to entice those developers.
So, how did Cold Fusion 4 do? The Enterprise focus was a huge success (even though we ignored the analysts who told us that the best thing we could do for the product was to tack a couple of zeros at the end of the price). The scripting idea, however, failed. Why? Well, for starters, never actually did enough. Sure, it made if statements and variable assignments feel more like they would in traditional languages, but as soon as you needed to do any real work you’d have to drop to tags anyway. Fail. In addition, the language was actually not like the languages whose developers we were targeting, and felt clumsy and awkward to them (which, in truth, it was). Fail. And finally, to be a viable option against perceived free alternatives you need to add value, not get in the way, and so as a result of the prior two issues, price became the deciding factor, and developers were just not going to pay for something that got in the way instead of helping. Fail.
Now, just to be clear, Cold Fusion 4 was one of the most successful Cold Fusion releases ever in number of copies sold. Cold Fusion 4 itself was in no way a failure. But the scripting feature? Yep, that failed. Miserably.
Over the years we kept tweaking , but never really committed to it. We talked about how to make a first class citizen in ColdFusion, we talked about introducing a .cfs file where everything would be in script, we talked about ways to expose all CFML tags in , we revisited the scripting concept with each and every release, but never really committed to it. It’s not that there was no interest in the feature. There was, lots. But when you have to weigh features for releases you have to play the prioritization game. Add resources to Feature A and you have to remove from Feature B, or ship the product later, and so on. And every time we ended up having to decide between adding new features or providing users with an alternative way to do what they already could do. And each and every time new features won the debate, and understandably so.
Recently, with the releases of ColdFusion 8 and ColdFusion 9, we finally did commit engineering resources to improving . ColdFusion developers can now write CFCs in , they can access just about any CFML tag using scripting syntax, they can create arrays and structures using shorthand notation, they can use operators that actually look like script operators, and more. For some ColdFusion developers, this is a long overdue enhancement. For some. For others (arguably most) it’s irrelevant.
And for me? Well, for me it’s too little too late. Remember, the original intent of was to broaden the ColdFusion developer universe by making the product compelling and appealing to traditional computer language users. That never happened. And enhancing now, all these years later, is not going to make it happen either.
So does have any value now? Absolutely, but not as originally intended. Nowadays I see two primary use cases for .
First, it can indeed make life easier for ColdFusion developers. At its simplest, long lists of statements are a pain, and the equivalent block is just cleaner and more elegant. Complex nested business logic can also be easier to manage and comprehend in . Moving back and forth between the various languages used in development is easier when using . Ever tried porting a Java or JavaScript or PHP function to CFML? Do it once, and you’ll find yourself thankful that exists. can, and does, make life easier and more productive for ColdFusion developers. And I am fully supportive of anything that makes ColdFusion even more productive than it already is. Productivity is, after all, ColdFusion’s very raison d’être.
But in addition, there is one area where I think can indeed deliver on its original objective, to some degree, and that is for users of other Adobe products and technologies, and most importantly, Flash. There are hundreds of thousands of over 2 million Flash developers and designers out there (far more than there are ColdFusion users actually), and many have top-notch client-side skills but have done nothing server-side ever. And now they need to do just that. I have lost count of the number of times a Flash user has asked how to generate an email message or make a simple database query, stuff that ColdFusion does so easily and beautifully that we take it for granted. I want ColdFusion to be the obvious choice for every one of those Flash developers and designers. This is a huge growth opportunity, and one that ColdFusion is uniquely positioned to address. And when you add AIR and Flash on devices to the equation, the opportunity becomes even greater and even more apparent.
So, be it to simplify the development lives of ColdFusion developers, or to empower Flash and Flex users, ColdFusion scripting is compelling and much needed. But, in its current form, fails on both counts. Why? Simply because today is an oddly bastardized nonsensical language that seems to be mutating rather than evolving. It is not JavaScript, although there are similarities. It’s not Java, although CFCs look quite Java-like. Actually, to be brutally honest, it’s not anything that any existing developers would recognize or find intuitive. And so while I am supportive of ColdFusion scripting, I believe that just as the original Cold Fusion 4 implementation failed to deliver, so is its current form hindering its own chances of success.
Scripting in ColdFusion? As I said, I’d wholeheartedly support the effort, but I’d want it based on an established language, similar to what we should have done way back when. Some have suggested that be implemented in JavaScript, and I’d be fine with that. JavaScript is used by just about every ColdFusion developer, and being able to use the same language for the client and the server would be useful and compelling. Others have suggested that be implemented in ActionScript. Personally, I’d welcome this option, and judging by the response when we sneaked this functionality at MAX I’d venture to suggest that the idea would be very popular.
I started off by saying that I am not a fan of in its current form. But I am most definitely a fan of solving the problem that could, and should, solve. As such, I’d like to see in its current form deprecated. And then let’s figure out exactly what should look like in the future. That would be a very useful discussion to have (although I’ve definitely aligned with the server-side ActionScript camp on this one).