Comparing ASP.NET to ColdFusion is difficult. Actually, it is not just difficult, it is simply incorrect, and not an apples-to-apples comparison. In order to defend ColdFusion against a “we are moving to ASP.NET” claim, you (and whoever is involved in the decision making) needs to take a big step back. Why? Simple, because ASP.NET is part of Microsoft’s .NET solution, and ASP.NET apps take advantage of the .NET framework and infrastructure, just like ColdFusion apps take advantage of J2EE. In other words, deciding between ColdFusion and ASP.NET (and indeed, defending ColdFusion against ASP.NET) first requires a .NET versus J2EE discussion.
J2EE and .NET are remarkably alike, both in terms of objectives and the range of their various components and systems. Of course, applications and application development is not alike at all, everything from tools to languages to methodologies are different. At their respective cores, both .NET and J2EE provide the building blocks and technologies needed to build applications. Security abstractions, database support, back-end integration, system level services, transactions and messaging, run-time services, and more, are all provided by the platforms themselves. Both J2EE and .NET provide “safe” environments in which applications run (the JVM and CLR respectively), both J2EE and .NET support he use of different languages within these environments (although this potential has been realized to a greater degree in .NET), both have a scripting solution designed for web applications (JSP or ColdFusion for J2EE, ASP.NET for .NET), and both are incredibly powerful and capable.
Many organizations are going through a J2EE or .NET discussion, usually independent of any discussion about ColdFusion. And there are pros and cons to both options. J2EE wins when vendor independence, openness, and portability are a priority. .NET wins when it comes to tools, a better client experience, or simply a commitment to the Microsoft way (there is more to it than that, but that’s an entire column unto itself).
However, as many are discovering. J2EE versus .NET is not always an either or proposition. In fact, lots of organizations are discovering that they need both, and that the future is decidedly heterogeneous. This is especially true for larger organizations, there is room for both, and interoperability (primarily via SOAP) makes this a workable option.
If an organization has made the strategic decision to bet its future solely on Microsoft and .NET, then they probably should indeed use ASP.NET. Sure, ColdFusion can coexist and interoperate with the .NET world, but ASP.NET will likely be the preferred option. For organizations going the J2EE route, well, I’ve covered that one already. But for most organizations, ColdFusion remains compelling, leveraging the worlds of J2EE natively and .NET via SOAP. In fact, some organizations have discovered that ColdFusion is the simplest way to create client applications that talk to both J2EE and .NET back ends, if that is needed.
So, ColdFusion or ASP.NET? That depends on what your IT future looks like. And unless the future is Microsoft and Windows only, ColdFusion remains an important cog in the IT engine.