Submit Your Article
About two weeks ago, Hal Helms blogged that he is leaving ColdFusion for Ruby on Rails. Naturally it stirred a lot of the traditional “is ColdFusion dead?” worrying from the community, so much so that Hal posted a follow-up on ColdFusion’s death which suggests we focus on the value of applications, rather than any specific technology.
Hal’s been a father figure for a lot of CFers. His podcasts and blog posts have always been good listening / reading, with a lot of thought-provoking content. He was one of the early evangelists for OO in ColdFusion although more recently he’s pulled back from this position and said several times that he feels certain “gurus” are pushing OO too hard and spreading misinformation (although he wouldn’t name any names, which kinda created more heat than light and left a general sense of FUD around OO in some parts of the community – like we needed more of that!).
Hal listed half a dozen reasons for his shift from ColdFusion to Ruby on Rails and I’d like to talk more about those reasons in this blog post.
First off, Hal feels he’s more productive with Ruby on Rails than ColdFusion. Rails is a full-stack framework that takes away a large number of things that you’d otherwise have to think about when building an application. ColdFusion has a full-stack framework in cfWheels but it doesn’t yet seem to have gotten much traction. Given the popularity of other frameworks, especially ones that don’t proscribe how you write your application, I have to wonder whether this is because of a resistance to “opinionated software” within the CF community? During my time as lead developer on Fusebox, and more recently as the lead developer of FW/1, I’ve seen quite a bit of push back from CFers on a framework telling them how to organize their code. Hal understands the benefits of conventions and finds Rails productive because he goes with the flow and does things “the Rails way”.
His second point touches on that too: Active Record is a very proscriptive design pattern that forces you to have a one-to-one mapping between your database and your basic persistent objects as well as lumping all of your domain object’s business logic in with the persistence. Again, you gain productivity by just doing things “the Rails way”. We may see more sympathy toward this now that CF9 has Hibernate-based persistence and CFers get more used to the idea of CFC = database table at the lowest level (although Hibernate let’s you do all sorts of fancy mappings including inheritance, embedding and so on). I’m in two minds about Active Record – it can lead to an anemic domain model and/or a poor object model (if you start with the database – or a poor data model if you start with the objects), but it is certainly a convenient approach that can make you very productive.
Hal’s third reason talks about the “joy” of programming and he’s finding Ruby a really nice language to work with. I can sympathize with this because I’ve used a number of language alongside CFML over the last couple of years. I personally don’t like the syntax of Ruby (for similar reasons that I also dislike Perl and PHP) and I’m on the fence about Python at the moment. More exposure will solidify my thoughts on that. I did a lot of C++ in the 90’s and got very used to working with it. When I picked up Java in ‘97, I became very enamored of Java’s “cleanliness” and quickly moved away from C++ because I realized I’d grown tired of the fussy, punctuation-laden syntax. Over time I became tired of Java’s verbosity and repetitiveness. My first exposure to CFML was not entirely positive but my team (of Java and C++ developers) came to really enjoy the speed of development of CFML, even if we didn’t love the tag-based syntax. After using Railo for a while I find myself using CFSCRIPT more and more (because Railo has allowed argument types and defaults to be specified for several releases). The CFSCRIPT enhancements in CF9 – part of the CFML2009 specification and coming to Railo in the next couple of releases – will make CFSCRIPT even more enjoyable to program in. But CFML, for all its RAD benefits doesn’t really make me feel “joy” when I’m programming. I spent a year doing Groovy, while I was at Broadchoice, and I enjoyed that a lot. It has the cleanliness of Java but without the verbosity. It has closures which make for expressive, high-level code and it doesn’t require semicolons. That may seem like a minor point but once you get used to not needing them – in ActionScript, JavaScript and Railo’s CFSCRIPT syntax – you find them quite jarring when you’re forced to supply them (in C++, Java and Adobe’s CFSCRIPT syntax). Even so, whilst I liked Groovy a lot, it didn’t quite hit the “joy” spot for me. I’ve recently started working with Scala and, for me, that hits the “joy” spot pretty solidly. It’s a strongly-typed language but for the most part you wouldn’t know it – it infers types for you in most situations. It shares a lot of Groovy’s syntactic convenience (including no semicolons!) but it goes a step further in not requiring a dot between an object and a method call and often letting you omit parentheses in function calls. Combined with a very powerful pattern-matching engine built directly into the language, Scala lets you write some very expressive, English-like code that is also type-safe so fewer errors occur at runtime – and because it isn’t a dynamic language, it’s very, very fast! I don’t see myself leaving CFML for Scala any time soon but I look forward to writing a lot more of my model in Scala on future projects. CFML remains my drug of choice for the control / view layers.
Hal likes Rails’ migrations for handling database schema changes. I see the benefits, especially the ability to roll back changes but you still have to write carefully-crafted Ruby code to ensure that your up and down migrations work without causing data problems. I like Hibernate’s approach of managing my schema for me but with that simplicity comes a loss of control which some (many?) will find uncomfortable. Having played with Grails – Groovy’s equivalent to Rails but built on Spring and Hibernate – as well as directly with Hibernate (with Groovy), I think I’d prefer to work with a solution that leans more on Hibernate’s schema management during development and carefully-crafted SQL for migrations in production. For me, that’s the best of both worlds.
The next bullet on Hal’s list is “gems” aka plugins for the Rails framework. This is definitely an area where CFML frameworks have lagged behind. Fusebox has supported plugins for years but there’s really only a handful of useful, production-quality plugins out there. ColdBox supports plugins and provides a large number out of the box, although the 3rd party market is growing. cfWheels also supports plugins and there’s over a dozen on the cfWheels site which is a good number for a relatively small community. None of these frameworks approach the breadth of plugins available for Rails, in the same way that jQuery has a huge number of plugins. I think part of this is a mindset amongst CFers that doesn’t lend itself to open source development by default – something that is the norm in the communities behind non-CFML languages and frameworks.
Finally, Hal points to all the “little things” – the conveniences that make modern languages and frameworks easier to use. Now, it’s worth pointing out that Ruby is about as old as CFML but it’s grown up in an open source environment that has driven its pace of change at a much faster level than Allaire and Macromedia could manage. Adobe has pushed CFML forward dramatically over the last couple of releases but even that still leaves CFML a long way behind many of its rivals in the modern web development world. It’s the “little things” that I like about Groovy, Grails, Scala… None of them would be enough to make you switch languages, but once you use them you wonder how you managed without them (and then when you come back to CFML, you realize how you have to manage without them!).
So what’s the bottom line? CFML is a strong, solid work-horse of a language. It’s not particularly exciting but it gets the job done quickly and easily for nearly 800k developers and lets them do their jobs effectively. Adam Lehman has publicly acknowledged that CFML’s competition is more Ruby on Rails and similar “modern scripting languages / frameworks” than anything else these days and he’s committing to taking back the RAD crown for CFML. Hal says it was a very hard choice to switch to Ruby on Rails and I can believe that. I’ve worked in a lot of programming languages and CFML is still, for me, the most productive way to build web applications. Could I be more productive with Ruby or Rails? Maybe, but I don’t like the language enough to switch. What about Grails? Again, maybe, but it’s not as lightweight and easy to work with, in my opinion. For Java diehards, Grails is very very appealing tho’. What about Scala and Lift? Yes, Scala has a sophisticated web framework too. I’m just not convinced about Lift. I’ll read the docs a few more times and I’ll build a few more sample apps before I pass judgment tho’…
Almost concurrent with Hal’s defection from CFML was the realization that FuseNG, the recent fork of Fusebox, was truly dead (unlike CFML!). Adam Haskell, project lead for FuseNG announced on his blog that FuseNG is dead. Given that his job has moved him away from CFML and Fusebox, that’s not too surprising. Peter J. Farrell (of Team Mach-II) picked up on this news and ran with it, proclaiming that Fusebox is dead too. Fusebox is the oldest CFML framework around and there are probably more production apps built with some version of Fusebox than the sum of all the other frameworks put together. Does a framework “die” when no one is actively enhancing it? How can it, when there are so many production apps built with it? I’d say reports of Fusebox’s death are greatly exaggerated – so I asked the community… I posted to the House of Fusion Fusebox mailing list as well as the fusebox4 and fusebox5 Yahoo! Groups, asking for their thoughts on the lack of leadership and the failure of FuseNG. They were initially saddened by the news (showing how few “in the trenches” CFers actually pay attention to blogs – they just get on with their jobs, quietly and successfully – so let’s not kid ourselves about any “status” associated with even a high-traffic blog!) but then they rallied and soon a number of people were volunteering to help and it was suggested that perhaps 4CFF might be persuaded to take over stewardship of Fusebox. An interesting proposition and, in some ways, exactly what 4CFF was created for – to ensure widely used projects can’t die off through lack of active participation. It’s too early to know what will happen here but parallel remains: neither CFML nor Fusebox can be considered dead because of the huge number of developers using them and the success those developers have had.
I’ll close by pointing out another mournful blog post about CFML which tells the story of a web site being redeveloped in PHP because of a lack of available CFML developers (at a reasonable price). I get asked to recommend CFers all the time by recruiters with jobs to fill and I suggest they post to user group mailing lists and job boards in the area in which they are recruiting. There are definitely jobs out there but you can’t always telecommute and your area may be lacking in CF jobs. That’s an unfortunate situation for us to be in as a community. If you’re multi-lingual, it’s easier to get work and then you at least have a chance to introduce CFML into a new company. There’s no doubt tho’ that CFers earn more than, say, PHP developers. I’ve run into that a few times with agencies that are used to PHP but suddenly have a project and need a CFer. They’re often shocked at our rates but then they ask around and, yes, we do get paid more. Why? Because CFML lets us develop better applications quicker than PHP.
PHP succeeds because of its ubiquity, not because it is better technology. It succeeds because it has a killer array of Free Open Source software and that gets it in the door. CFML lags far behind in that area, as I’ve blogged before and as I’ve said at conferences too. Can we change that? Yes, but it will be a long, slow, hard road and we’ll need to work together more. I think 4CFF will help. I think the availability of Free Open Source CFML engines will help too.
On the other hand, don’t worry about working with a niche technology – COBOL, much-maligned at times, is still powering a large number of businesses and its developers are paid handsomely. Hal says “As developers, we’re paid to produce great applications.” and he suggests that we get our self-worth from the work we do, not the technology we use. Amen!
Topics: ColdFusion, Database, Java, jQuery, Open Source, PHP, Programming, Web Development
