So this blog is a bit of a spill over from a Twitter conversation I had today with Stefan Mischook, a PHP programmer and maker of all sorts of training videos at www.studioweb.com and www.killersites.com.  A few years ago, Stefan uploaded a video blog to YouTube titled "Should you learn Coldfusion?" (sic) where he presented a not-so-glowing review of ColdFusion through the lens of circa 2003.  I've seen the video before come up in YouTube searches.  Part of that is a testament to the pathetically small amount of actual CFML content on YouTube.  While I've recorded a number of screencasts and webinars that are posted online, they're all on Vimeo or Adobe Connect so alas I'm not contributing to that specific site.  

Update: Stefan has posted a new video in response.   http://youtu.be/n8qGnohyuLQ

None the less, I watched it a while back and disagreed fundamentally with many of the basis of his discussion but I just ignored the video.  Well, last night will trawling YouTube for audio clips of Adobe employees who have worked with ColdFusion for my "CF Sound Board" that I'm building into my CFClient mobile app that silly video kept coming up in the results. I commented on the video in a bit of frustration which led to a good discussion on Twitter.  Stefan asked me to clarify my comment that "Your video was just plain misinformed" which was going to take more than 140 characters so I thought I would write up a post to elaborate on the details.   

The More You Know...

I'll preface this by saying, Stefan-- I do apologize if I came off as a bit of a jerk on YouTube.  I may have typed that initial comment in a frustrated frame of mind.  If you haven't noticed, I really like CFML and I unfortunately see a massive amount of misinformation, or just plain outdated information about CF and it bugs me.  Sorry for taking some of that out on you.  You seem like a pretty level-headed chap and I appreciate the work you do for programmers in general, even if it is for PHP :)  Nonetheless, you asked and I think it's a good opportunity to continue the discussion so the next time you're asked about ColdFusion, you can come at it from a 2015 viewpoint (even if you still don't care for it).

Talking Points

"Why should you learn Coldfusion?"

It's actually ColdFusion, with a capital "F".  I know, it's kind of silly but that bugs us as it's easy to spot someone who's not familiar with the product.  (Fun fact, it used to be Cold Fusion with a space, just like the theoretical low energy nuclear reaction.)

"I hesitate to call it a language"

You shouldn't hesitate.  It is a full, turing complete language.  Well, technically CFML is the language.  ColdFusion is actually a trade mark currently owned by Adobe that refers to their application server that runs your CFML code.  More later on why that differentiation is important.  You may not care for its syntax, operators, keywords, or structure, but the CFML is absolutely a language.  It supports

  • all the typical flow control and decision tree structures
  • classical object oriented patterns (before PHP, mind you)
  • user-defined functions
  • recursion
  • closures
  • fancy operators (ternary, "elvis", etc)
  • regular expressions
  • data structures (indexed and associative arrays)
  • data formats (XML, JSON, lists)
  • locking mechanisms

Hopefully you get the picture.  You'd be hard pressed to find a common structure, pattern, or expression that is not represented clearly in CFML.  And to be clear, most of the items on my list above aren't even required to be a "language".  Heck, even this is a language.  My point is that not only is CFML a full-fledged language, it's on par with every other mainstream language.

"It's a server side technology that competes with Ruby, PHP, java, .Net, so on"

More less.  You can build web sites with each of those in the list, but CFML was the first in Rapid Application Development. It's definitely more in the PHP and Ruby space.  Java is a general purpose language wrought with boilerplate, but I think you and I agree on that.

"For every ColdFusion job that's available there's probably 10,000 PHP jobs and 7,000 Ruby jobs, and 10,000 Java jobs."

You are correct that there are more PHP and Java jobs, but you are very, VERY off in your comparisons. A quick look at Dice.com shows the following breakdowns:

  • CFML -- 131 jobs
  • PHP -- 2,075 jobs
  • Ruby -- 1,792 jobs
  • Java -- 12,927 jobs

First, you seemed to over sell PHP a bit.  Java is kicking all our butts.  Secondly, there are about 15 times as many PHP jobs, not 10,000 times as many.  Lack of jobs is actually one of the better arguments against CF, but for goodness sakes it's not THAT much harder to find a job.  Java is probably a bad comparison here since it's a general purpose language so most of those probably aren't for web design.  Also, I realize your video is about 3 years old but this graph from indeed.com showsn the job market hasn't changed significanlty since then with the exception of Java losing some ground.

"ColdFusion is a niche technology"

I can't disagree too much with that, however I would offer that ColdFusion is a less-visible technology.  It has always been marketed at the enterprise sector and, as such, is deeply entrenched in corporate (especially financial), government, and education.  A lot of CF code exists behind company firewalls in commercial applications that never get counted by w3Techs.  At one point, it was said 75% of fortune 500 companies used CFML though I don't know the current stat on that.  Many people are surprised to hear "cool" companies use CF like Twitter, facebook, Apple, and NASA.  It's all around us, yet people always seem surprised when they see it.

"it had it's day in the late 90's"

Nah, it was still cutting its teeth back then (as was PHP).  ColdFusion use actually appears to have peaked around 2008.  Some people just think it stopped progressing back in the 90's because it's the last time they looked at it.

"It's a commercial product, you have to pay for it"

This is where it gets fun.  It is true that Adobe's product (ColdFusion) is a commercial product.  And I'll stop right there and point out that I'm unclear on when that became a bad thing!  Tons of server side tech is commercial, especially Enterprise-focused tech.  Take Oracle, SQL Server, IIS, Windows, SharePoint ,MySQL Enterprise for example.  They're still great products and I never once hear anyone complaining about the fact that they're commercial--- as if that is somehow inherently bad!

Here's the part most people don't even know-- though it's been true for over a decade.  Adobe ColdFusion isn't the only CFML engine out there.  There are more than one atrractive open source alternatives.  My favorite of which is Railo.  It's open source, free, community-supported, professionally backed, and runs the same code (CFML) as Adobe ColdFusion.  This is the best thing that happened to CFML in my opinion, it happened years ago, and somehow no one has noticed.  

"If you have to buy the server, it's like a grand or so"

 

Well, actually it's a few grand, but pretty cheap for enterprise server software.  SQL Server Enterprise runs around $20k per license, and at one point Oracle was $40k per CPU!  But Railo (open source CFML engine) is free!  My personal sites run on Linux, Apache, MySQL, Tomcat, and Railo.  That's right, I use CFML for my blog and it costs me absolutely nothing in licensing.  For me, the pricing aspect is a complete non-barrier.  I mean, people don't run their personal blogs on Microsoft SQL Server, so they would they use the Adobe version of ColdFusion?  

You did mention shared hosting (as I'm not a big fan of in general) but I'll also point out Adobe has cloud licensing too (cents per hour) so that's another route that isn't going to cost you an up-front license:

Amazon AWS ColdFusion AMIs

"All the 'code' looks like tags"

This is probably the most often incorrect statement made about CFML and the sad thing is, it hasn't been true since version 4.  Tags were the original syntax of CFML, and yes it was to appeal to HTML developers back in the day, but I don't really see that being the case any longer in my opinion.  I LOVE CF's tags--- for templating HTML.  CFML was the first web templating engine, and I still think it's one of the best.  It's even funny to see some of the new "cool" JavaScript templating libraries like Angular looking strangely like CFML has for 20 years.  

But here's the thing, ColdFusion has also supported an (unfortunately under-used) scripting syntax since 1998 which has grown over the years.  For many years now, it has been possible to write CF applications ENTIRELY in script-- without touching a single tag.  Of course, you'd be silly not to use tags for templating-- it's what they're good at.  CF Script is very close to ECMA script and reads a lot like JavaScript or C.  Here's an example of a function written in CF's script syntax:

function convertToNamedParameters( userPositionalParams, commandParams ) {
	var results = {};
	var i = 0;
	// For each param the user typed in
	for( var param in userPositionalParams ) {
		i++;
		// Figure out its name
		if( commandParams.len() >= i ){
			results[ commandParams[ i ].name ] = param;
		// Extra user params just get assigned a name
		} else {
			results[ i ] = param;
		}
	}
	return results;
}

Betcha' didn't know CF looks like that now (and has for years)!  This is what 90% of my code looks like now when I write apps.  My views are the only place a use tags, and they're small since all the logic is in the model layer of my MVC framework.  For more examples, check out ContentBox Modular CMS.  This is a full-featured, open source, CMS (that I'm affiliated with) that's built using ColdFusion's inbuilt ORM (Hibernate) the ColdBox MVC Platform, and all the business models and controllers are script. Click these links to see how CFML programmers are coding in in the modern era:

"It might say <connect_to_database_tag>"

That would be the cfquery tag :)

