By Peter Bell

Railo: The Future of Web Development - Easier or Faster?

Part of an ongoing series explaining why I decided to head up Railo US starting this month . . .

What is CFML Good For?
There are two ways you can look at CFML. One is as a set of training wheels that allows someone with little programming experience to build working applications while they learn enough to port to a "real language". The other is as a RAD application development language that allows any programmer to build compelling web applications more quickly and cost effectively than they could in any other language . . .

Historically I would say ColdFusion was definitely the latter. There are many CFML developers who could easily use other languages but choose CFML instead. It's a dynamic language that allows you to deploy applications on the Java Virtual Machine (JVM) with a solid tag based templating language and (soon) a complete scripting language for writing your model code. Two years ago there was simply no credible competition for dynamic RAD scripting on the JVM so CFML had an excellent value proposition for developers irrespective of their skills. Along Came Groovy
And then over the last year or so I noticed a trend. Sean Corfield, Joe Rinehart, Brian Kotek and even Ray (the CF Jedi) Camden started to use Groovy for some of their business model code. Barney Boisvert introduced his CF Groovy library. Then Doug and the team at Alagad mentioned that they were going to use Groovy for their model in future. I had to wonder "what is this Groovy and why are so many top CF devs starting to use it?"

After working with both Groovy (a programming language) and Grails (a Rails influenced convention over configuration framework based on Java libraries such as Hibernate, Spring and SiteMesh) I now believe that they allow experienced developers to build web apps more quickly than CFML + (CFML framework of choice) currently does. Of course, it depends on the details of the use case and the background of the developer, but while I still think CFML is much easier to learn, I don't think it is any more productive than Groovy and honestly for a lot of apps, CFML is currently less productive than a corresponding Groovy/Grails solution.

Does it Matter?
OK, so Sean and a bunch of "rocket scientists" are gonna go use another language. Who cares?

I do.

If the best CFML developers leave, we're going to be left as a language for beginners, and the fact is there aren't that many beginners building important web applications today. We *need* people promoting initiatives like cfSpec for Behavior Driven Development, ANT for automating build tasks and MXUnit for Unit Testing, and if all the guys doing that start using other languages that won't bode well for the future of CFML.

Why Fast Beats Easy
I love that CFML makes hard things easy, and I think it should always continue to do that. It allows us all to write simple procedural scripts when we need them and makes it very easy for new developers to get started with CFML. But I also think it needs to make experienced programmers faster - here is why . . .

The Problem with cfmail
When they first came out, tags like cfmail and cfquery were revolutionary. A single line of code and you could connect to a mail or database server without worrying about the plumbing. It meant that every time you wanted to do a query or send an email you saved a bunch of time.

However, if you're building well architected OO apps, these days you probably find that you don't use either of these tags very much. You probably have an ORM like Transfer handling your db access and a custom built NotificationService that you call to encapsulate all of your mailing activities so you can easily add logging or other business rules around all of the notifications that your apps send out. If you do that, does it really matter whether the framework author (whether it's your framework or a third party) had to write one line of code or ten the one time they implemented the query or mail functionality?

A Change in the Web
At the same time, web applications are changing. They are becoming more business critical and need to be more maintainable, testable and better architected. As such, most companies are now increasing their budgets for web applications and the smart ones are looking for developers who understand and use best practices like TDD, automated builds and Continuous Integration to deliver maintainable applications that will grow with the business needs. Most such programmers are polyglot (they can code in multiple languages), and quite frankly the time they spent in honing their skills with TDD, their IDE of choice, understanding Continuous Integration, OO patterns, best practices and the like dwarfs the time it takes to pick up the syntax of another scripting language.

For such developers, they need a language with frameworks and tools that allow them to build maintainable applications more quickly and cost effectively, and with a vibrant community of other professional programmers also interested in using best practices to build their apps.

So, What Should We Do?
For the average ColdFusion developer it makes no sense for them to go out and learn Groovy and Grails. It isn't just learning a new language - it is entering a new world of Java servers and WAR files and libraries like Hibernate and Spring as well as the different syntax and IDEs. Most CF devs are not going to be able to do a one month pilot project in Groovy and Grails and to deliver a production ready app.

However, there are many things in Groovy and Grails that are attractive to experienced developers, and we need to bring those back into CFML so you can get your feet wet in the bigger Java world without giving up the frameworks, syntax and community that you know and love.

One of my goals with Railo is to make sure that we deliver a language that is both easy to get started with *and* productive for experienced developers who might otherwise choose something like Groovy. I think that is how we will ensure the future for the CFML community.

One thing some people have asked me is whether I think Railo is good for the community. I have thought long and hard about that and I believe that it definitely is. However, if you want to know why, you'll have to wait for tomorrows posting (yeah - I'm done for today so you can actually get some work done now :-) ).

