As you may have noticed, my website recently underwent a significant facelift as explained in a blog post made a couple of days ago. In that post I also noted that as part of the update I rewrote much of the code “to use ColdFusion for what it does best, and to stop using it where it no longer makes sense to do so”.
Obviously, a statement like can’t be left unexplained, and indeed, the first few comments on that post asked me to do just that. The truth is that when I wrote that post I did start to explain what I meant, but as the explanation grew it felt out of context for that post, and so I planned a follow-up. This is that follow-up.

Just to be very clear, I am not abandoning ColdFusion, a technology I have been using for almost as long as it has been around, and a product that I have closely tied my own professional reputation to. I have been a ColdFusion fan since the day I discovered it, and remain one to this day.

So, where exactly do I see the use of ColdFusion as no longer making sense? I’ll explain that in a moment. But first, by means of introduction …

ColdFusion has been around for over a decade and a half, with over a dozen versions brought to market by three different companies. During that time ColdFusion has undergone numerous changes, but one thing has remained constant, and that is the reason to actually use ColdFusion. The original reason to use ColdFusion way back when, and it is still the reason we use it today, is that it is an incredibly productive platform. Really, that’s it. Once you get past marketing materials and tag-lines and promo videos, ColdFusion’s entire raison d’�tre can be summed up in that one word – productivity.

Way back in Cold Fusion version 1 we introduced a tag to perform database queries. It was easy to use (well, maybe not in DBML, but we fixed that quickly, and using it got even easier and simpler in subsequent versions), and it just worked. To this day, the brilliant simplicity and power of <cfquery> remains the benchmark that any other platform seeks to emulate. We added <cfmail> which made programmatic delivery of SMTP email messages as simple as it could possibly be. In ColdFusion MX we added what I consider to be the most important enhancement since those first releases, the introduction of the ColdFusion Component, and with it the ability to encapsulate business logic and processes into neat clean hermetically sealed units. And then we added the ability to work with spreadsheets, and manipulate images, and communicate with Exchange servers, and so much more, all in the name of greater productivity. All of these features black-boxed otherwise complex server-side operations, and in doing so made us even more productive.

We also introduced a different class of features, ones that simplified the use of client technologies. A perfect example of this is form field validation via <cfinput>. This tag, introduced in ColdFusion 3 (way back in 1997), generated client-side JavaScript so that developers would not have to do so themselves. This tag was actually rather contentious when first introduced, there were many who hated the generated client-side code, and preferred to do the work manually, rightfully insisting that in doing so they’d have greater control and cleaner results. I, however, was an ardent advocate of <cfinput> and related tags. For me it was yet another productivity play. Sure, I could have written the client-side JavaScript myself, but that would have been a slow (and highly error-prone) process, and I was willing to sacrifice some performance and control for that greater productivity.

And so, like many other ColdFusion developers, I used <cfinput> for many years. But I don’t use it anymore. Why not? Well, let’s look at an example:

The above code snippet is a fairly simply (and typical) use of <cfinput>, it makes two input fields required, and requires that the second contain a valid email address. If you were to use this code, ColdFusion would generate the necessary JavaScript to perform the validation and would embed the generated code (and includes to external .js files) at the top of the page.

Here’s another example:

This example uses the popular jQuery Validation plug-in to perform the same validation. The code snippet is obviously a bit longer as you need to include the .js files and call the validate() method, but it’s really not that complex. And once you get the hang of using jQuery and this plug-in, you can do so much more with it. You would have total control over the UI, things like highlighting the failed validation fields in red boxes, displaying failure counts, writing custom validation, etc. And you could even consolidate the validation rules into one place, like this:

When we first introduced <cfinput> few developers knew what JavaScript was (heck, back then most thought that Java and JavaScript were one and the same, and that applets were Java). As such, back then <cfinput> made sense because it made us productive. But is it really productive to use <cfinput> now? The jQuery example just shown is cleaner, does a whole lot more, is easy to write, and is actually very productive in its own right. And truth be told, even using jQuery and this plug-in is becoming dated, HTML5 adds native options for form field validation, and while it’s probably not safe to rely on this yet (for anything other than mobile web sites and apps), expect to be able to do so in the near future. And so, to be brutally honest, <cfinput> is just not needed anymore.