<cfquery name="test">
  SELECT *
  FROM foo
</cfquery>

And of course, it's script brethren:

test = QueryExecute ( 'SELECT * FROM foo' );

Note the lack of connection strings, or DBMS-specific functions. Nice, isn't it :)

"that's the two advantages"

I'd say you're selling ColdFusion a little short if you think those are the only 2 advantages.  What about:

  • Loosely-typed for faster coding, less boilerplate, and duck typing
  • It's dynamic, classes are modifiable at runtime, supports implicit event dispatch (onMissingMethod(), etc)
  • Tons of conveniences such as generated get/sets and implicit gets/sets to remove boiler plate and clean up syntax
  • Direct Java interop with classes or entire Java libraries dropped in the classpath as a jar
  • Enterprise integrations such as Exchange, SharePoint, PDF generation, etc
  • Really easy yet powerful ORM based on Hibernate
  • Inbuilt support for SOAP and REST web services
  • Task Scheduler
  • SMS Gateway
  • I could go on...

"I think these advantages have diminished quite a bit"

Yes I would agree, but to be clear-- CF didn't "diminish", the other languages finally caught up :)  This in itself makes other languages more attractive, but doesn't take away anything from CFML in my opinion.

"It was ported at some point... I'm not sure what the date...."

May of 2002.  Codename Neo.  Guess which movie franchise was still going strong... :)

