In the interests of full disclosure, I'll state upfront that I am not a fan of <cfscript>. 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, <cfscript> 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 <cfscript>, but never really committed to it. We talked about how to make <cfscript> 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 <cfscript>, 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 <cfscript>. ColdFusion developers can now write CFCs in <cfscript>, 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 <cfscript> was to broaden the ColdFusion developer universe by making the product compelling and appealing to traditional computer language users. That never happened. And enhancing <cfscript> now, all these years later, is not going to make it happen either.
So does <cfscript> have any value now? Absolutely, but not as originally intended. Nowadays I see two primary use cases for <cfscript>.
But in addition, there is one area where I think <cfscript> 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.
I started off by saying that I am not a fan of <cfscript> in its current form. But I am most definitely a fan of solving the problem that <cfscript> could, and should, solve. As such, I'd like to see <cfscript> in its current form deprecated. And then let's figure out exactly what <cfscript> 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).