And <cfinput> is just one example, another is <cfgrid>. Way back when displaying a grid that allowed sorting and paging and filtering and more was painful (and not even possible with things like Java applets), and so <cfgrid> was invaluable. But now? Look at this code:

Title 1 Title 2 Title 3
A value Another value Yet another value
A value Another value Yet another value

This example uses another great jQuery plug-in named Data Tables. As you can see, it requires that data be placed into the already familiar HTML <table> (and if you are using ColdFusion then the table could easily be generated using <cfoutput>). Then a single line of code turns the table into a paginated grid that is sortable, searchable, and completely customizable. So, once again, no more work and lots of upside, that’s productivity at its best.

And I just presented two jQuery examples (both of which I am using on my new site). But there is a lot more out there beyond jQuery, and you can (and should) be open to taking advantage of it all. The way I see it, web browser technologies evolve and improve, and the range of libraries and options available to us developers evolve and improve with them. And as more productive solutions become available, we should adopt them because, well, they are more productive, and productivity is why we’re even having this discussion in the first place.

So, when I said that I wanted “to use ColdFusion for what it does best, and to stop using it where it no longer makes sense to do so”, that’s what I was referring to.

What does ColdFusion do best? Lots of things, starting with database integration. It is also great for encapsulating business logic (for example, my book pages are highly dynamic, there are entire sections that apply to some books but not to others, and a set of relational database tables are used to drive those pages, all beautifully encapsulated in clean CFC methods that expose the data and flags I need to render the pages). ColdFusion is also perfect for wrapping external services and libraries into clean useable chunks (like monkehTweet which I use to interact with Twitter, and CFlickr used for Flickr integration). That’s where ColdFusion shines, and so I implemented all of that functionality using ColdFusion.

Where does it no longer make sense to use ColdFusion? In my opinion there is no longer a compelling reason to use any ColdFusion features that generate client-side code for you. Be it UI libraries, form validation, data grids, menus, embedding maps, and more, there are now so many alternatives that are clean and lightweight and easy to use that it is more productive to just use those instead. So I am using jQuery validation libraries instead of <cfinput>, client-side grids instead of <cfgrid>, and so on. No more <cfmenu>, or <cfwindow>, or <cfcalendar>, or <cftable> which was introduced in Cold Fusion 2 and made little sense then and even less now (I mean, seriously, is it that hard to loop through results and manually add <tr> and <td> tags?), to list a few. These all need to be supported by ColdFusion to maintain backwards compatibility, but there just is no good reason to keep advancing them, and even less reason for you to use them in new development. ColdFusion client code generation features just don’t make that much sense anymore.

This is not an attack on ColdFusion, nor is this a novel idea. Way back in 2000 I wrote an article entitled “When Not To Use ColdFusion” in which I explained that the best ColdFusion apps were not just ColdFusion apps. Rather, they were the ones that used the best technology for the job, all held together by ColdFusion glue. That’s why ColdFusion supports XML and Web Services and server-side Java and CFXs and even .NET integration. The objective has always been to use the right tools for the job, recognizing that what is right for one project may not be right for another, and that what is right today may not be right tomorrow. And now, what is right is to use ColdFusion for back-end functionality, and to stop using ColdFusion client-side abstraction features.

And that’s what I did in the rewrite of this site. I am indeed using ColdFusion for what it does best, for what it does better than any of the alternatives, but I have stopped using it where other technologies are preferable.

I hope this explains my statement, and I’d love to hear your thoughts on the subject.

