It’s popular to hate on CF. It’s popular to say ColdFusion is “dying”. It’s popular to call CF a “legacy” language, and compare it to COBOL. But is ColdFusion really unpopular? And, more important… does it matter?
I think most devs in the ColdFusion space know how popular it is these days to slam ColdFusion - specifically, CF's unpopularity itself. Recently, we even got a fun reference in a CommitStrip comic:
The point of the comic is to poke a little fun at CF - and that's fine! But it did get me thinking about the pervasive "unpopularity" of ColdFusion / CFML. So here’s why I don’t care whether ColdFusion is unpopular or not.
One: All Languages Fluctuate (thus all languages are "unpopular" at times)
Two examples of fluctuation in the "popularity" of programming languages - whether real or perceived.
- Ruby - no, really!
- HTML - Turns out Google Trends is a stupid way to measure language popularity
Ruby Is Not Dead
Remember that thing called Ruby? You know, the scripting language powering Kickstarter, Soundcloud, Basecamp and Etsy? Apparently these days it's cool to say that "Ruby is dead". Compared to the current rising star (once Ruby, now Node), all code is "unpopular". Take a gander at this worthless article by TechRepublic, citing the "Death of Ruby":
Ruby's popularity has dropped in the workplace and in coding bootcamps, while leaders question the open source programming language's staying power.
There it is again - popularity, that moronic metric only useful in blog posts and line graphs. The article gains some sanity when it quotes David Robinson, data scientist from Stack Overflow, with this piece of wisdom:
"Languages almost never die," Robinson said. "People build a lot of useful infrastructure in them, and those can last for decades beyond when they're essential parts of the ecosystem. It's not a question of alive or dead, but a question of growing or shrinking."
So nice of TechRepublic to admit that the entire premise of their "The Death of Ruby?" article is flawed. This is yet another click-hungry blog article with little experience and fewer facts citing the premature death of a language.
HTML Is Not Dead
Hear me out here - of course HTML is not dead, right? Right?
I had some interesting feedback on my Five Reasons to Learn CF in 2019 post from a developer who told me:
"I see a definite pattern in how many people search for ColdFusion. How would you interpret that graph?"
For reference, here is that Google Trends graph of "ColdFusion" searches from 2004-present which he was referring to:
My response was to link to the same Google Trends graph for HTML over the same time period.
So let me ask you - is HTML dead? ;)
Or is it simply that popularity is a nonsensical metric (Seriously, do Google searches count for anything?) to "rate" a programming language? We're talking about programming languages, not TV personalities!
Two: ColdFusion is Running the World
Whilst y'all dimwits call us unpopular, we're busy running the world - from health and banking to government and Telco companies. Adobe's Evangelism Kit points out that ColdFusion is utilized by over 70% of the Fortune 100. I agree that statistic should be taken with a grain of salt - after all, it is likely that many of those companies do not use ColdFusion as their main bread-and-butter tool, and may well consider their ColdFusion apps as legacy. But the kit also points out that 70% of Adobe ColdFusion customers are still building new apps with CF - meaning that they still consider the platform viable for future expansion. These are not take-your-funding-and-die-in-three-years startups, they're not Mom and Pop ecommerce websites, they are the largest companies in the world building new applications with CFML. Eat that. :)
Three: ColdFusion is too Current to be Unpopular
Many "Is ColdFusion Dead?" devolve into "ColdFusion is dead like COBOL"-type arguments. (If you really wish to see this sort of rhetoric, you can find several such comparisons in this Adobe Forum post, of all places.)
This doesn't hold up for the simple reason that dying languages aren't kept up to date! Check out the list of COBOL releases on Wikipedia - frankly, only two major versions released since 80's spells obvious doom for the COBOL ecosystem.
Contrast this with Adobe ColdFusion, with four major releases since 2012, or Lucee, with one major release and four minor releases since 2015. I mean, seriously - check out this list of tags on the Lucee Docker image. This is not how dead languages work!
Four: "Popular" Does Not Mean "Useful"
Popularity is not the end goal. I'll say it again: popularity is not the end goal! If your language of choice has a scheduled release every two years and hundreds of thousands of active developers, it won't matter one bit unless that language is useful. Node.js, as a language, is almost worthless without its immense open-source ecosystem. You won't find any real-world applications running on Node without the use of dozens or hundreds of npm libraries simply because Node is not useful in and of itself.
That's not a bad thing! Node is an excellent language to learn, and is very powerful thanks to its immense popularity and large package ecosystem - but just remember that without the ecosystem, Node as a language would be a footnote in the annals of history.
My point concerning CFML, and Lucee specifically, is that fast, easy jvm languages will always be useful and relevant. When you can build a form, process the form and send an email in an hour (and all without leaving CFML), you have an advantage which is simply hard to find elsewhere. I'm not sure an hour would be enough time for me to choose an npm package if I was using Node! ;)
Conclusion
I'm done caring about "popularity". Unless the market ceases to care about fast, stable, powerful languages, CF can only go up from here.
Top comments (47)
ColdFusion's been paying the bills since 1996 :)
Great post! I started out in Coldfusion back in 2010. Since then I’ve learned PHP, Python, Golang, Node, etc. However Coldfusion is still my go to when I want to get stuff done and ship something. It’s just fun to work with :)
Thank you! Yeah, CF is fun. I've been doing it since 2011. I did veer into PHP for a while, but man nothing beats raw CFML for the sheer joy of building something. :)
I have been a CF dev since version 5 and it’s paid a lot of bills since then but, time to move on. I would never recommend CF for anyone due to the complete lack of a decent ecosystem and lack of direction from Adobe and Lucee. Once one looks at .net core C# and F# you can’t make any good argument to continue with CF. Using C or F sharp I can develop native apps and high performance web API’s, event sourcing, testing platforms from Canopy, Spec Flow, NUnit, Xunit etc......
I mean my gosh Adobe is still actively spending resources with keeping tags alive! They now add covariant into the language, why? They should have open-sourced 10 years ago and maybe we would have something.
Just have a look at the SAFE stack, Fable or one of the million other options and huge community dedicated to open source in .net core. VS Code is a great example of what can happen or the F# compiler that is maintained outside of Microsoft as open source.
The landscape has changed and CF is being buried.
It's pretty obvious Adobe has done a lackluster job in determining a direction for their implementation, but decrying ACF as closed-source is a poor argument when Lucee is both open source and far better.
The SAFE stack looks pretty interesting. Fable looks kinda stupid in my opinion - if you want a JS app, write JS!
I'm not sure why I have to take a look at a million other options when CF works really well for me.
Referencing other projects as "kinda stupid" unfortunately, is the attitude I have encountered among the vast majority of CF devs I have worked with or met over the years and is the main thing that has me going down another path. If you think Fable is "kinda stupid" you also need to include Clojurescript, TypeScript, Elm, Dart, Flutter, Fabulous, Rust, etc.... Fable simply allows F# devs to maintain their style of functional programming and quite frankly I am not at all wild with the direction of JS anyways. We are getting very close to having WebAssembly becoming a standard and you should ask yourself where is Lucee or Adobe providing this ability to use CF, and then look at what is going on with .net Core, Go, Clojure, etc...
My apologies, I actually thought for a minute I was allowed to have an opinion.
You can write JS in Java as well through GraalVM, Nashorn, Rhino, or several other libraries but I still fail to see the point.
My apologies again @Robb. I didn't mean to get so sarcastic. If you think CF is falling behind, that's ok. I wouldn't mind a few constructive tips on how to improve the language or ecosystem, and we can stop badgering each other. :)
So, I started CF back with 3.1 with PWS. It was fun, easy to learn and could make apps fast. After moving back to Canada from being in the US for 13 years doing ColdFusion, it took 8m to get a contract, after that ended, I have not been able to secure a gig with CF. For all intents and purposes, CF is dead in Canada. Everyone cringes when you bring it up.
So I have been learning Python/Django. All I can say is wow. No way I can go back to CF after that. So much more robust. The tools for development are 2nd to none. I actually have fun coding again. Don't forget that I believe ColdFusion is the only app server left that you have to actually buy. Not accounting for Lucee of course. But management does not know about Lucee. They do know python, node, .net, Java etc. All free. Then you also have to consider the open source area. Try to find a Twilio package. If you do, it's likely outdated. Plenty more examples of that. Whereas all these other "popular" languages you can find almost anything. I find that a good way to judge a language is by the community and what they offer as far as open source, online learning and more. ColdFusion certainly lacks in that area especially since riaforge has been taken down and all the old school folks like Ray Camden have fled. Anyway, just my opinion. Take it for what it's worth.
I appreciate your insights, I really do. We can't move forward with CF until we address our flaws, and CF is not perfect. I had to chuckle at your mention of Twilio, though - I integrated with Twilio over a year ago in a CF app, and it only took a few minutes because there was a couple libraries out there. This one seems to be the most popular at this point: forgebox.io/view/twilio-sdk
As far as online learning goes, I'd definitely like to address that. Cfdocs.org is a great reference site, but it's hard to find quality, up-to-date tutorials to help show the bigger picture.
Taking down riaforge was a poor move by Adobe, in my opinion, but it was only for really old stuff anyway - modern CF libraries are on GitHub and ForgeBox.io.
I'm curious, did you leave the scene before CommandBox and ColdBox came along?
No, I've known about it. Just seemed daunting. Like learning a new language. Doesn't that Twilio package need coldbox? Twilio may be a bad example, but there are definitely not as many as the other languages.
You don't like learning a framework because it's like learning a new language - and so you actually learned an entirely new language?
Maybe Twilio is a bad example for your purposes, but it illustrates mine perfectly. No I don't believe it needs Coldbox, but it would need Wirebox, a standalone DI framework.
Yes, as I stated, I don't have a choice but to learn something new because there are zero jobs or contracts here for CF. No point in figuring out coldbox if it's not going to get me anywhere. How does 1 or 2 OS projects for Twilio illustrate that CF is thriving? And now I have to introduce wirebox. CF was meant to be RAD, and to me, it's no longer that. Going with Eclipse for the IDE was a huge mistake IMO. They should have learned from ColdFusion Studio, or Android Studio and partnered with JetBrains. At least take time to make some a great plugin for VSCode.
Anyway, people like what they like. If you can make money doing CF, then do it. Just learn a something else as well.
See how technologies have trended over time based on use of their tags since 2008, when Stack Overflow was founded.
Well said. I write new ColdFusion code every day. And provide value for my users. That's the only thing I really care about.
new code is the way to do it! :)
The problem is that too few companies are actively seeking CF developers anymore, UNLESS it's to help switch to a new platform. When saying it's a dying platform, it's because that too few companies employ CF devs anymore. Both of the job offers I'm currently entertaining both plan to re-platform away from CF in the next 2-3 years. And of probably eight of the last ten places I applied to were headed in the same direction.
I love ColdFusion; I've been doing it since 1996. It's a wonderful language. But between Adobe's ridiculous licensing prices and the lack of developers, it's not going to get anymore popular.
Adobe's pricing is kinda ridiculous for anyone except enterprise companies. I don't know why anyone would use ACF at this point over Lucee for standard web apps, it just doesn't compare.
The developers thing is a problem, but it's not hard to train new devs in CFML so I'm told. I'm hoping to make that even easier in the future.
Yeah training them is easy; I've trained several of them myself. Convincing them that it's worth it to them to be trained is another story. The company I just left -- we spent two years trying to find CF devs and there was nobody applying. So we said okay fine, ANY dev will do and we'll teach you CF. Nobody was interested. There is a huge "fake news" style of negative press surrounding CF that needs to be handled before this will turn around. Remember the adage -- if you tell a lie enough times, it becomes the truth.
I've been writing CF for about 10 years, until 2012. I did a certification for 7 and 8. There was a time I'd say the technology is dead. Now, however, I would avoid such a strong statement.
The problem with CF is not the language (if one can call a bunch of tags "a language", is cfspreadsheet really a language statement?), the problem is with the server. It just one gigantic Java monolith where, when one wants to use a couple of if statements, one gets 1GB of legacy Java dependencies loaded.
Also, whenever I read that there are OSS alternatives, I chuckle. They're not 100% compatible with Adobe CF. Event gateways are the example. Your earlier post at dev.to/mikeborn/five-reasons-to-le... says "There is an abundance of wow-it-can-do-that?-type functionality baked in by default" and then the reality hits you - you switch to Lucee and a lot of magic like: cfcalendar, cfexchange*, cfpdfform*, and more, simply don't work. You have to rewrite your Event Gateways. There are quirks in application startup and application.cfc handling which are incompatible with Adobe CF.
I was implementing a Kafka Event Gateway not so long ago for someone. I was faced with ColdFusion (Adobe CF 11) using 10 year old versions of the most popular Java libraries which form the core of the server: I had to shade org.apache.commons, org.apache.http, org.apache.log4j, slf4j because the versions shipped with CF are so freaking old that nothing modern is working with them. When using CF, you are using so much legacy stuff, it's simply unbelievable.
By the way - somebody here is claiming that CF is more secure than Java. CF is Java. It is written in Java.
Then there's the community. Super helpful for other CF folks, so painfully defensive towards literally everybody else trying to suggest looking at alternatives. So many people who only know CF (+ maybe some PHP or a bit of JavaScript, Node.js is not a language...) so blatantly ignore the progress in software development practices, almost always claiming that it is not worth looking at alternatives because CF is so fantastic. It is sheer ignorance and lack of will to learn new things. Knowing multiple technologies broadens the horizons.
Since I switched away from CF, I used: Node, Ruby, Erlang, Java, Scala, Clojure, Golang, wrote tons of bash and sh, Python, learned CI/CD, IaaS. I'd never consciously select CF for a new project. Never.
You sound upset that Lucee doesn't offer a funky JS calendar widget. I'm sorry. As for MS Exchange, I've simply never met such a thing (read about it in old books though), and there's a perfectly workable CFPDFForm Lucee extension. If Lucee actually wasn't a viable product, then guess what... we wouldn't use it.
I apologize for your poor experience with the community. After being bludgeoned over the head for 10 years with cries of death, please pardon us for carrying a shield. And we have a lot more experience in other languages than you'd expect.
Lest you think I'm a narrow-headed dev with my head stuck in the sand, I wrote a piece on our "Legacy of legacy". Yep, we do have work to do - as a language, as a community, in documentation and in frameworks. But it's worth the climb up, at least if you're running Lucee.
No, I remember this vividly. The client had a lot of CF servers running and it was pretty difficult to reliably migrate to Lucee from Adobe CF because of Event Gateways and the application.cfc handling issues. That + the fact that almost nobody knows unit / integration testing in the CF world. I would actually love to hear how people test ColdFusion code today.
Regardless, it was virtually not possible to save this client money on licensing with a huge upfront development cost investment. This was pure vendor lock in. Sorry. Maybe the situation has changed in the last two years.
Two years after my original post, I think that sense of carrying the shield is part of the problem. Why does one need to carry a shield? I am not golang, I am not ColdFusion, why personalizing with the technology used? Why is one bothered when someone else on the internet talks bad about ColdFusion? What emotion does it trigger?
CF11 was from 2014. If you were working with it "not long ago", it was already dated by then, surpassed by 2016 and 2018, which run on Java 11. Hardly dated.
If only the client wanted to upgrade their 4 instances on every of 4 production servers. Sigh. Do you think that everybody upgrades?
Edit: which reminds me, "not so long ago" was in 2017. I guess the only option was CF2016. Happy to see the dependencies are somewhat upgraded since CF11. However, looking at slf4j used by CF2018, the version is 1.7.12, it was released in March 2015. log4j is 1.2.15, released in August 2007. I'm sure these dependencies work fine and they're stable but the legacy apis in such old versions make it rally difficult to integrate CF with recent, widely used technologies. Partially because of CF being such a monolith.
The fact that it runs on Java 11 means nothing. Java does pretty well with regards to backwards compatibility.
If CF had a little bit more modular approach, maybe that would turn things around. There are some great aspects of CF. I really enjoyed working with cfpdf, for example.
FWIW, 2 yrs on, CF2021 did indeed introduce that more "modular approach" you wished for here. The core is around 140m (vs the old 1gb min you mentioned in a previous comment), and one can optionally install modules to support more and more functionality--whether in the installer, via the cmd line, via scripting, via docker config loading, or via the CF admin.
Just one of many ways CF continues to evolve. Too late for some, but just in time for others, who for various reasons are not only sticking with it but moving to more recent versions for various reasons.
Great article! Yes popularity, as measured by Google searches, is not a good metric for how useful or good a programming language is. For that matter counting questions on StackOverflow is not ideal either - if the language community uses other platforms for discussing code. Such as CF Slack channel or FB groups.
CFML has forged ahead in the last five years - with regular releases and all the major eco-system tools and libraries. Such as CommandBox, ColdBox, ForgeBox, Foundeo security tools, FusionReactor etc.
CF security is way ahead of Java or PHP or .NET as measured by CVE.
The various CF conferences are growing each year.
Nowadays ColdFusion is modern, vibrant and secure. I wrote a book about that last year called CF Alive that goes into this data and resources in more detail. And how all CFers can help make it more alive.
My family's business was well-served by a CRM written in BBj, a JVM-hosted stepchild of Business Basic. Over the years, the language has added structured programming, database support, easy Java interop, and other post-1980 amenities. But the vendor enjoys their flat files, single letter variable names, and GOTOs.
(We even tried to migrate to something built on sounder technical foundations, but its rigid UI and the new vendor's limited desire to customize things forced us to migrate back. It was a very expensive lesson in what matters.)
Of course, as a programmer, paying bills is only part of the equation. I wasn't interested in writing BBj, and I'm not sure I'd be happy coding in CFML. Lucee seems decent (closures!), but when I looked at lucee minute, it seemed like parts of the samples still relied on the tag style code. I wonder if the wider CF ecosystem resembles this -- a modern implementation providing backward compatibility, with folks leaning on "the old ways" to varying degrees.
My first real web app was written in PHP -- there as well, the code is only as modern as you make it. It did the job, though.
FWIW, I think the current trend of fat front-ends, pure-JS, and microservices is a recipe for complex deploys and reliance on shoddy, WIP tooling, but that's a story for another day.
I don't think you're wrong about the "wider CF ecosystem" - there are a lot of legacy apps stuck in legacy practices. As you say, any code/app is only as modern as you make it. I've seen some pretty awful PHP stuff that turned me off of the language for a while, until I discovered Symfony.
I haven't heard of CF since the millennium. Didn't know it's still used. If you like it and it's still usable then that's fine.
Thank you. :) It's actually making a pretty serious comeback with an open source engine, Lucee, and the package library Forgebox.io.
Don't forget Commandbox
Some comments may only be visible to logged-in visitors. Sign in to view all comments.