Posted by Double Compile on Tuesday, November 17. 2009
I'm a software engineer with 10 years (at the time of writing) under my belt, and my speciality is web-based applications. I have used a number of platforms to author applications of all sizes. I am an expert in PHP. I am advanced Java EE developer (and Groovy). I have used ASP.Net. I have also used ColdFusion. (To a lesser extent, I have used Perl and Python, but only once each and it's been years). I am comfortable saying I have enough experience with those platforms to give ups and downs.
The purpose of this article is to lay out the downs of ColdFusion, for in my opinion, it has few ups. To quote a comment in this blog post, "Coldfusion indeed sucks major spidermonkey testicles." This post is not a reasonless rant; I have many reasons listed below that ColdFusion should be avoided and they're pretty good. This is not another "ColdFusion is a dead language" post. Far from it, I know ColdFusion is still alive and kicking, and that is a sad truth.
I won't attempt to refute any of ColdFusion's marketing bullets, I'll just list all the things I've observed in my painful relations with it. I was originally going to shoot down any near-truths they listed, but once I began reading the ColdFusion Evangelism Kit distributed by Adobe, I had trouble gleaning any facts from the marketing fluff and comparitive numbers without sources. (Why can't everything have a Wikipedia-style  template?)
All web application developers who call a platform their home that is not ColdFusion have two things in common. They know what
null is (more on that later), and they all make fun of ColdFusion. ColdFusion developers are the furries of the programming world (no offense, furries). An acquaintance of mine that is a ColdFusion developer told me that "PHP is for smart people." This claim doesn't bode well for the CF developer community.
In his blog post "Why learning ColdFusion today is a waste of time", Aral Balkan describes the ColdFusion ecosystem thusly:
…the ColdFusion world where the promise of non-programmers creating applications creates for good marketing but crappy applications.
In a thread on the xkcd forums, the user "wing" compares PHP and ColdFusion:
Your real world differences are going to be that ColdFusion supports less, is an uglier language, is undersupported (good luck finding a webhost offering it on anything but a dedicated server), and costs money, as opposed to PHP, which supports just about everything (in 15 different ways), is supported on every webserver in the universe, and is free.
PHP can be written and maintained by most 15 year olds, and certainly damn near any real programmer who's written anything for the web in any language. ColdFusion requires a real programmer to sit down and learn it, and unless they are truly twisted, they'll hate it.
Enough of the foreplay, let's get to the details. These are my reasons for disliking ColdFusion that I've gained directly by experience.
ColdFusion is proprietary and costly
The official ColdFusion server is only available under a proprietary license. The production version of ColdFusion 9 costs US$7499 per 2 CPUs. What's the incentive when you can deploy PHP, Java EE, ASP.Net, Ruby, Python, and Perl applications into production at no cost whatsoever? (Yes, even ASP.Net, which technically could be Mono running under Apache HTTP Server on Linux instead of shelling out cash for a Windows Server license). Yes, there is also an open source project that implements some of the ColdFusion features, but not all, and good luck convincing your client or boss that you don't want to use Adobe's ColdFusion engine, you want to use a different one. [Insert open source vs. proprietary software arguments here.]
ColdFusion is basically bloat
ColdFusion is built on Java, right? Why not just write the application in Java? ColdFusion doesn't provide what Java does and more; really, it hides much of Java's power, and adds only performance overhead. If you use Flex, Air, or nurse from any other teat of Adobe's, ColdFusion may possibly help you there, but since I've never used any of those tools, I have no knowledge in that regard.
I had a very large application that I converted from ColdFusion into Java EE. In the intermediate stage, I had reimplemented the backend in Java EE and changed all of the ColdFusion templates to delegate all data access and business logic to the new backend. At that point, ColdFusion was only the front end. It had a simple MVC I threw together with controllers written in CFScript and presentational templates written in CFML. There was no business logic in the controllers or the templates. When the time came to finally ditch ColdFusion, we got rid of JRun and replaced it with Tomcat on which was deployed a front-end using Spring MVC with JSP and JSTL. The performance of the application increased by an order of magninute, even though the backend was exactly the same. (Some of this may have been due to Tomcat probably being faster than JRun).
ColdFusion is not very extensible or customizable
how the form it generates looks(not what I meant; I know you can style forms), or maybe you want to change the error display screen. Tough luck, you can't. You have to do it from scratch yourself.
As I've read, ColdFusion 9 introduced a few features that make it easy to be a cog in the corporate wheel, like interacting with MS Office documents, turning things into Flash or PDFs (no surprise being from Adobe), or connecting to SharePoint, but oops, what if you want to customize how those work
work with OpenOffice documents(a reader noted that CF9 works with OpenOffice documents, which was not readily noted in the materials I read beforehand), can you extend from anything? Nope. They also note that they've added Ajax controls that use Ext JS, but what if you want to use jQuery, YUI, or Dojo? Time to write more shit by hand.
By the way, I hope you ColdFusion developers like inefficient work. A PDF generated from HTML and CSS by the
CFDOCUMENTtag compared to a PDF generated by JasperReports with the same content just formatted differently was almost 4 times larger in filesize. As I'm told, ColdFusion 9 generates smaller PDFs, so this may not be an issue anymore
Overlook my specific examples; the real point is that you are incapable of toying with the operation of base ColdFusion capabilities. You cannot extend from the CFDOCUMENT tag to make it generate PDFs a little differently. You cannot extend the CFLDAP tag to make it connect to LDAP servers in a different way. While you may be able to write your own custom tags and components, you're going to end up reinventing a lot of wheels if you need to change anything low-level.
Yes, yes, if you do everything ColdFusion's way, Adobe's claims of it being a good means of rapid application development are somewhat true, but it may not be the most efficient solution. Remember the age-old addage: "Fast, cheap, stable. Choose any two." (In some cases, I know of apps CF and otherwise that were only allowed to pick one).
In his post ColdFusion is Dead, Dave Lowe says the following:
…[I] started leveraging components for as much as possible. From there I quickly learned that ColdFusion didn't have much more to offer, and if I were to continue using it, I would be doomed to code redundant line after redundant line. On top of that, if I wanted any modern libraries that exist in the open-source world, I'd have to reinvent those wheels myself.
Speaking of Components, let's get to the next bullet.
ColdFusion as a "language" is laughable
There's nothing wrong with a tag-based templating language. In fact, JSTL and .Net have great tag libraries for visual presentation. Notice I said "tag-based templating" and not "tag-based programming".
ColdFusion developers, if you read nothing else in this article read this paragraph. Templates are for presentation only. Business logic, data access, validation, authorization, authentication, and anything else that isn't "showing pretty stuff to the user" (database queries, form value checking, web service calls, checking LDAP or e-mail servers, etc., etc.) goes in the backend in a completely different file from the presentational template.
CFScript used to be a complete joke, but in ColdFusion 8 they actually got the increment operator (I know!). In ColdFusion 9, CFScript got the ternary operator (
boolean ? if-true : if-false), the
newconstruct (before they had
new, they had
createobject('component', your-component-here)), and actual constructors. Note, CF9 came out a month ago and these poor CF developers have been without constructors all this time. That's right, they had to call the method after creating their object to set it up.
ColdFusion has no concept of null. I'm guessing that variables in ColdFusion are stored in a glorified
java.util.Map. As far as ColdFusion is concerned, there is no difference between an entry in this map with a null value, and no entry at all. This causes problems with some of ColdFusion's advertised conveniences, notably the shorthand for using
object.getProperty(), but not if the getter returns null! You've got to use the long version for testing if a property is null. ColdFusion even pukes on some null values returned from Java. Example: I used a Java library from CFScript that returned an object array (
Object, for Java savants). You can't even work with the array if one of its values is null, it gives some bizarre error.
ColdFusion doesn't allow you to compare objects for equality. Yes, you read that correctly. You cannot determine equality for complex values like structs, arrays, and CFCs. What you have to do is make sure your CFCs inherit from a base that keeps some unique identifier, then you can compare those. Why would ColdFusion hide something so basic as object equality and identity?
How about the odd variable scope in CFCs? You need to declare all of your local function variables at the beginning of the function (even
forloops). If you use a variable without declaring it at the beginning of the function, it automatically gets assigned as a class property (what?!). Thankfully these poor bastards got a "local" scope in CF9 so they didn't have to declare all their variables at the top of the function (
local.i = 0;).
Remember in the 70s and 80s when government organizations started to regulate CFCs because they were bad for the environment? I think they were on to something.
All in all, CFScript in CF9 is less shitty than previous incarnations, but why would you even use it when there are better alternatives? Let's say there's no way the design team will let you replace their ColdFusion front end with something else because that's all they know. Put everything else in Java, and if Java is too "strict" for you, try JRuby, Jython, or Groovy, since they all compile to Java bytecode, which ColdFusion can apparently work with.
The features that ColdFusion provides — and there are some good ones — are not worth what it takes away: speed, extensibility, efficiency, and convenience for advanced developers.
I'll close with this. You can write horrible software in any language. While ColdFusion doesn't make it any easier to write bad software than any other platform, it sure makes it harder to write good software.