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).

64 responses to “I Am Not A Fan Of CFSCRIPT”

  1. ahsan Avatar

    @Sean Corfield. "Java (not Java like) syntax" – what I really meant to say was to utilize all the OOP that Java supports including compositions, innner classes, generics, run time/compile time overloading/overriding, etc. In addition, instead of

  2. ahsan Avatar

    @Sean Corfield. "Java (not Java like) syntax" – what I really meant to say was to utilize all the OOP that Java supports including compositions, innner classes, generics, run time/compile time overloading/overriding, etc. In addition, instead of

  3. TJ Downes Avatar
    TJ Downes

    Sean, specifically i am talking about key/value pairs as attributes. Its too verbose and adds nothing except readability, which can be solved by an IDE with proper code hinting. Granted, you dont need them for everything, but it seems that there are still areas that require these key value pairs (output="true/false" on cfc functions, for example)

  4. Sean Corfield Avatar
    Sean Corfield

    @ashan, "what I really meant to say was to utilize all the OOP that Java supports including compositions, innner classes, generics, run time/compile time overloading/overriding, etc." – so why wouldn’t you just write Java then?
    I don’t se

  5. Brian Panulla Avatar
    Brian Panulla

    @Sean Corfield: Yes, I use the var scoping in for loops over arrays – now that I think about it, my complaint is looping over CF Query objects in script, and not really about the var scoping issue. Unless I’m missing something, looping over a query object

  6. Freemont Avatar

    I prefer writing Coldfusion tags. But I would side and be interested with an actionscript approach to cfscript. I work with Flash (not Flex) regularly and only use jQuery for writing javascript. I can see it being a useful workflow when using flash remoting. I don’t see it making a difference with ajax calls.

  7. Freemont Avatar

    One other thing. Every Flash book I’ve read uses php examples for server side interaction. Coldfusion is so easy to use with flash remoting. If the syntax is closer to actionscript, I can see this becoming a compelling reason to use Coldfusion.

  8. eric fickes Avatar
    eric fickes

    Great comments everybody, instead of repeating the same points, here’s what I’d love to see.
    < CFSCRIPT >
    // cfscript ( legacy support I guess )
    // actionscript – why is this even a question? AS is Adobe’s programming language.
    // Java – hell yes
    I’ve been an active CFDeveloper since CF4, but I’ve also been doing ASP the entire time as well. These days I still love Coldfusion for it’s R.A.D.ness, but you can beat the language options in ASP.NET.
    Again, this is just in my ideal world and I highly doubt Adobe would do something like this. However, I truly believe more devs would freak out ( in a good way ), if cfscript supported that language set.
    < CFTwoCents who="mine" / >

  9. Dale Fraser Avatar
    Dale Fraser

    ColdFusion needs this, and needs it quickly. If you have done any work with ColdFusion and Flex you quickly get frustrated by the syntax differences.
    ActionScript is the Adobe language, it should be supported.
    As for Java, if I want to write Java on the server, I don’t need ColdFusion. Adobe don’t waste your time on this, Java people wont use ColdFusion to write Java, they don’t need it.

  10. skeasor Avatar

    cfscript is great…an easy transition for me from PHP. The syntax is somewhat similar to other languages out there. Plus, it just looks right…cleaner.

  11. Orville Chomer Avatar
    Orville Chomer

    I’m a little late in commenting on this article, but…
    one way to use a cf tag that is not part of the cfscript syntax is to:
    Wrap its functionality in a User Defined Function. Yeah, the function is written in tags, but you can call the function itself from within a CFSCRIPT block just fine!

  12. Charles Robertson Avatar
    Charles Robertson

    To be honest. I think there is going to be a problem satisfying 3 camps. Action-scripters, javascripters and cfscripters.
    Scrap <cfscript> altogether.
    Lets just use the tag based language!
    Now, I am going to get shouted at…

  13. Ghengis Avatar

    You don’t understand Coldfusion very well do you? You are such a n00b. LOL!!!

  14. Brian Erickson Avatar
    Brian Erickson

    I have programmed in PHP, ColdFusion, cfscript, JavaScript and ActionScript.
    For the most part I agree with "molaro".
    JavaScript has no type checking, a pain to debug.
    ActionScript can be a pain to get around the type checking.
    A compile and I am certain each function has correct number and type of parameters and
    syntax is correct. Fewer run-time errors.
    ColdFusion tag programming, is messing, takes up space and difficult to read.
    Which is why I prefer the cfscript, when doing server side programming.
    BTW, considering I started out as C/C++ programmer and tend to favor the C/C++ mind-set.
    Both cfscript and ActionScript are close enough to C/C++ that I feel at home.

Leave a Reply