Blog

4Feb
2011
I Am Not A Fan Of CFSCRIPT

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

First, it can indeed make life easier for ColdFusion developers. At its simplest, long lists of <cfset> statements are a pain, and the equivalent <cfscript> block is just cleaner and more elegant. Complex nested business logic can also be easier to manage and comprehend in <cfscript>. Moving back and forth between the various languages used in development is easier when using <cfscript>. Ever tried porting a Java or JavaScript or PHP function to CFML? Do it once, and you'll find yourself thankful that <cfscript> exists. <cfscript> 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 <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.

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, <cfscript> fails on both counts. Why? Simply because <cfscript> 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 <cfscript> 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 <cfscript> 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 <cfscript> 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 <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).

Comments (63)



  • John Farrar

    I am a fan (in the right season only) of CFScript. Great article.

  • Rui Silva

    +1 for the server side ActionScript. It would open ColdFusion to a huge number of developers who, right now, are afraid of being lost amidst CF's tags and the somehow strange scripting syntax.

    #2Posted by Rui Silva | Feb 4, 2011, 11:56 AM
  • Paul Carney

    Ben - I agree that it has not lived up to its purpose and that Adobe should attack the issue to keep it from becoming a blocking point for developers.

    I do not agree that ActionScript is the best solution. I would rather see it go towards the industry-standard Javascript. There are many CF developers that use Javascript libraries like jQuery instead of Flex. We choose this direction because we need our code to work on tablets, including the iPad.

    And if it does go the Javascript route, it will be much easier to integrate any Javascript code. I know that you can also integrate Javascript with ActionScript, but why muddy the waters? Your point in this post is to make it more useful for the developer and I believe that in general, Javascript has more use in the industry than ActionScript.

  • molaro

    Great article! In general I feel the same way I think. As a CF developer, I know originally CFScript seemed intimidating to me. I wasn't sure what code worked in script and what didn't. CF9 has resolved a lot of that. Also, having done Flex work for a few years, and totally falling in love with Actionscript, I really like cfscript a lot better. In my mind, there is now less translation I have to do when I jump from an AS class to a CFM or CFC file that supports my back end.

    Since the major updates in CF9, I have assumed (and hoped) in the back of my mind, that Adobe wants to take CF in a similar direction as Flex. In other words, we would still use CF tags for display (ala MXML in Flex), and now move towards cfscript more for the back end logic (like AS in Flex). The more we blur the lines, the less ramp up time a developer needs to learn, or get their head back into a different code base, enabling them to develop faster. Of course as part of that we need CFBuilder to do a MUCH better job of code hinting, error handling, etc (again just like FlashBuilder does already). I could even see the CF script, CFML, HTML, JS, AS, and MXML syntax libraries being bundled up into libs that could be added to a project, just like I load the AS3Core lib into a Flex project today, I could load cfscript into a Flex project and poof, additional functionality.

    As for the comment about hoping cfscript moves more towards javascript rather than actionscript, I disagree. First, in my mind, there isn't much difference between JS and AS as far as core coding methodologies. However, I have come to love the strictness that AS enforces, and almost always wish JS did it more. I know people who do more JS than AS (or Java) probably like the freedom, but I have found that the strictness makes me a better coder. I know which var is which, I know what's private versus public, and the compiler enforces those standards keeping me in line. So to me that's a good thing.

    #4Posted by molaro | Feb 4, 2011, 12:25 PM
  • Daria

    Awesome article! I too support the possibilities that cfscript can add to the language, but am frustrated with its implementation. Many times I've been tempted to write a blog post titled, 'Queries in CFSCRIPT Break ColdFusion for Me'. I think the script functions implemented as cfcs are clunky and hack-ish. I would welcome an overhaul.

    #5Posted by Daria | Feb 4, 2011, 12:58 PM
  • Daniel Schmid

    I love cfscript... can't imagine writing modell components tag based anymore, in views I use cftags. To force any cf developer to learn action script would definetly the wrong way... Javascript as an option - yes

  • phill.nacelli

    I would welcome cfml scripting as server side Actionscript! I would even welcome if it were strongly typed! Yes.. there I said it.. :)

  • Jason Dean

    ActionScript is statically typed, ColdFusion is not.

    Are we talking about Server-side ActionScript (with static typing)? Or are we talking about making ColdFusion "look like" ActionScript but still be the dynamically-typed wonder that it currently is?

    I suspect the latter.

    Personally, I think ActionScript-like CFScript would be the better choice. I also think a separate server-side ActionScript implementation would be great. Not one or the other, BOTH.

    Am I making sense?

  • Jim Pickering

    I really enjoy reading about the history of ColdFusion from your perspective Ben. I jumped in with version 3.1 and had no idea what I was doing, I hadn't even coded HTML at that point, I learned both on-the-fly. Version 4 was when I started figuring things out.

    I am using CFScript more and more with CF 9. I like it for the reasons you mentioned, but Queries are quite burdensome. I find coding the CF9 ORM with CFScript to be a cleaner, more readable way to code. But I also enjoy coding ActionScript 3 on the Flex side of things, and would prefer CFScript being implemented with ActionScript, over JavaScript.

  • Jason Fisher

    @Ben,

    As always, thanks for the insights into CF history. I've been a CF coder since version 2, and made the transition to CFSCRIPT late, only after I had an appreciation for JavaScript. Seems like following the JS model would be a sensible step forward.

    Also agree with previous comments that things like CFSCRIPT queries are just too odd to be very compelling, at least for me. I stopped using SQL as string variables long ago, and the kludgy assembly of scripted queries in CF 9 feels a lot like those old days of "wrap it all in preserveSingleQuotes()". Of course, in that specific example, I don't think JS (or AS) helps much, since the challenge of porting functions like CFQUERY and CFMAIL haven't been solved in those other scripting languages either.

    #10Posted by Jason Fisher | Feb 4, 2011, 01:43 PM
  • Magnus Thyvold

    Is it possible to support both options? <cfscript syntax="javascript">, <cfscript syntax="ActionScript"> and even, for backwards compatability, <cfscript syntax="cfscript">. I'm guessing it is totally possible but the but perhaps not practical in terms of resources needed to keep developing 2 (or 3) flavours. It would certainly open up CF to the widest audience of new developers.

  • rich

    Love the cfscript! My views use cfml, but controllers and services are almost completely cfscript. It's just more concise and legible when it comes to business logic, IMHO.

    Support for Javascript and ActionScript sound great, but let's not deprecate what we have now.

    #12Posted by rich | Feb 4, 2011, 02:34 PM
  • TJ Downes

    While I agree with the sentiments you are expressing Ben, I'm not a fan of putting ActionScript into CF. It will just add to the confusion, and potentially end up as another legacy thing in CF that's adding to the bloat of the server. Does Adobe realize that I need to upload a 400MB WAR file to the cloud to deploy a CF app?

    I'm all for an AS3 middleware engine. But I'd prefer to see it as a standalone server or not at all.

    For me, I'd like to see Adobe focus on going back to basics: Strip out all the legacy stuff. Make a plugin engine and lets not include those those legacy things by default (seriously, does anyone use the Java cfgrid anymore? cfreport is so old is nearly useless. I could go on). CF needs to go on a diet before more is added to it. And it needs to be more open so that the community can participate in it's growth (via plugins). Then we can worry about things like cfscript.

    #13Posted by TJ Downes | Feb 4, 2011, 04:30 PM
  • big al

    Really, deprecate cfscript after finally becoming useful? That would be a shame.

    With CF9, I finally feel at peace with CF as I can now write components and business in cfscript and not yearn for the elegance of a more formal language. (This feeling may be unique to those of us who come from a more traditional programming background however.) And for views, cfml is still king.

    As others have mentioned, having an extensible script engine would probably would probably be the best of all worlds.

    #14Posted by big al | Feb 4, 2011, 05:33 PM
  • Sean Corfield

    I'd be interested to hear what _specifically_ folks would want to change in cfscript to make it more like JavaScript and/or ActionScript (both of which have ECMAScript as their root - and AS3 specifically draws on ECMAScript 4 / ECMA-262 extensively). Recent enhancements have made it much, much closer to that ECMAScript core.

    Is it the type system? That's very different in all three languages (JS has a prototype-based model like Io, AS has a fairly traditional statically typed model, CFS has a very dynamic model that allows meta-programming).

    One syntactic thing that trips me up constantly moving between the three is that semicolon is optional in JS and AS but required in CFS (in Adobe ColdFusion - it's optional in Railo). Since I work with several languages where semicolon is optional (JS, AS, Groovy, Scala...) I keep omitting it in CFS and Builder complains at me! :)

    I've gone on record in the past as saying cfscript should be deprecated - for most of the same reasons that Ben gives - but with the changes in CF8 I started to use it more and with the latest round of enhancements, I now write all my CFCs entirely in cfscript and I'm pretty happy with it.

  • John Mason

    The scripting debate comes back around again. How many times has this discussion come up?

    I, like Ben, never liked the evolution of cfscript, but the deeper problem is the management of the language. Jason hit the nail on the head. Actionscript is static. So making it fly in the CF world would mean either converting it in a very fundamental way or leaving it as a static script language that runs along the dynamic tag language of ColdFusion tags. Neither option sounds great. You will have to manually deal with the conversion somewhere. There's no way to avoid that. I suspect certain parts of Adobe may be working on a Actionscript server platform but it may not be associated with ColdFusion. It may be another BlazeDS-type project that CF might be able to talk to. I guess we'll see. The problem lies in that converting from static to dynamic can be a complete pain. Trust me, I've been doing it for several years now.

    I like Ben, but sometimes I think he has far too much influence in these debates. Making cfscript more like Actionscript isn't going to make any real change. He should understand that. Does it make sense for him to continue to have the influence he has over this anymore? I'm starting to think not.

    What should have happened with cfscript and never did was to pattern it after JavaScript/ECMAScript which is a script and also dynamic. That was actually the idea at first. Because the initial edition of cfscript was half-baked, it got lost over the years.

    The bigger problem is the management of the language has been left to a very small group of people that have had little to no background in language development. Then you have others, like Ben, that have too much influence over the decisions related to CF. This pattern in developing a language has been a mess. Over the years, the results pretty much speak for themselves. For example, every time I have to specify "output=false" on my components and functions, I think WTH. TJ mentions all the legacy crap that has drag CF with each release. In the world of the cloud, you can't justify a 400MB or larger WAR file just for the simplest apps. ColdFusion needs to be lean and mean again.

    I was really happy to see the standards committee start up, but sadly, due to personality conflicts, Adobe didn't see the need for it anymore and killed it. ColdFusion needs a proper standard and a group of wise men to help it evolve. It just can't be duct taped together anymore. And sorry, the ACP fanboy club, which is how it's evolved now, isn't a solution in my opinion.

    Even the recent additions to cfscript have been really weird, look at transactions, queries or locking in cfscript. Now, the small problems have only grown, in time, to become far bigger ones. Yes, there are people that use cfscript, but it's not gaining wide adoption among the CF world and it's not converting people to the language. Remember, there was a small group of people back in that infamous cfObjective BOF that pushed for these cfscript enhancements, and many of those same people have moved on to other things. Once again, the voice of the vocal minority won out, and turned things in the wrong direction.

    Now with the HTML5 / Flash problem in full swing, Ben and others at Adobe want to pattern things tighter to Flash/Flex/Actionscript. I, frankly, think this is a bad move. It's important to gain adoption. So do you go after the hundreds or thousands of Flash developers or the millions of Javascript developers. Do you go static or dynamic? Dynamic is winning and oddly enough ColdFusion was way ahead of its time in that regard. Most web developers know HTML (which is tag based) and some degree of Javascript (dynamic script). ColdFusion should do what it has always done best at, to make things easier for that group.

    To be honest, Flash/Flex/AIR is going to have a rough run. Regardless of what people think of Apple, the fact remains that there are millions of iOS devices that don't run Flash in the browser. This isn't going to change anytime soon, and at this point, it's very important to pick your battles. Clients aren't going to understand if the app doesn't work on their iPhone or iPad. ColdFusion has always been the best glue to talk with multiple services but it shouldn't get in bed with any of them directly. I suspect we may be looking at Actionscript in 10 years like we look at Director today. As a result, making cfscript based on Actionscript could end up being another hugh waste of time.

    Remember, today, BlazeDS, Flash and Flex all work just fine with ColdFusion. You do have to handle the conversion between dynamic and static but that will never change. Sorry Ben, I think making cfscript more Actionscript like isn't going to bring anything extra to the table in this regard. Nor are Actionscript people going to jump into ColdFusion that easily. It just doesn't work that way.

    I think one of the main points that Ben made is true. All of this may be a "little too late". ColdFusion has lost a lot of steam since the .com days, and sadly ColdFusion development had been very disorganized (flash forms, cfreport, cfscript, etc) and going around in circles for the past 10 years. Several editions have had completely half-baked features that were not properly thought out or much less fixed later. That simply can't happen anymore. ColdFusion needs a very serious spring cleaning to get the cobwebs out. It also needs a complete marketing overhaul including a name change. Let's stick to the real problems, and let's move forward.

  • Justin Carter

    To those lamenting the query support in cfscript, I wrote a blog entry last weekend which you might be interested in reading, about the use of CFML tag literals in cfscript:
    http://www.madfellas.com/blog/index.cfm/2011/1/26/...
    I've also logged an enhancement request (ticket #86199, which is linked in the post) which you can vote for on the ColdFusion Bug Tracker if you like the idea.

    I'm going to repost a few points worth considering from one of my comments a few days ago when Ben mentioned server-side ActionScript in ColdFusion:

    - What problems does cfscript have that ActionScript would solve? (And in this case, would it inherently solve the issue of verbosity of cfquery, or allow the use of custom tags?)
    - Would changing to ActionScript actually bring important new features and improve developer productivity compared to cfscript?
    - Why not server-side JavaScript instead/as well? (Wouldn't JavaScript's developer base be larger than ActionScript's? There's a target market right there!)

    (part 1 of 2)

  • Justin Carter

    (part 2 of 3?)

    Personally I'd be hesitant to go down the ActionScript path as I've never had any intention of using it for client-side development, let alone server-side development. JavaScript is probably much more enticing to a wider range of developers, including myself. I realise this goes against the grain of what Adobe would be thinking internally, as far as broadening the integration of their products, and perhaps that's what makes it a hard discussion.

  • Justin Carter

    (part 3 of 4?)

    Overall, I think cfscript is in pretty good shape, it just needs to go the extra 10% for it to feel truly complete. There is some ugliness and confusion with knowing whether some parts of the language are keywords with "attributes" or functions, and this probably needs to be sorted out in the next version of ColdFusion (yet somehow be backwards compatible).

  • Justin Carter

    (part 4 of 4)

    If Adobe's top secret "go big or go home" plans for CF10 was server-side ActionScript rather than improvements to cfscript, I think I'd be calling for a quick rethink :P The "go big or go home" plans need to be refinements to cfscript, and performance, performance, performance! And "cloud". Everyone needs "cloud". Or "cloud 2.0" even, yeah, that'll be awesome :)

  • Andrew Scott

    This is a very interesting topic and one that I am sure is going to see so many people want ActionScript, after doing some flex development I can now understand why some people are in favour of this.

    However I am not one of these people.

    The reason behind this is because the cfscript actually could have a lot more potential than it has now, by going the way of java'ish/javascript code.

    One of the things that I felt that cfscript lacked was the feature where I could write something like this.

    <cfscript>
    import java.io.*;
    try{
    // Open the file that is the first
    // command line parameter
    FileInputStream fstream = new FileInputStream("textfile.txt");
    // Get the object of DataInputStream
    DataInputStream in = new DataInputStream(fstream);
    BufferedReader br = new BufferedReader(new InputStreamReader(in));
    String strLine;
    //Read File Line By Line
    while ((strLine = br.readLine()) != null) {
    // Print the content on the console
    System.out.println (strLine);
    }
    //Close the input stream
    in.close();
    }catch (Exception e){//Catch exception if any
    System.err.println("Error: " + e.getMessage());
    }
    </cfscript>

    Being able to just drop code from java into CFScript like this would actually be a hell of a lot useful than moving to ActionScript, everytime this subject comes up this is the first thing that I think about becuase with so much code out there in Java, and solutions we can't really use them to great effect. We can libraries, but not small code like this inline to our page.

    The added benefit also, is that one then becomes oblivious to what is actually Java and what is actually ColdFusion, because ColdFusion wont have the need to create tags/functions like fopen/fclose any more because it would already be usuable.

    #21Posted by Andrew Scott | Feb 4, 2011, 11:39 PM
  • Brian Panulla

    I'll see Sean's comment on the pain of mandatory single quotes, and raise you post-var typing with colons (like ActionScript, Scala) rather than pre-var typing (like Java).

    I recently rewrote a very CF5-ish CFScript function to make it a little more testable and readable, and decided to add typing to the parameters - the function accepted a query, and there was no point in allowing other types in and trying to handle them on the fly. I was really disappointed to see that argument typing in CF9 was done via Java style.

  • John Bliss

    > There are hundreds of thousands of Flash developers and designers out there (far more than there are ColdFusion users actually)

    This:

    http://www.adobe.com/products/coldfusion/pdfs/cf_e...

    ...claims, "778,000 developers." Are we talking about 900,000 Flash users versus 778,000 CF users?

  • John Farrar

    CFScript works, but there would be advantages to having a grovy type ability of using other scripts. JavaScript for those who want it and Actionscript for those who want it.

    Personally what I would like in CF10 is the ability to interact with Blaze (LIveCycle) with a IDE practically anyone can set up without fail. Things like that would be great game changers. No matter how friendly the code is configuration has been a road block to growth in these areas. 37Signals understood this when they choose convention over configuration as a methodology of choice.

  • Mike Kelp

    I fully agree with your comments Ben. Also, for those arguing about ActionScript vs. JavaScript, please remember that both implement ECMAScript standards (in fact, ActionScript is way ahead on that) and ActionScript is OPTIONALLY strong typed.

    Personally, I'd love to see OPTIONAL strong typing implemented in both the script and tag-based syntaxes because dynamic types are very much the hammer where everything is a nail right now, and should be used on a need basis, not all the time. Honestly, how many times do you set a variable as a number and then change it's type to a date within your code. For the speed and self documenting features, you would get, strong typing would be nice on quite a few occasions.

    I also like how ActionScript extends that feature to classes as well, allowing static / dynamic classes.

    Anyway, the only thing I don't really want to see is a .Net style bastardization of scripting in 50 different languages in the same code file. This is something that is much more up to developers to control though and I would remind everyone to deeply consider when mixing languages to choose them for their strengths. We don't need any more general purpose languages like JavaScript, Python, Ruby, etc. that have no specialty and perform slowly. When they are all on top of Java or .Net, at least they get a speed boost. One scripting language like JavaScript or ActionScript will do the job for your project using large logic blocks, or one that is directly focused at data mining for some applications. Purpose should come before playing with new toys. Too many times have I opened code nowadays and seen 3 or 4 languages with no real benefit to their usage in one project.

    Looking forward to see what Adobe comes up with.

    #25Posted by Mike Kelp | Feb 5, 2011, 11:53 AM
  • Nick Walters

    Making cfscript more closely resemble JavaScript will not bring in a single new developer.

    Making it be ActionScript will bring in at least a few.

    Not hard to see where Adobe will go.

  • vgb

    The driver of this discussion seems to be the desire to use something other than tag-based CFML to code business logic, especially CFCs. Rather than modify CFSCRIPT to support ActionScript, or implement something like <cfscript language="java"> why not implement an MVC-style framework that would allow you to write controllers in any language you chose? Views would still be coded using tag-based CFML, but business logic in controllers could be implemented using Java, server-side ActionScript, server-side JavaScript, tag-based CFCs, etc., or any language supported by the Java VM.

    #27Posted by vgb | Feb 5, 2011, 05:16 PM
  • Sean Corfield

    @vgb, with CFML's excellent interop with Java - and therefore all languages that run on the JVM - it's very easy to build your Model in some J-language and use any of the existing CFML frameworks to build the View-Controller portion and call down into the Model.

    I've used that very successfully with a Groovy Model (built with Spring and Hibernate - and used as the backend of both a Flex app and a Model-Glue CFML app) and I've also used Scala for some model components (where I need high performance XML manipulation, for example).

    I've been experimenting recently with a Model written in Clojure and I'm liking that a lot (immutable state and small functions makes unit testing much easier - and higher order functions make reuse and composition easier too).

    For frameworks that can use Dependency Injection for their controllers, it should be possible to use a bean factory that allows J-language beans so that even controllers could, in theory, be written in the J-language of your choice...

  • Russ Johnson

    I agree with parts of what TJ is saying. I would love to see Adobe focus more on the core language for CF10 and stop trying to squeeze in tons of features that frankly end up "underwhelming".

    I personally like CFScript but only now in CF9. I write all of my models and controllers in pure script CFC's and use tags in the view. I would welcome a change to either javascript or actionscript as a replacement as long as a standard is set. I really dont want to lose my script now that I finally have it!

  • Aaron Neff

    I was given a few CF 4.5 tutorials at a college internship, after studying HTML for a couple years. But I _really_ began in CFMX (6) after graduating (and have been addicted each day since!!). The reason I mention that is this: I don't have quite the same broad background experience in other languages (or even prior versions of CF) that others here have. I definitely respect the knowledge that the others have, and likewise acknowledge that many good points have been made on all sides.

    Thank you for posting this, Ben. CF's history has always intrigued me. It is understandable that as the CF team changes over the years, it can be somewhat difficult to maintain consistency in language development. So establishing a standard to base CFS on, and sticking to it, would be a good thing IMO.

    ActionScript, it's always remained next on my TODO list.. I'd used it in some Flash. I really got into it more when CF Flash forms came out. Then I've dabbled in Flex. But, my primary focus has always been on CF. ActionScript, you're next! That BlackBerry PlayBook has got me psyched!!!!

    So when I say +1 to CFS looking like ActionScript, that is where I'm coming from. Having <cfscript language="java|actionscript|javascript" would be interesting. I could understand language="java|actionscript" more. But anyhow, for me personally, I'd prefer the ActionScript route (at least to start w/).

    Thanks!,
    Aaron

  • Aaron Neff

    Forgot to add.. Maybe it'd be good to allow default CFS language to be defined in Application.cfc (to allow existing CFS to run)?

    Thanks,
    -Aaron

  • Mike Collins

    Seems like a timely discussion. If I know Ben, he would not mention a topic unless someting was happening to address it.
    I would not be surprised to see some CF and Actionscript blending.

    To me the big news would be Actionscript interpreted to Java. CF would be the obvious product to capitalize on this but it seems a bit more global then CF.

    I also wonder if Adobe ever thought about running the Player VM on the server, and run actionscript inside the Flash VM.
    It makes me also wonder if a server side Flash VM, in time, could ever equal a JVM?

  • Ben Forta

    My comment about the numbers of Flash and ColdFusion developers started to become a distraction, so it's been reworded.

    And now back to our regularly scheduled discussion.

    Oh, and I will respond at some point, for now I am loving the debate.

    --- Ben

    #33Posted by Ben Forta | Feb 6, 2011, 10:20 AM
  • Sean Corfield

    I'm going to reiterate my question because no one seems to be answering it:

    "what _specifically_ [would folks] want to change in cfscript to make it more like JavaScript and/or ActionScript"?

    I see comments like "I'd prefer the ActionScript route" and "would prefer CFScript being implemented with ActionScript" and "I think ActionScript-like CFScript would be the better choice" and "I would welcome cfml scripting as server side Actionscript" and "+1 for the server side ActionScript" - but what do you mean by that? What features from ActionScript do you want in CFML?

    I can see an argument for optional static typing in CFML - but not all of the existing CFML types have an AS3 equivalent so how would you expect mixed static and dynamic typed expressions to work?

    Do you want AS3's class syntax and model? How would you expect it to mix with CFML's dynamic component model?

    Brian made a great point about function declarations: CFML uses Java-style (TypeName var) whereas AS3 uses var: TypeName (in common with a lot of other languages). How would you expect to mix / reconcile those?

    I can totally see why Adobe would want to offer server-side AS3, to draw in a portion of the two million Flash/Flex developers but backward compatibility means keeping cfscript alive for the foreseeable future, in order to protect upgrade revenue etc. That means the only way to do this is to _add_ AS3 as a second 1st-class scripting language to ColdFusion, increasing ColdFusion's footprint - and increasing a layer of complexity to support interoperability between the AS3 type model and the existing CFML type model (or else introduce lots of new functions that operate on AS3 types, rather than CFML types).

    Then there's the question of how much of the standard AS3 language library would have to come across to CFML to support programming idioms that Flash/Flex developers expect to have available - ArrayList / ArrayCollection / etc. Not that CFML wouldn't benefit hugely from a decent collection class library (and closures!).

    Of course, it could be argued that no matter how horrible a mixed CFML / AS3 programming model might be to work with, in some ways we already have that - but the boundary today is BlazeDS / LCDS and data is explicitly marshaled back and forth between the two worlds. What would the world look like if CFML components and AS3 classes could be mixed together server side? Where would all that marshaling take place and how would it perform?

    I can see value in a full server-side AS3 implementation but as a separate server product and I think the Flash/Flex experience has shown that the footprint could be dramatically smaller than ColdFusion is today.

    Definitely an interesting discussion tho', as Ben says. I'm looking forward to hearing some more _specifics_ about what the combined language platform might look like because I'm not sure folks (outside Adobe) have thought it thru all that far...

  • Scott Barnes

    @Sean:
    CFSCRIPT vs AS3 seems to be a damned if you do, damned if you don't response. I think personally, Adobe should just bite down hard on the AS3 bullet and push it into the CF space more aggressively. Yeah it increases the footprint but given the market share of Coldfusion it's something in which can only bolster their footprint within the market vs where it's at now?

    I also think given HTML5 is being an aggressive player even more so in the next 3-5 years Adobe could potentially stand a greater chance of attracting others to the fold given this new approach - ie entice the JavaScript like crowd to the cause (if positioned / evangelized correctly).

    Marking CFSCRIPT as being deprecated and moving on is harsh but in the end welcome to the world of technology where nowadays nothing is ever forever... even Java / Oracle has that big question mark above its head ("where's this train going anyway").

    MY thinking is - Adobe Coldfusion Product + Community could only grow with ECMA on the server-side.

  • Justin Carter

    I'm with Sean on wanting to see more specific examples of what people are *really* after with server-side ActionScript. Some people have mentioned things like easier LiveCycle / BlazeDS integration, writing value objects once and being able to use it in Flex (Flash) and on the server-side - but the same could be said for JavaScript and Ajax applications.

    If Flash and Flex developers don't already use ColdFusion for their server-side stuff then I'm not sure they are going to start if/when ColdFusion implements ActionScript as an alternative server-side scripting language. CF is probably the easiest tool for the job already, so perhaps they have other reasons for not choosing it - the lack of server-side ActionScript isn't it though, IMO.

    I'd also reiterate what others have mentioned about CF going on a diet :) We really want performance. Make ColdFusion lean and mean. Make it fast. Let us strip out the things we don't use. My comment about "the cloud" above was quite tongue in cheek but that's where things are heading, and being able to run a lean mean CF server in the cloud is important for the future.

  • Aaron Neff

    Just read Justin's blog posts on C4X. Very interesting indeed. It seems to resolve a particular growing issue in a seemingly quick/simple way: the issue of jumping out of script components for not-yet-implemented-as-script tags.

    Also just read Andrew's blog on mixing CFS/Java.. also neat/useful.

    Regarding ActionScript/CFS specifics, I'm still mulling this all around. Honestly, yes, I hadn't exactly thought it thru that far. I do like the idea of being able to take knowledge of CFS and jump right into writing AS3 code. Somehow existing CFS would still need to run, IMO. Especially if there isn't unanimous support for this switch. ..b/c that could really upset ppl and/or catch them off-guard, and end up being bittersweet.

    Truly a good discussion to be had. The combination of the above 3 topics could result in a pretty powerful/potent mix of a feature! ..if it can be pulled off. Anyhow, it's late, or early depending on tz, and my concentration is nearing zilch! I'm also interested in any other discussions around this.

    Thanks,
    -Aaron

  • Tony Nelson

    I would much rather prefer all efforts going towards improving the performance of ColdFusion (it can _always_ be faster) than trying to rewrite cfscript, especially since it isn't broken by any means. Closures, blocks, and anonymous functions would be great additions, but merely icing on the cake. We really need to get to a point where performance isn't a constant concern, but unfortunately we're not there yet.

  • Brian Panulla

    Another item I really feel is missing from CFScript are elegant for-each-in loops. The ability to var-scope variables in the bodies of functions is nice, but I'd wouldn't even have most of those temporary variables if the CFScript loop constructs were more expressive (i.e. functional-programming style).

    Also, a nicer XML API patterned after ECMAScript's e4x (or Scala?) would be fantastic. Moving back and forth between Flex and CF in a CF-backed Flex app that uses XML as the main serialization makes my brain hurt.

  • Jeff Gladnick

    DISCLAIMER: I understand many people, all smarter then I, prefer cfscript. I've been wrong before, but.....

    I shudder every time I hear CFSCRIPT and have practically banned it from all projects in which I have the ability to do so. I have nothing against languages coded in that style, and as Ben assumed, I am one of the CF developers that use Javascript every day.

    But IMHO, it just makes no sense to have two versions of the same language. It complicates things for no reason. I can't take a snippet of code and dump it inside of a for loop if its in cfscript, i have to rewrite the code.

    For too long, cfscript couldn't do what the full tag-based language could. Now it seems to have caught up, but what's the point. Are we supposed to do all new development going forward using cfscript if we like? Then integrate CFC libraries or open source projects from Riaforge based on the tags?

    I feel like its the kind of problem that's never going to get solved, and we're just stuck with this bastardized, duplicate version of the language hanging around, demanding attention and resources.

    I wish it would die.

  • Don Blaire

    I also use Javascript everyday. It would be advantageous to have cfscript be like javascript.

    #41Posted by Don Blaire | Feb 7, 2011, 04:18 PM
  • Brian Kotek

    There would obviously be huge advantages for Adobe to use a common language across all of their tools. We already have AS3 for RIA work, you can write custom extensions for the CS5 suite in AS3, customize Acrobat/PDFs with AS3, etc. Adding server-side scripting to this growing list makes perfect sense.

  • Justin Carter

    @Jeff Gladnick: The point of cfscript is that it's useful and you can choose to take advantage of it if you want to. It lets developers be more productive. Lots of people were worried that bringing cfscript up to scratch would be wasted development time and I think they've been proven wrong - some of them have completely changed their minds (just re-read some of the comments above!).

    The same could be said here for ActionScript, but I think it's a far bigger leap - different syntax, different type system, different data structures, etc. I'm guessing Adobe would try to expose the CF scopes, data types, functions, etc to AS somehow, but I just get the feeling that it would be bastardising AS3 :P

  • Sean Corfield

    @Brian Panulla,

    You know you can var-declare in a for loop?

    for ( var key in someStruct ) ...

    for ( var element in someArray ) ...

    for ( var i = 1; i <= n; ++i ) ...

  • TJ Downes

    I agree with Brian Kotek's point of a common language across tools. I rarely touch CF anymore because I am focused on UI development. When I do switch to CF its a pretty big shift. I'd love it if I didn't have to make that shift.

    While I am not opposed to cfscript, it never feels right when I am coding cfscript. Sure, its a lot more concise and easier to read for non-view code than tags were, but it doesnt feel familiar like working with JavaScript, AS3 or even other server-side scripting languages like Groovy and PHP.

    #45Posted by TJ Downes | Feb 7, 2011, 08:01 PM
  • ahsan

    I think cfscript should continue to support all the cfml tags with Java (not Java like) syntax because it just makes sense.

    In addition, adobe should also open up and have it readily accessible of all Java APIs used in CF.

    Developers should have the choice of using Java API or CF API while coding. This would not only gain popularity among Java Developers but also among CF Developers. Also, I think it would help industry to open up doors to have CF as their primary support form.

    I do not think it makes sens to have JavaScript notion on CF because it's a prototype based language. ActionScript on the other hand may make sense but that would mean mixing two different symantics/grammers.

    In short Java in cfscript makes sense to me.

    #46Posted by ahsan | Feb 8, 2011, 02:42 PM
  • Sean Corfield

    @TJ, can you elaborate on this "it doesnt feel familiar like working with JavaScript, AS3 or even other server-side scripting languages like Groovy and PHP" - what aspects of cfscript don't feel familiar? What _specifically_ are differences that trip you up?

    @ashan, "I think cfscript should continue to support all the cfml tags with Java (not Java like) syntax because it just makes sense." - I take your points about JavaScript (prototypes) and ActionScript (semantics) being different but could you elaborate on "Java (not Java like) syntax"? To me that means requiring types and semicolons and a lot of "syntactic noise" that, say, Groovy doesn't have (to pick up on TJ's point) and even JavaScript has (prototypes aside, cfscript and JavaScript are similar enough syntactically, yes?)

  • Justin Carter

    I got an email notification with a reply from Bill Davidson but it doesn't seem to have appeared here yet... Strange?.. He had some good points. Anyway, to quote one of them:

    "While I love having the CF9 script-implemented functionality of a lot of the CFTAGs, just redoing them in tag-based CFCs seems like a copout. I can't imagine these perform that well. Would like to see some tests... In the meantime, I use them, but do have my concerns regarding performance."

    The answer is, yes they are slower. I was running some tests last weekend and, not surprisingly, the method of using the new Query object in cfscript is slower in both CF9 and in Railo 3.2 compared to just using a cfquery tag. It's partly because each query requires two objects (the first is the Query.cfc object and the second is the resultant object from calling .execute() which is what the actual query result set) and partly because of the string processing and looping that needs to happen to build the query and then finally pass it off to a cfquery tag (it's the super.invokeTag() call at the bottom of Query.cfc).

    I don't have any figures here at the moment but even with as little as 10 queries on a page I found the CF9 performance to be almost 3-5 times slower. We're only talking 10's of milliseconds, but at scale it's not really a good thing. Also, the alternative method that Railo 3.2 has for doing queries in cfscript seems exactly as performant as using the cfquery tag - which is what you would expect of a native implementation rather than a CFC wrapper :P

  • ahsan (techfuser@gmail.com)

    "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 trying to mimic Java class creation methodology in cfcomponent, cfscript should concentrate on Java class creation methodology-even syntactically.

    Leaving out the core feature of JavaScript which is the notion of prototyping and trying to compare cfscript with JavaScript isn't too convincing, at least to me. However, I would agree that cfscript is a lot more like JavaScript even ActionScript. I see a trend that eventually JavaScript and ActionScript would end up looking quite smiliar as they keep supporting ECMAScript.

    #49Posted by ahsan (techfuser@gmail.com) | Feb 9, 2011, 09:24 AM
  • ahsan

    @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 trying to mimic Java class creation methodology in cfcomponent, cfscript should concentrate on Java class creation methodology-even syntactically.

    Leaving out the core feature of JavaScript which is the notion of prototyping and trying to compare cfscript with JavaScript isn't too convincing, at least to me. However, I would agree that cfscript is a lot more like JavaScript even ActionScript. I see a trend that eventually JavaScript and ActionScript would end up looking quite smiliar as they keep supporting ECMAScript.

    #50Posted by ahsan | Feb 9, 2011, 09:32 AM
  • ahsan

    @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 trying to mimic Java class creation methodology in cfcomponent, cfscript should concentrate on Java class creation methodology-even syntactically.

    Leaving out the core feature of JavaScript which is the notion of prototyping and trying to compare cfscript with JavaScript isn't too convincing, at least to me. However, I would agree that cfscript is a lot more like JavaScript even ActionScript. I see a trend that eventually JavaScript and ActionScript would end up looking quite smiliar as they keep supporting ECMAScript.

    #51Posted by ahsan | Feb 9, 2011, 09:41 AM
  • 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)

    #52Posted by TJ Downes | Feb 9, 2011, 01:46 PM
  • 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 see any point in cfscript implementing Java when Java already exists (and better languages already exist that you can easily use from cfscript today).

    Re: JavaScript prototyping - I agree in terms of the type system but the _syntax_ of cfscript is already very close to the _syntax_ of JavaScript and that's where I'm asking for specifics that folks want to see changed. Changing the type system (to either JavaScript or ActionScript) would be a huge shift in cfscript and I'm not sure most people are really asking for that? (except for the folks who want optional strong typing perhaps).

    @TJ, the key/value pairs are indeed ugly. The CFML Advisory Committee discussed alternatives but nothing else was "more preferred" (or "less disliked")... There are definitely tag constructs that just don't have any good script equivalent (and I mean in the overall sense, not just the specific implementations we see in CFML today).

  • 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 in CFScript requires an indexed for-loop treating the query object as a (horizontal) array of (vertical) column objects. This feels very unnatural compared to both CFOUTPUT query="" and ArrayCollections in ActionScript.

  • Freemont

    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.

    #55Posted by Freemont | Feb 11, 2011, 09:55 AM
  • Freemont

    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.

    #56Posted by Freemont | Feb 11, 2011, 10:02 AM
  • 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" / >

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

  • skeasor

    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.

    #59Posted by skeasor | May 4, 2011, 11:40 AM
  • 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!

  • Charles Robertson

    To be honest. I think there is going to be a problem satisfying 3 camps. Action-scripters, javascripters and cfscripters.

    Solution.

    Scrap <cfscript> altogether.

    Lets just use the tag based language!

    Now, I am going to get shouted at...

  • Ghengis

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

    #62Posted by Ghengis | Aug 20, 2013, 06:47 PM
  • 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.

    #63Posted by Brian Erickson | Sep 12, 2013, 07:29 PM