ColdFusion Job Trends

Reader Soja just posted two interesting links in response to the ColdFusion relevancy article that show ColdFusion job and search trends in relationship to PHP, Ruby, .NET, and JSP.

The first link is to the job site Indeed. Here it shows ColdFusion job postings on a slight decline since April '05, with the interesting bit being that Ruby job postings have increased to the point where they're on a equal footing with ColdFusion's.

The second site is Google Trends, which shows the number of searches done per language as well as mentions in the news. The former shows the massive number of PHP-related searches, with all of the others cluster in a tight group at the bottom of the page, but still with CF coming in last.

In News Reference Volume, CF is hardly even visible, only popping up above the baseline occasionally.

While none of the stats are hardly conclusive, much like the bookstore shelf space stat mentioned in the earlier article, together they begin to paint a picture of where CF resides in the general marketplace.

In several comments here and on other sites readers have also pointed out what I like to call the "Mercedes" premise: that it's okay to occupy a premium niche in the minds of the marketplace and developers.

That said, I'm not sure that if I asked a hundred developers to name a "premium" web platform many would name ColdFusion.

So is it a premium niche? Or not? Or just a niche? I'm sure Adobe would prefer it to be the platform of choice... but how do we get it there?

Interesting questions, and I'm none too sure of the answers.

Comments

[SoJa]

I am honored that my small comment sparked an entire blog entry. As a CF-vet (since 3.x) and converted C# developer I offer these observations. Remember, these are NOT facts, just my observations.

1. True separation of tiers. We all strive to separate the tiers, right? MVC, MVP, Business Presentation Data, etc. If the View knows anything about the Database (column names, column data types) then the line between these layers is eliminated and a dependency is born between the View and Database allowing scalability to suffer. This is true if the View processes anything delivered by CFQuery (recordsets). A common approach is to create an Array filled with CFC business components but this leads to another problem. If the recordset contains 1000 records then the code will parse through all 1000 records 3 times to achieve this separation. (1) CFQuery fires SQL against a database table looping through the result to add rows to a recordset in memory. (2) A custom loop must then be created to instantiate the array of business components. (3) This array is then looped through to display the content on the page. On cflib.org I saw a cfscript equivalent to cfquery that may work here… the key is to loop through your data twice. Once to create a collection of instantiated business components and once to display them.

2. Self-describing web services. IMO, web services should describe exactly what they return. Returning a CF structure is just not good enough. If I, as a web service consumer, have to look at WSDL to determine how to pull data then the web service has failed. To my knowledge serializing a collection of CFC business components does not result in this behavior. My organization simply does not use CF for web services anymore because of this. We have non-CF services that describe exactly what something like a ‘Product’ class consists of… and CF can consume it just fine. Something like ‘#getProduct().getPrice()#’. This exact same server is then consumed by Java and .NET like this: Product.Price

3. IDE support. CF developers deserve a decent IDE. In an environment where common business components (CFCs) are used amongst several applications I, as a consumer of the common components, should NOT have to sift through the CFC code to find its public methods. CF-Eclipse, I have read, is heading in this direction or may do this already… but Adobe needs to produce something.

4. GET/POST requests across non-standard SSL certs. In the government world everything is being delivered via SSL. But these certificates are not generated from a trusted authority (Verisign, Thawte, etc). Firing off CFHTTP or Web Service calls against these servers fail every time. YES, there is a way to add these certs to the JRUN server and yes, it is supposed to solve this problem. … but we have done with 6 of our CF servers… 4 still cannot make requests through these certs. Too much time was taken trying to solve this problem with CF. This problem is easily solved with ‘other’ technologies without server settings (custom 3-line certificate policies).

CF put a lot of food on my table for many years and I do like its simplicity and RAD nature. I and the organizations I support just do not want to keep fighting with it as we move towards common libraries of business classes, n-tier architecture, and SOA. As developers we MUST not allow ourselves to become stagnate and focus on ONE technology or niche. Focus on concepts like Test Driven Development, OO, Gang-of-Four patterns, SOA … eventually the languages really won’t matter. It’s just different syntax.