38 thoughts

  1. Essentially you’re just doing what most experienced developers (or teams) do, crafting your own front end HTML/CSS/JS instead of using built-in "helper" code. Of course ColdFusion is still awesomely productive on the back end 🙂

  2. Hey Ben, great updates to your site and 110% agree on when not to use ‘x’ server technology for things that clean html, CSS and JavaScript can do client side. That is one of my big issues with a lot of the templating frameworks out there. Lots of helpers and new syntax for what pure html can accomplish.
    Keep up the great work.

  3. Yes! It’s about time someone came out at Adobe and said that ColdFusion shouldn’t be doing some of these purely client-side tasks anymore. Back in the day they were useful, now client side technologies have improved beyond the point where ColdFusion can realistically keep up. Many of the client side libraries advance far faster than releases of ColdFusion come out and thus these ColdFusion features become "stale". In my opinion I would add CFMAP to that list.

  4. Bravo. Well said. I hope Cold fusion can stay relatively productive compared to some other competitive BaaS tools coming out these days. If server side is its shining point then speed and code generation might be the area to focus on.

  5. I have *never* liked the client-side stuff that ColdFusion allows one to use, even the AJAX parts. I understand the rationale to some extent, but at some point you hit a wall where use the canned CF implementation creates more headaches than it solves.
    I use ColdFusion because it makes doing what I need done on the server-side super easy, and use ExtJS (or jQuery if I have to) to handle all the client-side goodness that is needed.
    I appreciate the points you made, and hope to see the CF team focus more on making more awesomeness happen where CF really shines.

  6. Thanks for the explanation Ben: it was far less controversial than I thought you might have meant when you made the original statement in your earlier blog article.
    I’d take this conclusion you’ve reached further, if I was Adobe. These features you mention CF has are no longer a good way of doing things, so Adobe should *actively* discourage their use. I think the whole lot should be officially deprecated, with an explanation in the docs to the effect that before the JS community "formalised" itself and took a coherent approach to things, these HTML/JS wizards CFML offered were a great approach, but now they are not a great approach or even a good approach; and the docs should go on to provide examples and tutorials as to how to effect the equivalent to the CFML functionality in vanilla JS/HTML.
    It’s fine to admit when an approach is out-of-date, and this would be "the responsible thing" for Adobe to do for its community: admit its ideas here are now obsolete, and provide guidance as to how to move on.
    I stress I say "deprecate" and not "obsolete": the tags should be left as-is functionally, Adobe should simply discourage their use. And no further development along those lines should be undertaken.


  7. Thanks for the follow-up. Those front-end tags should never had made it to the language in my opinion. I think that they are responsible for the bad reputation of the language in the web development community too. They are so heavily "marketed" by Adobe (look, "ColdFusion can do Ajax") that there is no room left to highlight much more interesting server side features. The ones web developers care about, not designers.

  8. As someone who has also recommended against the Ajax tags, I want to make two points though:
    It may make sense to be clear to others (ie, if you tell others "Ben said…") that there is a difference between the Ajax UI stuff in CF and Ajax support in general. I truly think that the simple "returnformat=json" feature for CFCs is one of the most powerful things ColdFusion has. That’s something I’d never want to see CF abandon.
    Secondly – I’d make an exception for WebSocket support. I don’t know how many people here have tried it, but imo, it is an incredibly sophisticated WebSocket implementation. Yes, it does front end stuff, but in a very minimal way (you need to write all the JS code to actually make use of WebSockets).

  9. @Ray
    I’d definitely differentiate between "interacting with the user" (CFFORM, etc) and interacting with the browser (AJAX proxies, web sockets, etc).
    It’s only the former that I think has had its day, and should be discontinued.

  10. @Jean:
    I think you need to consider the historical context. When CFML came out with the bulk of this stuff, there was no such thing as JQuery or ext JS or any of the rest of the formalised JS libraries that we have at our disposal now. *At the time* st

  11. I totally agree with Ben and feel that if Adobe doesn’t recognize this and lower the price, and increase support for the things that it is supposed to do (ehhem .NET), they will price themselves out of this market. How do you convince a client, who’s already purchased M$ Windoze, to drop another 5k on Coldfusion? It still has potential!

  12. Well, now that you mention it…
    I use cfform preservedata="yes" along with cfinput so that I don’t have to supply the value attribute to form fields. When I read a record (row) from the database, I loop over the columnlist and cfset form[FieldName] = HTMLEditFormat(qry[FieldName][1]).
    I know cfform generates some JavaScript, but I haven’t found a cleaner way to fill in input name="X" value="#form.X#".

  13. I agree with this wholeheartedly. Some of the client side things made sense "back in the day." But no longer. These tags should be deprecated (but not removed) from the language. If the underlying code is using some paid & licensed library, however, it should be removed from the language.

  14. I am just saying that all this front end stuff (a Text Editor???) ended up arming ColdFusion, the language. I can’t imagine where it could be if all the energy spent on marketing fluff to "decision making managers" and "designers wanna be developers" had been dedicated to promoting the language itself. I have not seen one thing in other languages (Ruby, Python, php) that is easier to do than with ColdFusion. And yet ColdFusion is dying, slowly – proof: we have to use the search engine on Adobe’s home page to find anything about it. It is a shame. And a waste.

  15. Jean, I am not sure that I’d go that far. cfinput was important back then, users needed it, and there weren’t alternatives. ColdFusion should do things to make us productive, but it also has to know when to back off, when those things have become less valuable and less productive.
    Raymond, your comments on Web Sockets are a perfect example of what I was referring to when I said "that what is right today may not be right tomorrow". Yes, right now that is productive. But when is ceases to be so, we need to be willing to deprecate a feature and recommend alternatives.
    Wil, Adam, yes, cfmap is one that never felt right for me. Same for cfwindow and cfpod and cfdiv, those were obsolete they day they shipped.
    Adam, cfchart is one that was very important to include back when we did. But you are correct, it is now less useful when they are alternatives.
    There’s a pattern emerging here.
    — Ben

  16. As a coding lightweight compared to the people responding to this blog, there may be a collective "ugh" when I suggest this, but the request and need is sincere:
    I think there is a HUGE need for Coldfusion (Adobe) to continue to develop user-facing parts of their Coldfusion solutions. In fact, one of the reasons it’s dying is that TRUE ease of use is not there…just productivity tools for really good full time developers.
    But, like Apple does with their spec lockdowns, if Adobe would develop an interface "Coldfusion Safe" library of javascript or jsquery that is plug n play using, say, Filemaker Pro’s ease of use as a benchmark, the community would explode with users: Use English words, code-helpers, etc.

  17. Thanks for following up, Ben.
    Like most others here I agree with you that functions that produce JavaScript and HTML are not needed in the language anymore since there are now superior options that it would be very hard to compete against.
    Would be nice to see Adobe deprecate these in the future. In fact it’s probably needed if we want new developers to take ColdFusion seriously.

  18. Lots of gem here…
    I particularly love the "the best ColdFusion apps were not just ColdFusion apps. Rather, they were the ones that used the best technology for the job," statement, my recent cf(Railo) app utilizes jQuery as well.

  19. I was hoping to see updates in CF10 regarding using CFDocument to generate either "Adobe" FlashPaper or "Adobe" PDFs. I’ve encountered lots of rending issues from when these features were first introduced and they’ve apparently never been upgraded or fixed.
    I don’t want, need or even care about features like CFTextarea or CFMap. These features are always evolving and I can read the publicly available information on how to integrate the latest versions of CKEditor and Google Map APIs without having to be beholden to Adobe’s update schedule. CFINPUT never made sense to me so we rolled out our own validation library and later standardized on jQuery and switched to jQuery Validation.
    I wish there was more focus on strengthening core features of ColdFusion. Take CFSpreadsheet for example… ColdFusion still can’t format a "date" value when generating Excel files. Why not? My work around has been to use the POI java library instead. When adding multiple spreadsheets into a single Excel file, the styles & column widths of all worksheets other than the first one are completely screwed up.
    I’ve had to rely on third-party Java, C++ components, Python and CRON services to read CSV files properly, create thumbnails, perform some CFHTTP requests, create advanced graphs (not relying on javascript or Flash), generate sprites, stamp text on a PDF (since CFDocument doesn’t like some non-Adobe PDFs) and perform scheduled tasks reliably.
    I have CF10 ready to be installed, but each time I’m ready to do it, another alert comes out from Adobe or regarding the auto-update not working properly, problems with IIS or other show-stopping features not working as expected. I "really" want to upgrade too, just not as excited about all the new potential problems I’m going to discover the hard way. 🙁

  20. Depending on the application, or form, client-side validation may not even be important. It’s main use would be for text fields (and of course for check boxes and radio buttons) but perhaps indicating the field is required (or something like "at least 10 characters") is all that is necessary. We should all have (ColdFusion) server code that can accept a variety of formats for many character input fields. Regular expression validation is frequently unnecessarily unfriendly and your code should often allow, for example, optional spacing and hyphens. You should be doing data validation in your server code, on all input, even if you are using stored procedures. Client-side data validation has nothing to do with security so you have to balance the work required with the gain. The gain is often minimal. But for lengthy forms, jQuery or other javascript is particularly valuable. Soon HTML5 can take care of most of what’s needed. Just my opinions. 🙂

  21. @JamesMoberg Amen! I’ve become a Java expert because of everything I have to do in POI to make an Excel spreadsheet look presentable. I’ve spent hundreds of hours tagging PDFs generated by CF because they need to be accessible and CF can’t do that. I’ve

  22. Way back in 1995 you helped me get started with ColdFusion, Ben. ColdFusion was my introduction into the web development world. Seventeen years later it’s odd to look back and see where I came from and where I am now. Much of that thanks to ColdFusion and people like yourself.
    These days I am not using ColdFusion daily, since I have transitioned mainly to a UI developer. However, my feelings over the last few years on ColdFusion have been very mixed, and many folks have heard me openly criticize CF. My arguments mainly center around this topic that you have discussed here: There is, by far, too much legacy stuff in ColdFusion. It needs a major overhaul. All of this legacy stuff needs to be pulled out of the engine and made available as plugins for backwards compatibility. It makes me sad to see all the effort Allaire, Macromedia, and now Adobe, have put into "extras" that really had limited shelf life when that time could have been put into furthering the core engine and language, and leaving the community to develop or maintain plugins for the engine.
    A good example of this is <cfreport>. It’s based on an "ancient" version of Jasper Reports. Can you imagine how powerful <cfreport> would be today if CF had allowed for the community to continue maintaining support for Jasper? Jasper is a potent BI platform these days, and the tooling is so much more powerful (and reliable) than report builder.
    I’d really love to see Adobe take a more objective approach on this and consider a release that focuses solely on getting rid of the fat and making CF more extensible by the community, as well as minimizing the size of deployments needed to be pushed to the cloud. Tomcat was an essential change, but there’s still a ways to go and I am afraid the commitment is just no longer there.

  23. Great post. I’d classify this as ‘things you feel good about knowing a few years ago’. Adobe needs to strip(deprecate) the unnecessary clientside fat and either drop the license fees dramatically or go totally open source and be the #1 premium support vendor. For server side advancements they should focus on continued easy integration of complex java libraries (Hadoop comes to mind) Anything that reduces the roundtrip from server to client.

  24. I agree with packaged logic vs writing verbose code over and over Ben. You did mention in 1977 we added custom tags and that is where you would replace your example with code like this.
    <cfimport prefix="jui" taglib="/share/tags/jqueryui/" />
    <jui:form id="frmLogin">
    <jui:textBox id="name" required="true"/>
    <jui:password id="password" required="true"/>
    <jui:submit />
    In fact packaging up JUI in general with custom tags would be simpler than HTML and following the scheme of <cfimput>. Your examples make sense but if we package our code for reuse then the JUI tags as shown here can handle the JS and CSS just like the <cfinput> tag did. The result would be lighter weight that internal CF JS and actually extend the reach of creating and sharing these tags at large.
    Sadly when the community went to CFCs it seems they baby went out with the bath water and we failed to understand view code still shines in CFML via packaging up into custom tags.

  25. HI Ben,
    We are on the same page. I’ve been using Coldfusion for the last 8 years and its great to do server side stuff. But as you said <cfgrid> and <cfinput> and all those added thing just don’t make sense. I am a firm believer that if Coldfusion creators and current developers concentrated in the server side aspects of it and continuing to make our lives (us developers) easier. It would have a much better acceptance between new developers.
    I just thing that all the added overhead does not make sense. Keep it simple and small. Just get rid of all the bells and whistles and keep the core of it, that functionality that we love to do server side coding much simpler.
    I have tried in the past to use <cfform>, <cfinput>, <cfgrid> and after a bit of time playing with them and just complicated my life. Just as you and I guess many others; I turned back to jQuery mostly or just plain custom JavaScript. It’s just a lot easier to write your own client side JavaScript than try to make Coldfusion integrated stuff work.
    Big thumbs up on this article, I am with you on this one.

  26. Perhaps the most profound way to put why Adobe should shift from some built in features is because it fails to achieve collaboration. I can remember when Max was in Chicago there was a ColdFusion United mini-conference the day before. Ray Camden did a presentation on what was new in ColdFusion and he said if he only had one feature CFAJAXProxy was worth upgrading for! (And Ray is right, the feature is awesome if you don’t move outside CF… will explain below. Timeline wise he statement was correct so I mean no disrespect.)
    While it is cool and the things you can do with it dog and pony very well other things have come on the scene that are game changers. jQuery has totally changed the game and if it had not then EXT.JS would have. ColdFusion may have built in some EXT.JS but it was never safe to throw in the current files because they could break built in functionality. Then there was MooTools also. Each of these tools has brought lots of extensions to us. If we package these extensions up into custom tags we cannot do binding.
    We also see new technology is thriving that moves templating from server markup mixing with data to client side templates. My point is when things are new (AJAX) it is helpful to have them built in and Adobe did good on that. The internet has matured though and either they need to totally rethink AJAX so everything is extensible even to our custom tags or they need to depreciate built in AJAX support. When the needs of a project expand the built in solution gets in the way as an unsustainable coding practice.
    I am curious how many people are using the binding features in their code today. It would be curious the best way to implement that a bit more universal. Would be choose backbone, knockout, kendo or should that move completely to custom tag libraries so the suites can be built around key technologies that are standards for sites?

  27. I enjoyed this post. 🙂 I feel the same about using the right tools for a job. I am currently developing actively in PHP , jQuery , MySQL and I have a strong background in design/art.
    I have a client who has come to me with a hefty project and I am seriously considering doing it in CFML!
    I have looked at the facts(age,speed,innovation,usability,SECURITY,DEBUGGING,cost,time,cost/time,on and on…)and opinions (personal preferences lol…) about web interface options. Serious consideration has only made precarious position of "bidding while on the fence" even more noticeable to me. This is not the norm for me. I usually just dive into things and figure them out as I go. Arrg… I think this could be a turning point from php to coldfusion.
    I am passionate about my code. I love that php’s complexity grows when a person doesn’t plan things from the singleton points first. eg… ..what are the most important numbers , pieces of data , database interactions… ..ect. I appreciate that coldFusion has great database relationships and I assume CFML structure is also greatly simplified with well organized planning.
    So , in all due respect , when faced with php and coldFusion , when is the right time to use php?

  28. I have been a ColdFusion developer for years and now I am an unhappy camper. With Dreamweaver I could do a search and find all the reference to stored procedures or templates. I could then drop the results into a spread sheet sort it this way or that and have the documentation I am required to produce. Now if I had a little app this would not be a problem, but with around 6000 stored procedures to modules I am in deep water. The search reults will only let me copy one line at a time, yeah that will get me done on schedule.
    Short of takng the code home and using a real old pc that has deamweaver on it I am at a loss as how to get this crossreferencing done.
    And I am not allow to take the code home in any case.
    I can’t beleivve I am the only developer that has to produce this kind of information.
    Help PLEASE.

  29. CFCHART should go as well. JS High Charts is much better. No flash required. So much cleaner and more customisable.
    Plus you can use High Charts with Railo…

  30. I would also like to see jSoup HTML DOM parser integrated into CF as a tag, so that I can analyse & amend the DOM on the server.

  31. Hi Ben,
    Good article….I have a question… my customer is moving our CF app to the AWS cloud. Because of the CF licensing CF is not scalable in the cloud. Unfortunately I looking for an cost effective, light-weight and easy was to migrate my code to another language. What do you recommend? Is there a tool to help convert to the code?

Leave a Reply