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.
Coldfusion software engineer - yes, Coldfusion. When I'm not debating the finer points of software development, I can be found pedaling furiously along a winding country road.
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.
You sound upset that Lucee doesn't offer a funky JS calendar widget.
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.
After being bludgeoned over the head for 10 years with cries of death, please pardon us for carrying a shield.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.