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.
Leave a Reply