If ColdFusion or CFML are "dying", then why are there still 12 active conferences covering them?!
Note: This blog post is from 2012. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.Often we hear some assert that CF's dying, whether they mean CF the product or CFML the language. I want to make one contention against that which I don't hear too often at all:
There are an awful lot of currently active conferences covering CF/CFML for such a "dying" product and/or language.
I count 12 annual conferences (for the current year) which cover the topics (CF or CFML) entirely or as a major track, as listed in the category on CFML conferences which I keep updated in my CF411 resource.
Here first are the next several coming up:
- NCDevCon (Raleigh, NC/USA) coming Sep 29-30 2012
- MuraCon (Washington, DC/USA) coming Oct 10-11 2012
- Open Source CFML for Government Conference, (Washington, DC/USA) coming Oct 9 2012
- CFCamp (Munich, Germany) coming Oct 15-16 2012
- cf.Objective(ANZ) (Melbourne, Australia) coming Nov 1-2 2012
- Adobe MAX (Los Angeles, CA/USA) coming May 2013, and the associated ColdFusion Unconference
- Scotch on the Rocks (Edinburgh, Scotland), coming Jun 2013
For more details, including links, organizers, etc., see that CF411 page about them that I mentioned.
And here are those which have occurred in the past several months (we can reasonably expect new dates for them, for next year, to come from the organizers):
- RIACon (Rockville, MD/USA) last held Aug 2012
- D2W (Kansas City, MO/USA) last held May 2012
- cf.Objective() (Minneapolis, MN/USA) last held May 2012
- WebDU (Sydney, Australia) last held May 2012
- OpenCF Summit (Dallas, TX/USA) last held in Feb 2012
Just one more sign of the still-healthy and active communities surrounding CF, CFML, and the alternative/open source engines.
A couple more thoughts on CF's vitality
Now, it's not the point of this entry to host a debate about CF's vitality, pro or con. And I certainly hope that supporters of alternative CFML engines would grant that I'm clearly acknowledging them above, even if they would argue against CF's longevity itself.
Still, I'd like to take a moment to point out just a couple other signs of vitality for Adobe CF the product (ACF, as some term it), starting with the recent CF10 release, as well as the recently offered product roadmap (link updated in 2015) for the next two releases, to name just a couple. These are simply not tell-tale signs of a swan song for the product.
Indeed, those of us who've been around a while have heard this assertion of CF's coming death for several years, which is ironic in itself, as Mark Twain might quip!
Been there, done that, got the t-shirt
More than that, I bring a historical perspective to my sentiment. I came to CF 15 years ago after leaving a mainframe product I'd worked with for 15 years, where everyone was saying then in 1996 that THAT product (and the mainframe) was dying.
Guess what: now 15 years later, that product and mainframes in general are STILL in use. Enterprise solutions just don't go away easily. There's too much investment in them. (And yes, CF and CFML are parts of an enterprise solution for many.)
Anyway, regardless of your favoring ACF or alternatives, I just wanted to make the main point above that for a "dying" product and/or language, there's certainly a lot of interest in holding conferences about them. :-)
(Perhaps I could have made that point and left out the additional commentary on ACF itself, but we seem to hear more often recently from those who would argue against it. Just trying to offer a little balance for the discussion.)
Finally, I really don't want to hear from folks in the comments here about why they think CF and/or CFML "really are dying". There are plenty of other places where that's been done to death, and it's just not the point of this entry. (Let's see who in that group speaks up first, having missed this simple request. Of course, I welcome comments about any other aspects of the blog entry.)
For more content like this from Charlie Arehart:Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Just something to ponder while the conferences are going on, secret dealings behind close doors, can always end a dream.
1) Regarding the conferences, if you look at the content being offered, and look at the content that's been offered in past years, I think you'll see a trend of less CF-related sessions and more that focus on other technologies. This is not a "bad thing" in general, but may be indicative of certain things.
2) I don't necessarily agree with the fact that there's a correlation between a company releasing a road map and the rosy future of a product. It certainly helps, but there also has to be a strong community around it. If nobody's around to read a road map, is the destination still relevant? :)
3) Regarding the mainframe product and mainframes in general, yes, they're still in use. But would you still consider them "relevant"? If somebody were going to embark on learning a new language today... would you suggest that they learn that language? How easy would it be for them to get a job?
Honestly, I'm not trying to be a naysayer. But to honor your request, Charlie, I won't go into why I think CF is "really dying". I'll say that I don't think it's due to any fault of CF itself, or the time and effort that the current engineering/management team is putting into it. In fact, I've been rather impressed by their efforts. I simply think the "programming-for-the-web" landscape has changed to the extent that the niche that CF had previously fit continues to decrease.
Hope that's fair to say without violating your simple request :)
@cfvonner, thanks for speaking outside of CF realms. It's amazing how many people today have no idea what CFML is currently capable of. I think talking about it in non-CF circles is important for us to do.
Nah, just kidding. Good post. From reading my blog, one might thing I am a huge CF naysayer, but I only comment vociferously on the stuff that irks me: and this is just a small percentage of what CF offers. Hey: nothing's perfect.
I'm a few years behind you in my CF career, but I am finding it more and more interesting as time goes on, and I am really enjoying working with it at the moment. I want to learn new things too (improve my JS, look at Groovy, etc), but I'm pleased CF (and Railo etc) are going reasonably strong at the moment. I hasten to add it COULD do better in some areas (and I think it needs serious attention in some areas too), but it doesn't need to the absolutely most popular language out there, just enough to keep the community healthy.
I'm pretty excited (such as I get excited) about the CF11 and CF12 roadmap, I just hope Adobe manage to get that message out to people who don't already use CF.
Again: good post. Cheers.
--
Adam
@Andrew, I hear you. That's one of many "possibilities", of course.
@Charlie G: I hear you, too. As for your points:
#1 About conference content changing, that's a fair point. Like you, I don't see it as any indication of doom. Just a natural evolution with new technologies to learn, and less to learn for most about CF.
#2 About the roadmap, well, ok. So I guess Adobe is damned if they do, damned if they don't offer one ;-) Anyway, I would assert CF does still have a "strong community" around it. And there are surely thousands who have read the roadmap, and there will be thousands or more who will implement CF11.
#3 About mainframes, well, you quote them being "relevant" as if I said that. I only said they are still around, nearly 2 decades after people started declaring them dead. As for whether anyone should learn mainframe languages, they do. Google "mainframe training" and there are 400k results. Remove the quotes and there are 8 million. Mainframe use is still strong in many businesses and industries (from a quick scan of various resources discussing the topic on the web).
You ask, "How easy would it be for [one] to get a [mainframe] job?" I'll just note that I googled [mainframe jobs] and got 1.3M results . PHP jobs found only 600k. (CF jobs found 800k.) Of course, that's not a completely realistic measure, but it's interesting nonetheless. (Sometimes, it's gigs that are harder to fill that lead to more job postings.) Anyway, there seem to be plenty of mainframe jobs.
So Charlie G, you say you're not trying to be a naysayer, but I'm not so sure. ;-) But as for your last point, sure, the landscape is changing. But I think that would prove my point; sure, it's changing. But it's not as bleak as many would seem to want to paint it. Again, just my opinion. I realize a lot of current and former CF cognoscenti would assert otherwise. Doesn't make them right, any more than I am. Just offering a contrasting opinion. I'm used to being in that spot!
@Carl, thanks for the clarification on Muracon. I should have caught that myself, as I knew it was in DC. I just had not updated the CF411 page when I learned it. I have now, and the blog entry here. Thanks.
@Brad, really good point.
Finally, @Adam, thanks for the reasonable observations, and for the additional encouragement. :-)
So let's all see what the next round of comments may bring. :-)
"Open Source CFML for Government Conference" - is really just an adjunct to MuraCon, not a separate conference, so I think it's a stretch to count that as well as MuraCon :)
D2W and WebDU are general web development conferences these days, not really CFML conferences, so I would argue it's a bit of a stretch to count those too.
Still, nine conferences around the world in a year is pretty good going for a "dying" technology - and it's worth noting that cf.Objective() attendance has increased pretty much every year, as have some of the others mentioned.
The analogy you draw with mainframes is telling: technology very rarely "goes away" even if it declines in popularity. The reason? Millions upon millions of lines of legacy code is often just too expensive to rewrite. There's still a huge amount of COBOL out there (and I'm not knocking COBOL - some of my early work was in COBOL, as well as working on COBOL compilers).
I half-jokingly call Java the modern COBOL because it's ubiquitous in the Enterprise and, despite all these upstart languages on the JVM, it's also never going away.
There are plenty of CFML jobs - there are many companies that can't find CFML developers so job reqs stay open for months, sometimes years - but I do think there are far fewer CFML developers now than in 2008, when the Evans Data Corporation estimated nearly 800k worldwide. The jobs trend for CFML on all the jobs sites has showed a steady decline since the beginning of 2009. Mailing lists are much quieter than they used to be. Blog aggregators are much quieter too (at least in terms of CFML content - many bloggers we used to follow have switched to other technologies). I think very few developers are learning CFML and joining the community these days (certainly compared to the heyday).
CFML isn't "dying" but it's a mature technology that has been overtaken in many ways by other technology and, ironically, Ruby, Python and PHP - perhaps CFML's biggest competitors - are all just as old as CFML, but had the benefit of being free, open source from the get-go. CFML is a rare creature in today's: a proprietary language (even tho' it has a couple of free, open source implementations now). Proprietary languages have a tendency to wane in popularity over time for a variety of reasons :)
As I've often advised, learn other languages (as well as CFML) so you become a better programmer - and more marketable. Learning Clojure, for example, will make you a better CFML programmer even if you never write a line of production Clojure code! The same goes for Ruby/Rails, Groovy/Grails, Python/Django...
As for D2W and WebDU being more general interest, well, I did say that these were conferences "which cover the topics (CF or CFML) entirely or as a major track". I think it's not really a "stretch" to count them. If they ever drop CF as a track or have only a couple of topics, I would drop them.
And to be clear to everyone, again this list here is taken from my list of CFML conferences on the CF411 list. Odd that no one ever complained about what conferences were listed there, only now when I have blogged it and made this assertion about CF's/CFML's vitality.
Anyway, I appreciate your other points. Yes, I'll grant CF/CML is a "mature" technology. But as you and I both turned 50 this year, I hope you'd agree that we'd rather not be called "dying", even we may be in "steady decline" also. Heck, we all are, and so too are all technologies in the long run.
I just am arguing against the age-old assertion that CF is in its waning stage. The signs are not as clear to me as some assert them to be. Again, it's all opinions really. Those who prefer to look at the glass half-empty can find other places for that. I'm still flying the flag here. :-)
Seriously? I don't think any sane person can argue that CFML isn't _waning_ - that's a far cry from _dying_ but let's be realistic about this.
This head in the sand attitude means you can't discuss the issues head on with people outside the community - and it also means you aren't preparing for the changes in the world that limit CFML developers employment opportunities because they don't know other languages.
If you can't get into a company that doesn't use CFML, you can't persuade them to use CFML. That's why you need other languages - you need to get in the door.
Let me put it another way: again, I'll grant that CF could be seen just like people our age (50): mature? Yes. Regarded as "over the hill" by whipper snappers? Sure. Waning, as in "approaching an imminent end"? Far from it (if one means that someone at 50 is on the verge of dying, on average.) I think both you and I, and most who know us, would not see us as about to be put to pasture. :-)
As for having to "prepare for a world that limits CFML developers employment opportunities", again I see that as an overly pessimistic stance. Not everyone is moving around trying to find new jobs all the time. And again I'll argue, as you did in your first comment, that "there are plenty of CFML jobs" and there will continue to be for a long time. (I get requests every week from people seeking developers, and I point them to my cf411.com/cfjobs page to find those looking.)
To be honest, I'm a little surprised at your shift in tone from the last note to this one. Was it something I said? :-)
To your next point, well not everyone is in a position where they need to seek to "get into a company that doesn't use CFML [and] persuade them to use CFML." For someone in such an evangelistic role, sure, that makes sense. But I don't think it's the position most CF developers are in.
Finally, and perhaps most important, I'm not at all arguing against "learning other languages". That's not my point here. Sure, it makes sense to learn other languages, whether those that serve as adjuncts to CFML development, or those that are alternatives, but by whose study one simply becomes a better developer. I didn't suggest otherwise.
But I shouldn't be cast as a Luddite for flying the CF/CFML flag. Just because I support and encourage its continued vitality doesn't mean I'm against innovation (the general meaning of Luddite).
Really people, what's with the compelling need to put down any attempt to encourage hope in the CF/CFML community? As the post asserts, if CF really was dying, why would there be so many conferences? and so many jobs? If you choose to see the cup half-empty, fine. Just know that not everyone does. (Not speaking necessarily to you in this last paragraph, Sean, but to the tone I hear often out there from a vocal segment.)
I didn't see Sean's post as being like that, Charlie. He was just disagreeing with some of the things you said (and his comments are all accurate, I think, as well as being reasonable feedback of what you said).
If you have a blog that allows comments, then you have to expect that not all the comments are simply going to be "yeah, you're exactly right".
--
Adam
And no, I'm not expecting all comments to agree with me. But I stand by my last paragraph, as a plea on behalf of some in the community.
For example, just a couple of weeks ago, ColdFusion was the 40th most popular language on github, now its the 42nd:
https://github.com/l...
Lets look at the number of recently created repositories for ColdFusion:
https://github.com/l.../created
The bottom line is that I firmly believe that the more open source projects that a language is being used in directly corresponds to its popularity and acceptance.
That said (and I'll be a broken record once again), we need more people actively participating in the community and creating open source projects with CFML.
And for those that would like to meet a few of the Coldfusion bloggers , last year there was a very interesting initiative, started by Steve Bryant: "How I got started in Coldfusion" - I felt is was a very interesting read. The collection of 60+ personal stories are available on Scoop.it
http://www.scoop.it/...
On the topic of language trends, I saw this interesting graph pop up on Twitter yesterday.
http://redmonk.com/s...
while riaforge might be `THE` place for open source ColdFusion projects, the industry looks at github as `THE` place for open source collaboration period. There are websites and services built around your github commits. More and more recruiters and employers are looking at github to determine a candidate's skill level. I highly doubt the same can be said for riaforge.
bottom line is if you want people to take notice and consider using ColdFusion or CFML in general, then there needs to be more activity from the community on github and the popularity of the language needs to be going up, not down.
I know very talented and I mean extremely talented developers, who have never written anything open source, sure they dabble at home in their spare time, but never release anything.
And by cutting their throats, the employer is being very narrow minded if they think github is a requirement in the recruitment process.
"As for having to "prepare for a world that limits CFML developers employment opportunities", again I see that as an overly pessimistic stance."
By putting quotes around that clause you make it sound like I said that. I did not. Please don't put words in my mouth.
"For someone in such an evangelistic role, sure, that makes sense. But I don't think it's the position most CF developers are in."
I was rather hoping that CFML developers would want to grow the community... Open source languages get popular because developers using them go into companies that aren't using them and introduce them. It's how companies switch to Ruby on Rails, or Groovy on Grails, or Clojure or Scala or whatever. If CFML developers don't know other languages, they won't have the opportunity to introduce CFML into a shop that doesn't already use it. The pool of CFML shops is shrinking - companies are moving from CFML to those other technologies, often because their CFML developers don't know enough about those other technologies to properly justify staying on CFML.
"Really people, what's with the compelling need to put down any attempt to encourage hope in the CF/CFML community?"
I think the CFML community needs to be realistic. Re-read my original comment: I agreed with most of your points. I just think the flag-waving smacks of desperation and an unrealistic view of the world (hence my surprise that you insist ColdFusion is not "in its waning stage"). It is waning just as COBOL and mainframes are waning (referring back to two other technologies mentioned in comparison).
And Tony's right about RIAForge. Yeah, it's nice, but it's a ghetto. CFML developers need to be out there in the general population, visible and proud of their language choice and, most importantly, be able to coherently justify it to others (which, again, means knowing enough about those other technologies to recognize CFML's flaws as well as its benefits!).
Attitudes might be different in the USA, or these days, but sorry to say any employer who hires one person over another because they have released open source software is not an indication the latter is a better developer.
i really think you're focusing on the coding aspect of github and open source and missing the bigger picture. contributing to open source isn't `just` about coding. any moron can whip up an open source project and push it out to the world. the bigger picture is about team work and how the person interacts with others while doing a project. very often employers pick candidates not just because they know how to code, but how well they will `fit` the company's culture and work with others. github allows you to get an overview how well a candidate takes criticisms, suggestions and generally interacts with other members of a team through their commits and comments.
my bad for not elaborating more in my original post and just mentioning employers using github to determine skill level.
That said, thanks to all for their contributions the past several hours. (I'm in the middle east right now, on an assignment, so my hours to respond are quite different from everyone in the US this week.)
So, first up about open source, thanks @Tony, @Andrew, @Birgit, and @Sean for an interesting discussion. I can see some value both in using it as a measure of vitality and as a *potential* measure of a developer's skills and working styles. As for it as a measure of vitality, I'll also grant that there are imperfections in using either that or conferences, but interesting contribution to the discussion.
As for using it as a measure of a developer's skills, good back and forth there. Sean, I was glad to see your noting when you ask that of interviewees, that "if the candidate has [no OS contributions], I always ask why." Some could take too rigid a stance on such things. As I'm sure some answers to that have sometimes shown, some people just don't get involved in community work outside of their job (or in it), though they may well be experienced, effective developers. (I appreciate that Andrew addressed that in some of his comments.)
Still, really fair point there, Tony, about how one could use an observation of active contribution to an OS project as a measure of "team work and how the person interacts with others while doing a project". Again, it's not perfect (they could do all that also well, but within a private team, and just having no time, permission, stomach, or motivation for OS projects.) As Sean notes, it would be fair to ask why they may not.
@Brad and @Bill, that's always a good point to remind people (about seeking developers from other languages when you have need for CFML coders.) We all know how easy it is to pickup, and a skilled developer can quickly be better than many experienced CFers, if they bring better software maturity.
@Sean, I have to repeat my "sigh" that I gave Adam. You're accusing me of misquoting you? Goodness, do I have to start making jokes about us old people and our memories? :-)
You said, in your previous comment above, "This head in the sand attitude means you can't discuss the issues head on with people outside the community - and it also means you aren't preparing for the changes in the world that limit CFML developers employment opportunities because they don't know other languages."
To that I replied, "As for having to 'prepare for a world that limits CFML developers employment opportunities', again I see that as an overly pessimistic stance."
That seems an accurate representation of what you said. Are you quibbling because i shortened the quote a bit, yet still quoted it? I was conveying that it was your thought (not mine). Even if was not a word-for-word quote, did I change your meaning from the original? I really didn't think so and certainly wouldn't have done that intentionally. It would have been awkward to try to simplify it as I did while somehow also indicating in the quotes the exact ways I removed and/or changed a couple words to make it stand on its own. But if you think otherwise, please clarify and if I see some major gaffe I would certainly apologize. But no offense was intended at all.
As for your "rather hoping that CFML developers would want to grow the community", sure, we can hope for that among some percent. I was just saying we can't hope for it among most, or I daresay many. I just disagree on the degree to which that's everyone's (or a majority's) role, altruistic and admirable though it is.
As for your referring to your original comment, and how you "agreed with most of my points", I did thank you for that in my first reply to it, and even added that "I appreciate[d] your other points" there. It was just to your second comment that my last one to you was focused. Your tone seemed to change, and I commented that I thought it curious.
Anyway, like I said in my last sentence, my final comment wasn't directed to you, but I'll admit it was inspired by what I felt I was having to state/repeat (in replying to you) and have had to say to others.
As for the flag-waving, I appreciate that you and others may well see it as seemingly "desperate". Those who have made up their mind on this matter may even see any attempt to defend to the contrary as insipid, illogical, ill-informed, misguided, leading lambs to slaughter, and so on. :-)
Hey, I'm just offering a public statement of that counterpoint. Castigate me as you will, folks. The comments from some others here show that I'm not entirely alone in wanting to put forth a different perspective on things. (Thanks for your comment there, @Magesh.) I suspect some might want to speak up but may be a little worried about being dragged into a quagmire.
Finally, back to your "surprise that [I] insist ColdFusion is not 'in its waning stage'"), again I tried to make a distinction between waning as in "about to die" and waning as in "in a mature stage of life". I see CF as the latter. Many seem to want to paint it as the former. See previous in this comment.
But really, Sean, let's please not make this a match of wits. For one thing, it may seem to some from the outside that we're fighting with each other, when any who know us know we're just being complete in stating our views. :-) More than that, the CF community would roundly (and rightly) acknowledge your superiority on matters of software development.
Again, I just want to offer even a lone wolf voice for the contending perspective that CF is not 'dead", nor even near it, and I'm willing to put myself out there with at least this one argument, come what may.
I hope I've remained charitable and reasonable to all. I certainly mean to, even where I may disagree. (I could make allusions to a similar challenge faced when one stands for Christianity, but that would open an entirely new can of worms! And this blog entry is not the right place for that, though I have addressed the topic in another entry, though the topic may at first seem unrelated: http://www.carehart....).
Finally, Sean, I hope in all my quoting here I did a more accurate job to do it precisely. ;-}
"I just disagree on the degree to which that's everyone's (or a majority's) role, altruistic and admirable though it is." -- and I think this is a key difference between developers who work in an OSS world and those who work in a proprietary software world. The latter believe it is the vendor's job to do marketing to grow the community. The former believe it is the developer community's job to grow the community. I suspect also that's where the difference of opinion on open source projects / github comes from: I want developers who give back to the community as part of their DNA; I want people who will be enthusiastic - and evangelistic - about the technology they use. I've been developing OSS for about 20 years now so my views are clearly going to be different to folks who are either fairly new to it or who don't contribute at all.
We're definitely in agreement that CFML is not 'dead' :)
FWIW, I've been doing quite a bit of evangelizing CFML to folks in the Clojure community and when I spoke at two Adobe user groups in Australia recently, there were a number of Clojure developers in attendance who'd previously never been exposed to CFML!
Sorry I stand my ground, not everyone has the time to even help out either. As much as I think it has merit, not all can contribute to something. Many have successful careers and have a very fruitful life outside of work, and I doubt they will change just to please prospective employers.
But I'm kind of surprised to hear you raise the concern so strongly. I've seen far more spam comment on many other popular blogs (CF and otherwise)--and far worse in my opinion, they never delete them (which only justifies the spammer's efforts) nor do many bloggers hit with them do anything to prevent them happening again.
I do certainly watch for them, and always delete them within the day. I then put in place protections to prevent them (those particular ones) from happening again. That's how I deal with them (and I've blogged about my approach in more detail in the past here.)
But as for moderation, the version of BlogCFC I have (admittedly an old one) does not offer it, so I can't easily add that. I'm certainly looking to update the blog software someday.
I'll admit it's not been a priority (for a number of reasons), and to be completely frank, no one else has ever complained about it, so I didn't think it was "_really_" that burdensome to others.
Still, I appreciate your opinion and do know that there is more I can do. Please just appreciate that I am not ignorant of, nor am I ignoring, the issue. It doesn't happen that I get that many spam comments (perhaps a few a month) given the protections that I do have in place.
My apologies to all for the annoyance. (And I'll oblige any request to remove someone's address manually from being notified for further comments on this or any other entry where they may ever have made comments. There's no automated mechanism in this version of the blog software, but just email me directly and I can take care of it. My contact info is offered in the right nav bar.)
As for "no automated mechanism", emails from BlogCFC 5.0 do contain an unsubscribe link so folks can easily stop receiving updates to a particular post.
Of course you could always deploy Railo in the cloud and just pay the base Amazon per-hour price :)
i second that. Just use Railo. It's free, faster, less memory intensive and more stable then ACF. We switched over to Railo at the beginning of the year from ACF9 and couldn't be happier.
Good thing to hear, but they're still waaay behind schedule.. AWS and similar products are reality, have been reality for a couple of years and "they are planning"... I waited for CFMX7 because CFMX6 'wasn't the best version released'. I waited for enhanced cfscript syntax since CF7 and they were available on CF9, I gave up waiting on decent prices and licensing. Let's hope things get faster :-)
@tony: railo is my last hope on CF
Indeed, in my consulting services, I find that often people are suffering with performance problems which can be easily resolved to make CF less "memory intensive and unstable", so it's not like it's something one just has to live with.
I can even demonstrate reasons why a switch from CF to Railo would make things seem faster and more stable, but which may have an explanation that's not at all what it seems on the surface. I can even show how a switch of the same code to a new (different) server running CF could also be "faster and less memory intensive" than it had been on its current server, yet without a single line change of code or configuration. (More on all that in a moment.)
Not Anti-Railo
------------------
But look, I don't want to turn this into a p*ssing contest of CF vs Railo. I've avoided making even that statement I just did, in any of many online debates that have raged, as it could be easily misconstrued without complete explanation, and I didn't want to take the time/space on someone else's blog to elaborate my point in making that statement. Since this is my blog, I'll take that time now.
First, let me be clear: I'm not anti-Railo. I've known Gert and Micha for years, and have even talked about getting more involved many times, but there are sensitivities for me personally. As many will know, I worked for the company behind BlueDragon (2003-2006). I appreciate where alternative CFML engines can indeed step in with a solution that perhaps CF may not have. In BD's case, my main interest and focus was the unique proposition that it ran CFML natively on .NET (something not in the open source version of BD, for those motivated more by the "free" nature of some alternative CFML engines. CF clearly can't, for now, compete with that aspect.)
Anyway, some know I was tarred and feathered back then, for "leaving CF" and supporting an alternative. Sure, things are different now years later, with Railo being free, and now even OpenBD. Still, I'm overtly sensitive to jumping in with an alternative. And many know I've been an Adobe ACP, user group manager, and am even on the CF Customer Advisory Board (CAB).
So no question, I'm a CF fanboy, and have been for 15 years. :-) Even so, I don't hold it against others to consider and even switch if they will to an alternative.
Most "Problems" Can Be Resolved
-------------------------------------------
I'm just saying it's not fair to paint that such a move will always be better. It might be, but it could well be that things could be made to be better as-is on CF, for someone with a seeming problem, with just a modest amount of modification: generally to configuration, not code, in my experience, which I know goes against the assertions of most, that problems are in CFML code, CF's running of it, SQL code, the DB's running it, and so on.
In my experience (helping people solve CF performance and reliability problems being my job), the solution is not in coding issues that would take a major rewrite to resolve. Nor is it inherently in "CF's being memory-intensive and unstable", though I realize of course that many paint it (or even see it) being that way.
In fact, I'll make anyone reading this an offer: if you feel that your CF server is "memory intensive and unstable", I'll spend up to two hours with you to resolve that. If I don't resolve the problem to your satisfaction, the time is free. If we do resolve things, you'll pay my normal rate. For more on my consulting services, including my rates and standing satisfaction guarantee, see http://www.carehart....
Since this sort of troubleshooting is all I do for a living, I can say with great confidence that most CF server performance and reliability problems can be resolved. I typically work with dozens of different shops each week, doing just that. And invariably, they come away with a server that now stays up for days, weeks, or months (when It may have been crashing daily). And again it rarely takes more than a couple of hours to understand and resolve the problem.
Is it that CF is somehow inherently complicated and therefore "requires the skills of an expert to make it work"? Not at all. What I'm trying to tell you is that often the problem is not CF at all. What I often do is help people use the diagnostics that are available (or can be made available) to better understand what's going on, when seeming problems hit.
What we do when we work together is not just "fix the problem" but I help them find and understand those diagnostics. In nearly all cases, folks come away from the session (even as brief as it may be) with considerably better understanding of things, and indeed renewed confidence in CF.
Some "Problems" Solved by Move to Railo
--------------------------------------------------
Might some of those people found things "just got better" in switching to Railo. I suppose some might. But the point is that they did not HAVE to in order to resolve things. And again I'll say that there are some problems that would seem at first to go away on a move to Railo, but that might even come back down the road (because the real root cause has not been resolved).
For instance, the default behavior in CF is to store client variables in the registry. (That default is changed in CF10, thankfully, at least for new installs. Upgrades will keep most previous settings in the CF admin.) And because CF (and Railo) also writes some "global client variables" (lastvisit, hitcount) this will cause read/write of client vars on EVERY page request, for anyone who turns on clientmanagement in code, even if they "never use client variables" elsewhere in their CFML code (after enabling them).
This has been a root cause of many problems that plague CF servers. I've found many servers that had millions of records in the registry. (Sure, one option it to change to using a database for client variables, something that both CF and Railo support, but that isn't "the solution" if the real problem is that you don't really use client variables in the first place, and have clientmanagement enabled needlessly. Setting the default clientstorage to cookies is generally the better solution, which is what CF10 now does for fresh installs.)
And not only does this client variable problem slow down every page request (due to the "global client variable updates"), but then CF wakes up every hour by default to purge them, and that itself can cause a terrible CPU and performance burden, every 67 minutes by default.
I call all this the cancer of CF, and have blogged about it as part of an entry on the larger concern, which is nearly always at root a problem of the impact of spiders and bots: http://www.carehart.... I help people resolve problems with this matter quite often.
So why do I bring all this up? Well, back to the point of this comment, some "good news" for Railo is that it doesn't even offer registry as an option in the Admin. Even if you set it in code with clientstorage, it will instead use a file for you. Indeed, if you specify no clientstorage in code, the default for the admin is to store it in a file. (For more, see http://www.sumoc.com...)
So if someone moved code from ACF to Railo, which had no clientstorage set in their code, their app would change from using the registry as it did in CF to using a new file in Railo. Not only would they not then have the baggage of the potential million-record registry being read/written to on every request, but they would no longer have the hourly purge of it. Both can be GREAT improvements.
But is the problem (in this case) that CF is inherently unstable? No, it's that there's a feature, which if enabled (again, people have to enable CLIENTMANAGEMENT in their code) has some defaults (the registry being the default storage and the global variable updates being enabled) which can be problematic in some situations (especially sites hit by high volumes of spider/bot traffic.)
Is that a common situation? Fairly common. Not common enough that everyone is hit by it. Some don't have any spider/bot traffic (which is what generally causes the excessive burden of pressure on the client store in the first place.) Others have not enabled clientmanagement when they didn't need it. Still others have tweaked their Admin settings appropriately.
But I have no doubt that it could the real root cause of problems for many who would be so put off by CF performance as to consider moving to an alternative. And if this indeed was their root cause problem, it would magically go away on the move to a new engine, at least until the newly written client storage file grew large over time, in which case it could come back to bite them, though perhaps Railo and the OS's management of read/updates in a huge client variable file would be better than CF' and the OS's management of read/updates in a huge registry. (And as I noted at the outset, this same "problem" would "go away", at least for a while, if someone simply moved their ACF from one box to another, since the new box would have a shiny new registry for CF to start populating, until the problem grew large enough to read its ugly head again.)
Things Just Aren't Always What They Seem
----------------------------------------------------
So why have I gone on and on about this? Again, because things are just not always what they seem. There are very few people who are aware of the problems above, though a few others have written about them. And it's possible that some of them have not made the switch to Railo or have not documented how they observed things to have changed in this regard.
So while you rarely have heard anyone bring this up before, I hope I've made the case that it makes sense that it could happen, and could be at the root of an apparent huge change in performance in Railo over CF.
And lest someone bring it up, I'm really not interested in any observations about how some tag or function is x times faster in Railo than ACF, because honestly it's problems like the above that are FAR more important when it comes to "why a CFML server is slow". In my considerable experience helping several hundred shops over the years, the solution has NEVER come down to such matters. Problems are nearly always configuration rather than code, or the impact of high spider/bot traffic, all of which have mitigations that have nothing to do with the speed of some one tag or function.
So all this said, again, I am NOT knocking Railo. I'm just saying that there can be many other explanations for why a move from ACF to Railo was better that have nothing to do with CF being inherently memory intensive and unstable.
Since I've helped many people easily solve such problems, I'd argue that a couple of hours spent with me investigating and resolving such an issue would be far more effective use of time than a shop making a wholesale move from ACF to Railo.
Again, that's not to discourage anyone from making the move, nor to knock anyone who has. Please do NOT turn this into a gripe session that "now Charlie is hatin' on Railo". I really am not. I'm just pleading that people be more careful in their assertions and investigations before making blanket statements that one solution is inherently better for everyone than another.
And yes, saying Railo is "faster, less memory intensive and more stable then ACF" is one of those kind of statements, at least in my opinion.
Finally, Tony, please don't take offense at my digressing on this point. Again, I don't deny that you may yourself have many other reasons to have "switched over to Railo at the beginning of the year from ACF9 and couldn't be happier." I'm only arguing against using that (and some comments offered by others in the community) to assert that somehow it's always and invariably going to be better for anyone who makes the move.
More specifically, I'm arguing that for some shops, finding, understanding, and resolving the root cause problem they face may be more cost-effective than a move to a new CFML engine, even if it's free.
But if someone does an apples to apples comparison and decides it's best for them, I'm not arguing against that. I can understand why some from Adobe, with a vested economic interest in sales of CF, would feel otherwise.
But I hope all who have had the patience to read all this comment will remember the point I was making from the outset: that I just don't agree with the assertion that CF or CFML is dead or dying. I even commented in the entry that I was not trying to make this an ACF vs other engine debate. Let's please not turn it into that.
I stand again by feeling that my comment here, in response to another, was a reasonable one to bring up. If you want to reply to this, feel free, but again let's not turn it into a debate over CFML engines. That's really NOT the point of this entry.
Anyway, thanks for any with the patience to have read this entire comment, and indeed to any of you visiting the entry for the first time who have been patient and diligent enough to have read all the comments above. It's becoming almost a book itself! Again, that tends to happen with blog entries that are viewed as controversial. I didn't really think that's what I was doing, but there you have it.
The conversation needs to be directed to Adobe, we're not going to get newcomers to CF by debating among ourselves. The CF community is still great and self-enthused, but despite what the community blogs or what Railo or Blue/OpenDragon do it really comes back to what Adobe does that makes all the difference in the long run. They're the only ones with the big budgets, customer reach and marketing power that can attract new developers to CF to keep it buzzing for another decade.
I won't waste my breath commenting on their marketing. I just wish I knew why they've never bothered, yet they still invest in a very capable and impressive development team.
Not all of us work for companies that have decided to invest in ColdFusion as the technology of choice. There are many web developers out there (like me) who work on a contract basis for individuals and small businesses, and who like to use ColdFusion if their customers could afford the hosting.
While more companies are offering shared ColdFusion hosting these days, and charging less than in years past, they still have to charge more than they do for plans that come with PHP and .Net, and Python, and other open source languages. Increasing numbers of hosting companies are even offering free hosting with open source languages. Not so with ColdFusion, because the enterprise licensing is so costly. Individuals, organizations, and companies with small web budgets will choose hosting based on their pocketbooks, and ColdFusion won't make the cut.
I believe that Adobe needs to make a special licensing arrangement for hosting companies, so they can make shared ColdFusion hosting more competitive. Adobe marketing promotes the "ease" of programming with ColdFusion, but then they price it out of reach of many independent developers, who will simply choose another language, because asking your customer to pay more so you can program in CF is a tough sell.
If more hosting companies can provide ColdFusion at the same price as PHP, .Net, Python, or other open source language, then more people will learn ColdFusion, and the popularity will grow.
Yes, Coldfusion is dying. And it's dying because not too many people are adopting it. And the reason it's not being embraced by potential adopters is very simple: Coldfusion has losts its attractiveness as a simple and powerful way to develo simple websites. The evangelists and Adobe itself have gone on this crusade to make everything OOP and find new and contrived ways to make everything simple into some complex coding process. Musicians making music for musicians. Ever wonder why the public won't buy your music?
Right now (and for several years), the tutorials and easy examples that would show a potential adopter how easy it is to get things done with Coldfusion have been hard to find. Everything is some sort of complex (for beginners) OOP method to query a freaking database. Even the Application.cfm template has become a complex project!
Why learn a complex Coldfusion when you can learn PHP?
The only hope is for Adobe and the evangelists to bring the simplicity back. To make the language appealing to the "unwashed masses".
http://charlie.grief...
I won't comment further here because the conversation has been pretty active lately on blogs by Nick Kwiatkowski, Adam Cameron, myself, and others.
I absolutely agree with @Tony's perspective on this CF situation ... If there was a stronger open-source community CF would explode again ...
From a small-time guy like me I look at other languages, frameworks, etc in comparison to CF and think, 'Geez ... why would I want to pay for X when Y does that and more for free? '
For a concrete example without the Holy Wars --- Take ColdSpring and Java Spring ... They both have extremely good Ioc DI support ... however in order to use CS I'd have to have CF or Railo ... in comparison to Java Spring I just need to have Spring.
For CTO's this is probably a big deal ... as Java is quite predictable with a very large candidate pool ... whereas CF changes quite drastically from v to v ... Which makes migrations and scaling quite expensive ...
As I'm nowhere near an architect I can't really speak from a perspective of experience with making large-scale technology stack decisions ... This is just my line-of-thought ...
http://forta.com/blo...
But really, what do you think they are investing "inside the US"? Trust me: no one inside the US sees any more marketing for CF than outside. That will ring hollow to some, who will say that this is the REAL problem, that there is little to no CF marketing they ever see at all. But that's an entirely different discussion.
I just want to say (for the nth time, in dozens of forums over the years) that any problem of lack of marketing or other community support from Adobe for CF is NOT worse OUTSIDE the US: it's the same inside the US.
What I really want to say to international folks is: please stop feeling like you're being singled out, or being left out. Really, you are not. We (in the US) don't get something that you are not getting. Honestly.
And just as we IN the states have just had to learn to live with it (including the issue of many/most others in IT not knowing what CF is, or not having respect for it, or not being able to easily find CF people, etc.), just learn to live with this state of affairs wherever you are. (I speak now to all readers, not just you, Qais.)
Adobe says they are undertaking new efforts to increase the reach of CF, and find new developers, etc. (see blog entries from the team at blogs.coldfusion.com to find out more.) We'll see how those renewed efforts may turn out.
As for pricing being another thing that you (and others) think will "kill" CF, I'd argue instead that it's about the only thing keeping it alive, at least within Adobe. If Adobe didn't charge for it (and support and maintenance), or if they charged only for support and maintenance, it's possible THEN that the revenue stream/profit margin may not warrant it remaining an Adobe product.
Would that still mean that it would "die"? I sincerely doubt it. Having been in IT for over 30 years, I can tell you that old enterprise software products don't "die". There's far too much investment in them (even if only in the tens of thousands of shops remaining, who it seems are just still not interested in or motivated enough yet to have moved to a new platform).
Instead, there's always been some vendor who would see that revenue stream/profit margin as "enough" for them to make it work. CA (Computer Associates) was legendary for doing this with many products in the past. I don't know who does it these days, or if they still do.
Finally, if nothing else, the fact that there ARE two alternative CFML engines means that even IF Adobe were some day to drop it, and even IF no other suitor bought it up, there would still remain viable ways to run CFML. So it's not dying, and it's not going away anytime soon.
Sure, it may lose favor in the eyes of the cognoscenti. It may lose total market share. It may some day be used only by thousands of IT shops. But it's not going away any time soon, whatever some may feel.
Do I know this for sure? No. I'm saying this from all those years of experience.
There's nothing new under the sun, including these infernal, incessant, borderline repugnant debates about whether CF's dead or dying. I know it interests some. It bores me to tears.
In fact, I really think enough's been said on this whole matter. Nothing new is being added here, so I will now close comments.
Yes, I'm basically picking up my toys and going home. As someone once said on his blog in response to me when I was challenging him, "my blog, my rules".
It's the first time I've invoked that executive privilege here on my blog, but thus it shall be. Moving on to other more useful subjects and use of time.