The Future of ColdFusion? Beyond Java!

At 179 pages it is a relatively quick read, but it provides an excellent perspective on how Java succeeded, the problems it solved and the problems that it now faces for “small quick web development” work.

The book is opinionated and it is clear that Tate has a bit of an agenda (Java development = slow, Ruby = cool), but whatever your thoughts on Ruby, it is a well reasoned summary of the issues facing Java and trends in language design for creating mid sized web applications more productively.

Approachability One of the most useful terms coined in the book is approachability – a measure of the steepness of the learning curve to become productive in a language. Tate argues convincingly that Java is rapidly becoming unapproachable for web application development. The language itself is fairly easy to learn, but by the time you’ve added the libraries, learnt enough about Spring to wire your components, Tapestry/Structs/SpringMVC to handle the application framework, Hibernate to implement ORM and Ant to write the build scripts, you’re talking about a heck of a learning curve (I’m ignoring JUnit only because you need unit tests in any language).

Approachability is a relative term. One of the big benefits of ColdFusion is that anyone can learn to write a simple web based application in just a few hours. And anyone who has looked at Ruby and Rails will realize that if Tate finds them approachable he is not exactly targeting ColdFusion’s core original audience - which included plenty of “enthusiastic scripters” who didn’t have a formal background in software engineering or OO design.

However at a different level ColdFusion is dealing with exactly the same problem. Web applications are fundamentally more complicated than they used to be. This means design patterns and object oriented programming are often required to keep the applications maintainable. Unfortunately for a “scripter”, such techniques are extremely unapproachable which I believe has led to much of the talk about “the ColdFusion skill divide” a few weeks back.

XML configs, AOP and DI Unnecessary? In the book, Tate suggests that XML configuration files, Dependency Injection and Aspect Oriented Programming are as popular in Java as they are at least in part due to specific limitations in Java (a lack of good language tools for handling data in the case of XML configuration files and the lack of support for mixins and functions as first class citizens in the case of AOP and DI). I personally still see a place for AOP and DI as useful conceptual tools for consistently managing classes of complexity, but I agree with his assessment that they can be implemented much more simply when approached from a dynamic language perspective. For example, LightWire - my DI framework - implements dependency injection in under 300 lines of ColdFusion code.

Killer Apps Tate then goes on to discuss Rails (Ruby) and Seaside (Smalltalk). I’m not a big fan of Rails as I don’t believe the future of object-oriented programming is in returning to table oriented design. Rails gives up too much of the power of OO programming for scaffolding that needs to be rewritten to be of use in production.

Seaside is much more interesting and I’ll be posting much more on stateful web interactions as I continue to play with Spring Web Flow and Seaside and to develop my own approach to stateful web controllers.

Conclusions I still feel there is a fundamental problem that nobody has cracked. Web applications are still too complex to build. Sure you can hack something together in PHP or ColdFusion that works, but maintaining such applications as they grow is a nightmare. Alternatives like Python and Ruby require OO skills that many developers simply don’t have, and statically types languages like Java and C# simply aren’t productive enough for most mid-sized web applications.

For now I think ColdFusion needs to continue to focus on integration (such as Scorpio .net integration) to act as “glue” and simple to use tags (to continue to be more RAD than the competition), but I still feel there is an undiscovered solution out there in simplifying not web scripting, but website engineering. Expect to hear much more about this over the next couple of months!

Any thoughts?