Ok. Continuing to play devil's advocate here but...going back to your argument the other post along with this one...

Aren't you threatening to create two classes of CFML developers, "advanced" ones that use Railo and the common masses that use ColdFusion? Is that good for the community? I mean should PHP developers who care about OO and TDD create a new PHP so that they don't have to cater to the needs of of those who want to "[use] pre-built packages and the absolute minimum of spit and bailing wire"? To me this kind of argument leads to a further fracturing of the languages and communities...and that is my fear with regard to Railo's current direction.

You and a small percentage of CFML developers may not use CFQuery or CFMail much, but I guarantee you that if you go look at the CFML apps that are actually deployed in production throughout the world, 95+ percent of them do (and that is probably understating it). Does that mean we shouldn't push for changes that advance the language and best practices in ways that can help CFML developers improve? Of course not. However, this doesn't have to be done by splitting the language and community along the lines of the "experts" vs the "masses."

And then the question becomes, even within your argument here, if the language features already exist in Groovy/Grails that this expert developer group appears to want, what is the point? Removing personal biases and sentimentality, if Groovy and Grails are legitimately better suited for your purpose than CFML, what is it you are trying to save?

I am trying to think of another language that has been split in that manner by a competing may be that I am blanking but I am not coming up with one offhand. Curious if you and/or a reader can come up with one (I am not saying there isn't one...just I can't think of it off the top of my head). Either way, I would argue that it has a potentially profound effect on the long term viability of the language whereby its status is dependent on the backing of a large company for whom the language/product are profitable (for the moment).
# Posted By Brian Rinaldi | 4/6/09 12:27 PM
Hey Brian,

I don't think Railo is just about advanced developers at all. I think that features like resources which allow you to just cffile - whether to RAM, ZIP, Amazon S3 or the server file system and the cfcache tag are great examples of Railo making hard things easy and that continues to be the core mission. At the same time, I think it is good that the language be capable of meeting the needs of the vocal minority so they stay with the language, stay vocal, continue to present, write and create frameworks. The great thing about Railo is that we don't need to choose any more, and I think that's good for *all* CFML developers.
# Posted By Peter Bell | 4/6/09 1:58 PM
I don't see Railo splitting the community with its direction so much as potentially pushing the community and/or Adobe. There was some speculation about Adobe spinning off the core aspects of ColdFusion or possibly leveraging Ralio's engine and then developing value added services on top of that core. If Railo pushes them to do that, all the better.

I also don't see where adding more advanced concepts from from the Groovy/Grails world like scaffolding or more terse scripting would split the community. The core tags and functionality - cfmail - is still there, ColdFusion is just expanding to fit some of the more advanced users like Adobe is attempting with the Hibernate integration.

If ColdFusion can grow to encompass things like Hibernate, Spring, scaffolding, etc. and still keep the basics involved, that should expand its value, not fragment the community. With that, beginners still have the parts of ColdFusion that we all got started with and the "advanced" crowd that is building enterprise apps and wants to play with more advanced concepts get what they need as well.

With all of that said, I think the bigger question is what is purpose of ColdFusion? Is the goal to be a complete top to bottom solution provider - from db to presentation? Or, does ColdFusion fit better in the controller / view parts of the application with something like Groovy on the back end so as to not re-invent the wheel? If ColdFusion were to go the all encompassing route and integrate things like Hibernate, Spring, scaffolding, etc., its biggest selling point would still be RAD. One thing I have found with Groovy etc. is that you now have to know a lot more about a lot of things, which in itself is not bad, but it takes away from the ability to jump in and generate results immediately.
# Posted By Jeff Chastain | 4/6/09 2:00 PM
OT: I just wanted to say that this back-and-forth between Peter and Brian is the so far the best exchange and outshines the more contrived CFArgument series...
# Posted By Andy | 4/6/09 3:24 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.005.