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.
Defending ColdFusion Against ASP.NET
14 responses to “Defending ColdFusion Against ASP.NET”
-
I don’t know how accurate this is, but my bosses’ boss says that the availability of .NET programmers coming out of college is higher than that of J2EE programmers.
He seems to think that the average J2EE guy/gal has been coding for a while, and hence can demand a higher salary (perhaps a salary that he’d rather not pay). -
Steve, there is some truth to that. And part of it is the tools and prereqs, it is easier to learn .NET stuff than J2EE stuff, and the .NET tools are really good. Which is part of why J2EE needs CF.
-
Right on about leveraging the best of both, .NET and J2EE. What CF needs now is consolidating the above made point along with strengthing the core CF developer with frameworks such as FuseBox, Mach-ii etc. Also Flash Remoting with CF left a lasting impression on my mind when i first saw it. The day Macromedia and Allaire merged, I knew that the simplicity of CF and the eye-candy of Flash, if bound by holy matrimony, had a great future together.
-
which is all the more reason why flex should be rolled into enterprise CF. the combination will knock MS’s socks off – before they can do the same (with Avalon).
With M$’s push (they virtually give away the tools and servers for education for just the point made above) CF (and MM) need an edge, otherwise it’ll be death by a thousand cuts.
$0.02
barry.b -
Ben what do you think about bundling flex with CF enterprise? does that make sense?
-
One other point…
.NET is seen as a solution for both web-based and desktop applications whereas Java is still largely thought of as a web-only environment. I don’t know how many times I’ve heard "but if I learn .NET, I can write C# for both web-based and stand-alone applications!" -
I think the C# for both desktop and web apps argument is a valid one.
.NET has already pretty much won the desktop fight. In much the same way VB did and for much the same reasons. It has the advantages of a very large base of developers and an even larger installed user base. J2EE apps require you to roll out Java runtimes and on managed corporate environments that’s just not going to happen. Client Server apps are slowly giving way to web based apps anyway since the support issues for a client drop like a rock when you only have to support IE which ships with the OS and not have to worry about any of those nasty client DLL thingies.
I believe another reason for the rise and rise of .NET is the MS certifications scheme means most if not all of our project managers and technical architects are more certified than the actual developers. Which is kind of funny because the developers are way too busy to sit the exams but actually know how it works and the proj mans earn more but talk crap 90% of the time and mostly think recursion is some kind of annual leave code they’ve yet to discover how to wrangle. Sorry I digress.
There’s still several million lines of crappy VB6 out there (and more than a few lines of VBA in Access) and all of these port to .NET better than they port to CF if only because the "MS and only MS" developers that dominate the IS dept (there are a lot more of them about than J2EE types)recognise the IDE and some of the terminology. And it is down to things that stupid and that simple.
I’ve spent most of the last few years moving these basic client server apps to web based frameworks mostly using ColdFusion but we’re increasingly being threatened with .NET
I had a very odd conversation with our Chief technical Officer who is very "J2EE or death" and had an interesting discussion about out .NET and ASP development strategies and how they were going to get along in the brave new J2EE world that was coming. I don’t think he understood most of the long words though. A great example of a little knowledge being a dangerous thing. -
It should also be noted that .NET is in no way limiting your platform environments; with Mono your .NET app will compile to your *.nix flavah du jour.
Another thing worth noting is that w/ BlueDragon.NET it could be argued that the simplicity of CFML can coexist in the .NET world without relying on chunky SOAP requests. -
Thom, I am not a proponent of that, I don’t think that it will help CF or Flex. I am more interested in tighter integration, and better leveraging of complimentary technologies, than I am simple bundling.
Hans and Steve, those are very valid concerns, and I am not sure that we (or anyone for that matter) have a real response. MS is still king of the desktop. -
My company has a fairly large CF base and I have really been impressed with the power and flexibility of CFMX and Flash Remoting. BUT, my company is now migrating to ASP.NET and I had thought that with web services and/or remoting I could take advantage of business logic/data access written in either and continue to use a Flash front end. I was very disappointed in the inability of either CFINVOKE or Flash MX 2004 Pro to easily consume a .NET web service that returns a dataset which is the standard way .NET passes query record sets. It just doesn’t parse the dataset into a query object as you would expect.
On the other side in ASP.NET, when trying to consume a CF webservice that returns a query, ASP.NET sees it as a QueryBean, which it doesn’t know what to do with. I was finally able to write code to extract the info, but it required knowledge of what was in the query that not available in the wsdl.
Interoperablilty is still much more painful than the hype about webservices leads you to expect. -
Kathy, I agree. When one vendor (Microsoft, in this case) "extends" the spec it creates problems for all.
-
I have my own sites in CF and I am earning money with CF (with almost all this sites on the top by Google and Yahoo).
A year ago I started with .NET (C#).
(www.jamaica-accommodation.com… and so on: it was nothing!!!!)
Google just doesn’t want to read !IsPostback by .NET ….
For me this is the most important reason to stick by CF.
Greets from Zagreb (Croatia) -
My CIO handed out a chart yesterday showing usage stats for servers running CF, Java and .NET. It was produced by NetCraft.
It showed CF going from 70,000-80,000 from January ’03 to March ’04. It showed .NET going from 12,000 to 55,000 in the same period. That’s quite a jump. I don’t know what their methodology was, or how accurate the results are.
Just throwin’ that out there.
[Java went from 32,000 to 55,000 in the same period.] -
Kathy & Ben,
Microsoft hasn’t extended any web service specification. The reason you’re not able to consume the web service is due to the fact that it is returning a DataSet, NOT a best practice.
Here’s why: System.Data.DataSet is a .NET-specific construct and the J2EE engine on the CF side doesn’t know how to deserialize it. This is completely understandable – for the same reason a .NET client won’t be able to consume a J2EE web service that returns a java.utils.Vector, because it’s a java-specific construct.
One of the top "don’ts" when designing interoperable web services (not matter what platform you’re on) is to NOT use platform-specific constructs. Use a custom type (class or struct). Each web service engine will build the contract (WSDL) correctly and each will be able to consume the service.
Happy coding!
Leave a Reply