In the interests of full disclosure, I’ll state upfront that I am not a fan of
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,
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
Recently, with the releases of ColdFusion 8 and ColdFusion 9, we finally did commit engineering resources to improving
And for me? Well, for me it’s too little too late. Remember, the original intent of
So does
First, it can indeed make life easier for ColdFusion developers. At its simplest, long lists of
But in addition, there is one area where I think 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,
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
I started off by saying that I am not a fan of
I Am Not A Fan Of CFSCRIPT
64 responses to “I Am Not A Fan Of CFSCRIPT”
-
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/Using-CFML-tags-in-cfscript-C4X-prototype
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) -
(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. -
(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). -
I am a fan (in the right season only) of CFScript. Great article.
-
#ERROR!
-
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. -
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. -
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.
-
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
-
I would welcome cfml scripting as server side Actionscript! I would even welcome if it were strongly typed! Yes.. there I said it.. 🙂
-
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? -
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. -
@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 fo -
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.
-
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. -
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. -
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. -
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. -
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. -
(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 😛 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 🙂 -
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. -
> 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_evangelist_kit.pdf
…claims, "778,000 developers." Are we talking about 900,000 Flash users versus 778,000 CF users? -
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. -
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. -
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. -
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.
-
@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
-
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. -
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! -
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 -
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 -
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? -
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 -
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… -
@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 m -
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. -
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.
-
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. -
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. -
If the current CFSCRIPT was abandoned that would probably be the final push for me to learn a new language and move on.
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.
I think there are some modifications that can be made to cfscript to make it more ‘friendly’ to javascript developers and that’s where I think Adobe should go. Sean hit most of them… one slight point I would make is the requiring of semicolons is sometimes helpful. Building a long string in JS is a pain since you can’t span multiple lines. I like to be able to have line breaks in cfscript and have the variable assignment continuing until you hit a ‘;’. Although perhaps removing the requirement of the last semicolon in a code block would make it more ‘standard’…..
As far as getting rid of cfscript altogether (not that you were suggesting it, Ben),,… tags have no business being in business-logic (model/controller) code…It’s cumbersome, verbose, and really hard to read. For those resisting moving over to scripting, you should really reevaluate that. After an adjustment period, you’ll be thankful you aren’t writing a million <….>’s all over the place. LOTS of saved keystrokes, and it is SO much cleaner.
cfscript has kept me in CF. I don’t want to have to re-learn it. Please don’t force us to.
Finally – one more big vote for the ability to just drop in Java code inside of cfscript, re: Andrew Scott’s comment. That would be huge. I’ve tried integrating Java code many times and anything beyond the basic cases always becomes more frustrating than it is worth. -
I also use Javascript everyday. It would be advantageous to have cfscript be like javascript.
-
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.
-
@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 a
-
@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 ) … -
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. -
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 -
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. -
@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
-
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 😛 -
"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.
Leave a Reply