Why ColdFusion is a Dead Language
Community. I don’t know why this would even be controversial in 2019, but some people have a lot of difficulty in recognizing reality and despite whatever bells and whistles the language has built into it — those things did not save the language and the community from shrinking year over year.
There are other reasons than just community however, such as the licensing issues of the language, the tag based nature of the original language before it added cfscript, and while some older developers are happy to use the tag base most other programmers are not. In fact tag based languages are simply harder to read, maintain, and collapse code and all of those things matter a great deal. This is a real problem too for new comers, and old codebases, because they’ll have to switch back and forth from wildly inconsistent coding styles and structures.
Here’s the other kicker though to the bells and whistles built into the language, whether it’s pdf, xls, image manipulation, ftp, imap, or pop related… ALL of those things are unnecessary for a language to thrive. Languages are better off being light, and concise about their purpose — when you start building large components in you muddy the waters, and chances are very good that the built in implementation of these things will not be as good as a 3rd party module or implementation that focuses on just that. We could even get into some philosophical debates about the linux perspective on keeping things small and focused on doing just one thing well.
If you ever tracked the progress of the ColdFusion language as they added cfscript you would have also noticed that they did not convert all of their tag based parameters into cfscript at once. Also some of the builtin features lauded by the ColdFusion community were stripped away entirely as you look at the free Railo or Lucee implementations due to licensing and proprietary reasons from the Adobe corporation. Another reason developers should be spending more time on finding 3rd party modules to accomplish their tasks independent of the language itself.
Despite whatever claim a developer may make about “costing” their clients more if they had to use another language… that simply is not true. It may cost that developer more time to have to learn about new libraries initially, but those costs are quickly recovered with experience. There’s also only so many built in features these developers are re-using, so if it is a matter of learning about a half dozen new libraries then I say get to work and learn it already.
One definite benefit though that ColdFusion does give the developer is a sense of locking in their client to using them in the future. ColdFusion does indeed do that, but that is not a benefit to the client — and once a client finds out, and they will eventually find out, they will be quite upset to learn that they’re unable to find other developers willing to work on and collaborate on the codebase they’ve spent thousands of dollars on and countless hours.
In an ideal world clients will always be happy and never seek out other developers, but that’s not the world we live in and sometimes developers need to move on for one reason or another and if you placed your client with ColdFusion then you essentially placed your client on a boat with no life jackets — you are responsible for that. Trust needs to go both ways, despite whatever experiences you’ve had with other clients, and if you are purposely shoving your clients out to sea without any life jackets then what happens to you & your reputation, as a developer, when somebody drowns will be well deserved.
If you are a developer and you are writing completely new projects for clients in ColdFusion, Railo or Lucee please stop. There was a time when that decision was defensible and even good, but that time has come and gone a long time ago. And there may very well be things that you absolutely love about it still, but there’s literally nothing in that language that can’t be replaced with just a little more effort and it will only benefit you, your clients or employer.
A good developer doesn’t need to place himself or his clients inside the silo of a dying language to make himself valuable, a good developer sees the value in large, and healthy communities and leverages that to everyone’s advantage.
The ability to hire and collaborate with others with a fair amount of ease is not just the sign of a good developer, but someone with good reasoning skills. You don’t just pick your language, libraries or frameworks on technical excellence, or a feature checklist alone, you also pick it based on the community surrounding it and the helpfulness of that community. You pick it because it has legs, perhaps proven to work well in existing & recent projects, and looks to be something that will have inertia & support in the future. Sometimes we still get it wrong — but that is ok. A decision that is sometimes wrong later on is always better than a decision that is and was knowingly wrong at the start.