Remember PUNKS NOT DEAD? That’s my inspiration for my title for this topic, which was prompted by the recent conversation between Michaela Light and Zac Spitzer about, among other things, the myth of CFML dying, which reminded me of a meme I thought of a few years ago:

<!--- What other programmers think we do. --->
<cffunction name="TagSyntaxForBizLogicIsEmbarrassing">
	<cfset foo = true>
	<cfreturn foo>
// What Lucee programmers actually do!
component displayname="ScriptSyntax" extends="ParentComponent"
hint="Text to be displayed when using introspection ..."
	public boolean function CFScriptIsAwesome() {
		var foo = true;
		return foo;

The original idea of dynamic templates, mixing the tag syntax of CFML in with HTML was a great innovation back in the day, and it’s still useful now for presentation, but it has never been appropriate for business logic. Unfortunately that is what ColdFusion developers had no choice but to do from the beginning, and embarrasingly many still do today.

Just look at code examples on Adobe’s website, Wikipedia, etc. Adobe’s tutorial even mixes the business logic of processing a form into the middle of the HTML presentation, and they reference a custom tag for the database query instead a cfscripted component. Argh!!!

The original and still persistent “Markup Language” portion of the CFML moniker didn’t help. Though markup languages can be procedural, that mostly applies to macros. ColdFusion should have been marketed as both a platform and a scripting language. CFSL? I guess “CFML” was a marketing decision because of its similarity to “HTML”, but we’ve been reeling from the repercussions of that decision ever since.

There’s also so much terrible legacy code still out there, and first impressions last such a long time. Other programmers who have only limited exposure to ColdFusion, much less the generally more professional Lucee code examples, don’t have much reason to take another look. And even when they dig a little deeper, they’re still seeing examples of garbage.

With all these issues, it’s no wonder we have an image problem.

But I love the positive spin from Michaela (starts at 1:06:53):

"What would it take to make ColdFusion more alive this year?"

Well … I have a couple ideas, both of them intended to improve Lucee’s professional reputation:

  1. From the marketing perspective we need to distance ourselves from the terms “ColdFusion” and “CFML”. Rephrasing in a way that will attract both JavaScript and Ruby on Rails enthusiasts, I suggest a purposeful publicity campaign, rebranding to: CFScript in Lucee! And that campaign needs to include strong advice that the tag syntax should only be used for presentation when mixed with HTML. And instead of saying that CFML can also be written in a script syntax, we should be saying that CFScript is the preferred syntax, but it can also be written in the tag syntax.

  2. It’s also embarrassing that we still have to enclose CFScript inside <cfscript> tags, so my other proposal is for Lucee to finally support .cfs files (analagous to .js files) as @isapir attempted to do years ago for Railo.

I know that LAS is busy with the finishing touches for the Lucee 6 Beta, but I decided to go ahead and post this now since the important issue was raised by @Zackster and Michaela.

And I hope to get some feedback and inspire other ideas. Because, hey, I was a longtime lurker, but no more! To be completely honest, last year I had been on the verge of migrating all my websites to Node.js. (Yeah I know … Boo! Hiss!) But then this year I read Charlie Arehart’s summary of ColdFusion’s modern advancements, and now with the news that the Lucee 6 Beta is finally about to be released this month (and I’m chomping at the bit to participate and in general help in any way I can), the conclusion is obvious:



.cfs already implemented


Nice! Apparently I’m not the only one who didn’t know about that because KamasamaK’s CFML extension for vscode does nothing for my first test.cfs file. Also Apache2 is rendering the source code. Which config file controls that?

That’s Lucee 6 only, I think (on a train!)

Depending on your Apache config, you need to tweak it to handle passing files matching .cf* to Lucee

Can you file a bug against the extension?

Oh well I found CFML_SCRIPT_EXTENSION = "cfs" in 5.3.9/core/src/main/java/lucee/runtime/config/ and then I added .cfs to the CFMLHandlers in modcfml.conf then restarted both Lucee and Apache2, but my test.cfs is still only displaying its source code. Either way I guess I’ll wait for Lucee 6 before trying again.


Will do!

I found the ProxyPassMatch line in /etc/apache2/apache2.conf:

ProxyPassMatch ^/(.+\.cf[cm])(/.*)?$$1$2

Changed it to:

ProxyPassMatch ^/(.+\.cf[cms])(/.*)?$$1$2

And now Firefox is trying to download my test.cfs. Progress? :thinking:

From the commit, looks like it was first added in

Is it working for you in 6?

So true! Another point is that every one was riding the wave to make everything work at the front end with SPAs and JS. Then, falling into some of the pitfalls they were looking for the “brand new innovation” to make front end js run on “server side”… And when you look at the code, cfml scripts does that for over a decade now.See this tweet

Also, as Gerd nicely also stated in one of Michaelas Video Sessions. He said something like …“Everybody says cfml is so hard, but the truth is that cfml scripting is so similar with Javascript, they know how to Javascript, but they think cfscript is so hard”. So true, I was one of those.

1 Like

You also need to tell tomcat to use lucee servlet for .cfs in the web.xml. I never tested .cfs, so I can’t tell how that will be.


Eureka! It works! Thank you! :partying_face:


It may not happen soon, but I got the ball rolling with a quick response from KamasamaK.


You are doing it wrong.

There are two parts (2) to running Coldfusion

  1. The Java application Server
  2. The Coldfusion Engine

Part 1 is Tomcat, if its anything else you are committing tech heresy, go scrub your brain with 200 hours of Monty Python and a case of bourbon and come back to us when you understand what I just meant about the above statement.
So in this part, it acts as the road which the engine runs on. The road has a context file that must understand what you want to do with your file. So someplace in tomcat install path/configpath/web.xml you will have around line 520

` <!-- Mappings for the Lucee servlet -->
	<!-- Basic SES Mappings -->

This is where you would want to add your new file to be treated as coldfusion

Now part 2, the engine just needs restarted so that Tomcat routes the correct file to the correct engine

Some of you, hell most of you and I have part 3, part 3 being a third party web server engine.

In Many cases our installs are like this

  1. HTTPD engine —> Tomcat —> Lucee ----> Webapp

The HTTPD engine can be anything from Apache HTTPD, IIS, NGINX, to just name a few, but the httpd engine is just a third party proxy engine for Tomcat. (Yes it does other cool stuff, but for illustration purposes)

Tomcat, when receiving a URL request goes down its list of known values and tries to make sense of it. So just throwing a file called CFS and hoping that by telling the Proxy engine about it, doesnt make it serve the value you want. (there are exceptions, yes but if you have one you more than likely have a security hole big enough to drive a city through) You must let tomcat know that lucee is the correct engine for that file.

Back to the above point, We do not need a massive update on the whole lucee application stack to sideload the configuration for a special language file extension.

With the above knowledge, you can have Tomcat handle all your other favorite languages (Which is heresy as there are none) :slight_smile:

1 Like

No, actually. As I stated above and with much more succinct help from @andreas, I already edited Tomcat’s web.xml and got it working.

I don’t know what “massive update” you’re talking about, but as I also already stated, support for .cfs files was committed to the Lucee repo way back in 2019. And I assume those fairly minor code changes were necessary because of how .cfs files don’t require the <cfscript> tag.

So I am doing this totally right, calling attention to an important hidden feature which very few people know about, and which needs to be added to the documentation and default config of fresh installations.


This is fascinating as someone who used CFML since the late 90s. What was embarrassing or inappropriate about using CFML for business logic?

Surely the visual representation of logic makes zero difference to its function, particularly where tags and script functions had identical outcomes?

It’s cumbersome to read, requires more keyboard typing for all those angle brackets, and tag syntax only made sense because of how it was intended to be mixed in with tag-based HTML, often by designers with limited programming experience. In the eyes of experienced software developers, it did not look professional. What’s mind-boggling is how many CF devs stubbornly defend that and even continue to ignore cfscript.

With the addition of script syntax, enforcing that for biz logic ensures visual separation vs the HTML/CFML presentation. And now that we have .cfs files, those should be used for the biz logic which then includes the presentation from .cfm templates for even greater separation.

1 Like

Nothing you’ve said here answers why it doesn’t belong in the business logic layer. I can appreciate stylistic and even fashionable opinions; or that most other forms of programming have gone down a script-based route, so developers may prefer stylistic continuity. No problem with any of that. But in my experience the sort of arguments you put forward for promoting scripting within Lucee, are the arguments made to dump it altogether.

Effectively labelling CFML the preserve of more limited programmers, is inappropriate.

And to call it “embarrassing” or “not appropriate” is either factually incorrect or pure snobbery.

Let’s reverse this and you try to debate why tag syntax belongs in biz logic.

This is like Jedi-ism… It has a light side, a dark side and in the end both sides do the same thing just from a different prospective.

1 Like

I’ve been running business logic in a tag structure for about 2 decades, it works well, behaves as it should and there’s no reason to change. But then I’m not proposing to change it.

“That’s all I’ve ever done” is not a compelling argument for why tag syntax is appropriate for biz logic. You simply did it that way because that was the only option at the time. Also I just thought of yet another reason why script syntax is more efficient, because there are fewer line breaks and extra characters for the closing tags. My observations are practical and honest, not subjective “snobbery”.