The End of ColdFusion

The marketing gurus at Adobe have just released an Evangelism Kit for ColdFusion [via Damon Cooper's Blog].

For as long as I've been using ColdFusion (over 3 years), I always heard detractors saying it was a dead or dying product. We never got much help from Adobe (or Macromedia) in justifying ColdFusion; we were forced to speculate on the future of the product, and the number of customers using it. I suspect that Adobe never had the need to justify CF; sales were fine, and so too, most likely, were revenues from the product.

So now I am going to become one of those detractors. Let's just say that this kit hasn't inspired me. On the contrary... I can't but feel that this Evangelism Kit spells the decline of ColdFusion. Here are few things to consider:

• Why now? 10+ years without such an offering. Why create this document now? I suspect that some of the major clients listed are actually migrating away from CF, so better to indicate that these companies are using CF while it is still technically true.
• Where are the exciting new features? I mean, look at the roadmap. Sully features "enhancements". I'm surprised "bug fixes" didn't make it onto that list.
• Open source competition: Blue Dragon, Railo and more
• Leveraging other products and scripting languages as middleware in the RIA stack: Groovy (the boys at Broadchoice, filled with names synonymous with ColdFusion, are using Groovy more and more these days: 9 posts tagged with "Groovy", zero posts tagged with "ColdFusion"), PHP, and Ruby.

I like ColdFusion, so I hope Adobe can keep it alive and keep its developers highly productive, but just when I think Adobe will push to make CF mainstream, I feel they took at least one step backwards, and may not have any more momentum to move forward.

iPhone: Apple should support Google Gears

A major criticism of the iPhone is the lack of an SDK, which prevents developers from writing custom applications. The only way for your application to run is via the mobile Safari web browser as a standard web application (HTML + Javascript). So this really raises the question: what do you want to do with an SDK that you can't already? This isn't strictly an iPhone issue, as we could try to develop a framework for all applications regardless of their target platform, i.e. when should one write a web-based application or write a so-called "desktop" application.

Under most circumstances, a web application is probably preferred because:

• there is no overhead in installing or updating the application


• data is stored remotely, so it's accessible regardless of where you are or which computer you are using


• it will run on multiple operating systems with little extra work

So what's missing? Naturally, there are a few things:

1. Access to other applications, either currently running or otherwise installed on the system


2. Using the application when no Internet connection is present, although I tend to agree that also think that this has diminishing returns


3. Security; individuals often think twice about storing private data on third-party servers

I'm probably in the Apple camp with regards to the first point. We don't want applications to interact with each other (or with the Phone OS itself) because this may have security implications for the owner and the network. I don't want to have an anti-virus running on my phone or iPod, to be sure. And I don't want to risk the possibility of my phone being hijacked to run some scams using my voice minutes. The risk is just too great.

So how can Apple help mitigate the second and third point without introducing a complex SDK? Easy! Apple should support the Google Gears on mobile Safari (and regular Safari, for that matter). With Adobe's support for Google Gears in AIR and Apple's adoption, we may see the Gears API become the de facto standard API for occasionally connected web applications.

Wouldn't that be nice?