Skip to main content
August 19, 2008
Answered

Are there advantages in using CFSCRIPT over CFTAGS?

  • August 19, 2008
  • 8 replies
  • 2094 views
Hi!
My app. has many CFScripts in it and almost can't find anything written in javascript. I read about cfscript and it is not a client side scripting, just like cf tags it goes to the CF server for processing.
So my question is why bother using cfscript? what is the advantages in using cfscript rather than cf tags?

Maybe this application doesn't need to be coded in javascript but still in that case why the previous developer bother using cfscript instead of just use regular cftags. Is there many advantages in using cfscript and I just don't have enough knowledge to know these advabtages?
For me, I found it easier to debug when using cftags because I can cfdump everything?
This topic has been closed for replies.
Correct answer Newsgroup_User
A code example just because I wanted to.

<cffunction name="dumpMe" output="yes" returntype="void">
<cfargument name="someVar" required="yes" type="any">

<cfdump var="#arguments.someVar#" format="text">
</cffunction>

<cfscript>
anAry = ['one','two','three'];
dumpMe(anAry);
</cfscript>

8 replies

WolfShade
Legend
July 10, 2020

I've read all the replies, here.  Just adding my two cents.

 

For me, there are no readability issues between the two.  I can read code within CFSCRIPT tags just as well as I can read the HTML-style CFtags.

 

However, one thing that I do really like about CFSCRIPT - not having to use CFSET when you have a bunch of variables.

 

This:

 

myVarA = "foo";
myVarB = "bar";
param name="session.id" default=myVarA & "." & myVarB;
request.dsn = "fubar";
application.pageSize = 10;

 

 

is less typing than:

 

<cfset myVarA = "foo" />
<cfset myVarB = "bar" />
<cfparam name="session.id" default="#myVarA#.#myVarB#" />
<cfset request.dsn = "fubar" />
<cfset application.pageSize = 10 />

 

 

Now, five variables isn't a lot.  But imagine you're setting 50 variables.  Which would you rather do?  🙂

 

On the flip-side, CFSCRIPT code looks too much like JavaScript.  Which, at the surface, isn't a big deal.  But then keep in mind - JavaScript (and most other languages) uses zero-indexed arrays; CF uses one-indexed arrays.  Maddening when you can't (immediately) figure out why your code keeps throwing errors like "position 6 doesn't exist".

 

V/r,

 

^ _ ^

Participant
July 10, 2020

You can still debug in cfscript, It's just not called "cfdump" there, instead it's a function called "WriteDump" and you can CFOutput with "WriteOutput"

Afaik, these days, there is nothing you can do with cftags that you can't do with CFScript except for maybe custom tags, but you can use modules and everything in CFScript, so probably even then you can still use CFScript for everything.

Imo, it's a lot easier to do code logic in CFScript, Switch, If, Else, functions, etc etc, so I just stay in CFScript pretty much the whole time.

Known Participant
December 14, 2009

I like what Adobe has done with CF9 and full scripting syntax support, but IMO the cleanest way to write SQL within your app is within the cfquery tag. You can't do that for a 100% script-based CFC, and you end up having to mixing up string variables or perhaps even going the ORM route. This could be a downside if you like seeing your SQL code colored.

On the flip side, I've heard it argued that all SQL should be within stored procedures, so if you don't plan on writing SQL at the application layer, it's very feasable to write all your business logic using cfscript syntax.

Pre-CF9, the cfscript vs. CFML (tags) is mainly an issue of what you need to be able to do. Between CF5-8, cfscript is a subset of what's available in CFML, so some tags cannot be run accessed using cfscript. Regardless, cfscript is much cleaner to look at and does not generate any output until you use the WriteOutput() function.

Inspiring
August 19, 2008
> At one time, it was theorized that <cfscript>...</cfscript> code ran a
> tiny bit faster then tag code, but that was back in the C++ days

CFScript was *substantially* faster in CF5 and earlier. Not "a tiny bit".

> before
> the current Java versions.

It was still measurably and beneficially faster until CFMX7.

There's no difference now, other than non-obvious differences in how
<cfloop> and for() work, and that sort of thing.

To the OP, you might prefer using CFML tags, but I find them ugly,
unnecessarily verbose and completely out of place for most of the code I'm
writing. When mixing HTML and CF code, tags make sense. However we try to
minimise the intermixing of the two, keeping processing separate from
output, in which case tags are not - in my opinion - a sensible construct
to use. I also find ECMA-style code much easier to read that all the <CF>
taggy nonsense CFML requires.

But the difference is a trivial one, and it's very much a personal
preference.

--
Adam
August 19, 2008
Ok now I understand. My app was written awhile ago, maybe that was when the cf still in a much older version. Thanks for the debugging techniques.
Inspiring
August 19, 2008
easier to type and read. For debugging, you can use the writeoutput function.

Also, if you are doing switch/case stuff, you have a bit more flexibility with cfscript.
Newsgroup_UserCorrect answer
Inspiring
August 19, 2008
A code example just because I wanted to.

<cffunction name="dumpMe" output="yes" returntype="void">
<cfargument name="someVar" required="yes" type="any">

<cfdump var="#arguments.someVar#" format="text">
</cffunction>

<cfscript>
anAry = ['one','two','three'];
dumpMe(anAry);
</cfscript>
Inspiring
August 19, 2008
At one time, it was theorized that <cfscript>...</cfscript> code ran a
tiny bit faster then tag code, but that was back in the C++ days before
the current Java versions. Now a days, both forms are compiled into the
same Java byte code so there is no performance differences.

So now it is just personal choice. Some people like the look of
<cfscript>...</cfscript> code. I personally use it when I am doing
heavy processing rather then heavy display outputting. But there is
nothing wrong with using tags for the same thing, and as you note there
are some things that can only be done in tags.

A workaround is that one can easily put the tags inside a user defined
function and call that function from within <cfscript> code.