"Basically, ColdFusion is just a Java... it's just made with Java.  That's all it is."

Again, I think you're oversimplifying a bit.  Firstly, saying it's "just Java" gives the impression you can do the same thing with Java in a comparable amount of code.  Not even close.  I'm a big fan of the JVM as a platform.  It scales really well-- just look at the numbers when Twitter switched to it from Ruby.  But CF is not "just Java".  The server is written in Java, but my CFML is not interpreted to Java.  It's direct-compiled with a JIT to bytecode which is cached and run directly on a HotSpot JVM.  That means when my code runs, it has the power and speed of native Java, but I just wrote hundreds or thousands less lines of code.  I don't see CF as sitting "on top" of Java, but rather "next" to it on the JVM.  

I'll also note JVM languages are growing in popularity.  See Scala, Clojure, Groovy even JRuby or Jython.  I've never heard anyone say, "Well, those are really just Java-- so why bother using them".  CFML is the granddaddy of JVM languages, but it never gets credit as one.

"It's actually just a taglib."

No, it's not a taglib.  CFML tags have nothing to do with Java taglibs other than they both have the word "tag" in their name.  It would also be silly to imply that you could match the breadth of ColdFusion's functionality simply by installing a few tag libs on top of Java.

"What's hard about developing good applications is good application design."

I absolutely agree.

"The tag-based paradigm..., which ColdFusion obviously uses, does have its limitations as the site gets more complex"

I absolutely disagree.  Even if we were to forget for a moment that CF script exists, who's to say you can't build an enterprise-class application using a non-script syntax?  That's just silly.  Now, I might have agreed if you said "throwing all your code with no clear separation into a single file interspersed with HTML" as  many CF (and PHP) devs used to do back in the day.  Of course, that would be a travesty brought on by a lazy programmer, not one forced upon them by a particular syntax.  Nonetheless, I've already showed that the CFML I write looks just as "scripty" as your PHP, just with a far cleaner naming  convention so that point is essentially moot in my opinion.

"...and you just want to bang out sites real quickly, simple things like simple shopping cart systems, or simple contact systems..."

What makes you think CFML is only suitable for "simple" things?  If I wanted to make a "simple" site, I'd use a CMS/blog engine like the one running this site (ContentBox).  When it comes to building "real" apps we have all the creature comforts of other languages.  I work for a company that makes a lot of CF tooling so I'm obviously partial to some certain libraries.  (You might notice a "box" trend below :)

  • Object-oriented design patterns are all possible in CF including interfaces, inheritance, overriding methods
  • Several mature MVC frameworks exist, my favorite being ColdBox, which is convention-over-configuration (much like Grails) and modular so it can be extended easily
  • Pluggable caching via CacheBox
  • Enterprise logging via LogBox
  • BDD and xUnit-style testing via TestBox
  • Mocking and stubbing via MockBox
  • Convention-based Dependency Injection, object persistence,  and AOP via WireBox
  • CLI and package manager tooling via CommandBox

I develop applications using source control, unit testing, continuous integration, MVC architecture, asynchronous event-driven patterns, using NoSQL databases, REST APIs, and JavaScript libs like Angular.  I'm not bragging-- I'd like to think that all web developers who are worth their salt are familiar with and using all these techniques.  I say that since people seem to get the idea that ColdFusion programmers all sit around in caves wearing animal skins and banging rocks together.  We build the same kick butt apps you do, and I promise you CFML doesn't hold us back.

Wrap Up

So in conclusion Stefan, that's why I told you that your video was full of misinformation.  I hope you take this as informative-- I'm certainly not trying to attack you or anything.  The view you held of ColdFusion is sadly a very prevalent one and I've wanted to type of some of these responses for a long time.  You sort of just gave me a good excuse to do it.  Please feel free to respond in the comments, ask for clarification, or just bask in the glory of CFML :)

I don't expect you to go start writing CFML or anything-- someone has to manage all those WordPress installs.  But if you (or anyone else reading) wants to play with it, I'd recommend using CommandBox.  Assuming you have Java installed, it's just a 33MB download.  You can scaffold out MVC sites, install packages, and start up a server in just a couple stupid simple commands.  Or just play with the REPL.  The getting started guide is here.