ColdFusion vs. ASP.NET

So this week I had an experience with ColdFusion and ASP.NET that reminded me of why I love ColdFusion. I'm currently working on a project which has a pretty aggressive time line, the goal of which is to migrate some legacy data into a new ColdFusion system. The system has some fairly complex business logic so we decided that the quickest way to get the job done was to write an routine which submits data to the new system as a user would entering data into the application's forms. That way we wouldn't have to reverse engineer any business logic and incorporate it into SQL migration scripts. We also decided to try to leverage some of our .NET resources to help with this task.

[More]

Comments
Phil Duba's Gravatar Good post on a quick comparison. It always amazes me how much extra the other web languages make you put in.
# Posted By Phil Duba | 8/24/07 6:29 PM
Peter Bell's Gravatar It's why CF is such a good glue languag. Unfortunately the "quick wins" like cfquery, cfoutput, cfhttp, cfmail, cfftp and the like become less relevant as you build bigger apps. How hard would it be to write a simple class in Java or .NET to abstract all the nastiness and allow you to use a much simpler method call to get most of the benefits of the tags that cf provides? I now have a pretty rich OO framework in CF and I almost never use the "productive" cf tags as they're wrapped in a base DAO, a notification service, an http manager, etc. so replicating that in another language would mainly be a matter of writing longer methods to implement the API.

That said, dynamic typing and mixins provide a lot of speed and flexibility, some of the tags would be a royal pain to replicate, and the templating language is great, so I still love CF, but I have found that the reasons love it depend on the scope of the project I'm undertaking.
# Posted By Peter Bell | 8/25/07 12:18 PM
Sam Farmer's Gravatar Interesting comparison...and always good to see CF need less lines of code!
# Posted By Sam Farmer | 8/26/07 8:51 AM
Dave Konopka's Gravatar I'm a .Net convert to CF too -- and shudder every time I look around at the amount of effort it takes to write ASP.Net code.

And it's not just the amount of code involved with simple tasks. It's the complexity of composing it. The idea of putting togther a new site in Visual Studio versus notepad, textmate, or Eclipse makes my head hurt.
# Posted By Dave Konopka | 9/7/07 3:40 PM
Me's Gravatar You need to get a book on .NET you do not know what you are talking about. Your code for .NET really shows you have no idea of how to develop in .NET.

There are drop on the page features of .NET 2.0 that allow login with NO CODING. Also, if you chose to code yourself calling stored procs to validate the user.

Keep your Cold-Confusion.
# Posted By Me | 9/13/07 1:06 PM
LOL @ This Article's Gravatar I agree with the last comment. You need to learn some ASP.NET before you write articles like this. I looked at your code and eliminated 10 lines, and could probably eliminate 10 more, before I just started laughing and decided my time would be better spent encouraging people NOT to use this article as a good comparison. Ignorance must be bliss. All of you CF fans certainly seem to revel in it.
# Posted By LOL @ This Article | 11/19/07 9:11 PM
Nathan Mische's Gravatar I've been ignoring these last two comments, but today someone asked me about them so I thought I'd go ahead and post a response. I guess these types of comments should be expected given the somewhat confrontational title of this post. Anyway...

@ Me, I don't think you understand what this code is doing; it is logging into a _remote_ site for which I have no control over the database. Think of it as writing a web page with logs into Amazon.com and then displays the cookies set by Amazon on login. (And for the record, I don't claim to be a .NET developer, however I have read a couple of .NET books.)

@ LOL @ This Article, Lines of code are not always an indicator of complexity. For example, in the .NET code above I use a String array to hold the login parameters. For this small example it may seem to needlessly add lines of code, after all you could just use one string variable and be done with it. However, as the number of parameters (form fields) increases, using a String array actually makes the code much more readable. This, to me at least, is a matter of style and has nothing to do with the complexity of the code. In the .NET example you still have to create several different lower level objects and deal with them, something that you don't have to worry about in ColdFusion.

That said, this post wasn't meant to bash ASP.NET or C#, but rather highlight some of the differences I've found in coding .NET and ColdFusion. I'm still learning C# and .NET, and ColdFusion for that matter, so if there is a better way to accomplish what I'm trying to do I'd love to see it.
# Posted By Nathan Mische | 12/13/07 5:24 PM
Vivek's Gravatar Hi,

I use both ASP .Net and Coldfusion at my workplace. While your article may highlight that .Net is more complex to develop, it is important to remember that both languages have their strengths and weaknesses.

If your product has a few 100 pages with multiple form submits from different parts of the web page, the .Net concept of separating the server-side code into the code-behind makes .Net code an easier read for the next fellow who needs to enhance the page. CF makes life a little more difficult since everything lumped together.

From a business POV, I like to separate business logic from presentation, and .Net allows me to do that in the form of DLLs. My business logic is safe from unauthorized access and changes are much simpler to deploy. My ASP .Net pages contain only presentation-related code, thus making things easier to track.

CF, on the other hand, provides some brilliant tags like CFDocument, CFChart, CFFlush etc. that make life much easier. You either need to build your custom components in .Net for charting or buy/borrow third-party components.

So, in summary, both CF and .Net have their own strengths. I prefer .Net since I find it cleaner to develop and maintain. Its really a matter of preference. Performance-wise, things are pretty much the same.
# Posted By Vivek | 1/30/08 5:09 AM
Jaydee777's Gravatar I agree with Vivek, Both Language have their Strengths and weaknesses. There are stuff you can do in .net without even writing a line of code. What I don't like is comment like oh CF i better ...oh ASP.net sucks et...I mean does Adobe pay you to endorse their prod or what? it does not matter what you use. I don't think you can even compare both technology. People who follow some companies or prod from a company (apple, microsoft google etc) in a religious way always amaze me and make me wonder about this world we are living in! Anyway if you are good at CF and happy with it USE it, if you are better and more comfortable with ASP.net then USE it because at the end of the day when the job is done and it works ...it does not matter
# Posted By Jaydee777 | 2/22/08 2:15 PM
Chad's Gravatar Ok....

I ranted for about 30 minutes and decided to start with somthing different...

I'm coming from CF to .NET.
No object oriented trainng at all.

Key Concepts for now to master:

<cfincludes %headerPath%>
<cfincludes %footerPath%>

With <cfquery> to build Global Nav, SubGlobalNav, from header.

Need to quickly change to asp.net (preferably 3.5 in VS 2008)

I have or can have the tools to make it happen, (servers, ms sql2005, vs 2008)

Anyone converted from CF Web Dev to .NET that can offer any help?
# Posted By Chad | 4/6/08 1:52 PM
# Posted By aeixx | 5/1/08 4:42 AM
Kevin's Gravatar I won't get into the deep discussion on CF versus .NET as I use both and feel they both have their strengths and weaknesses as previously posted. If you know CF, you know it can implement MVC or other design patterns that separate business logic from design as you can use CF Components to be your business logic layer or simply CF Include statements to bring in code as if using Code Behind pages. It is a preference thing. There are some things I absolutely hate generated code on, but as it is improved as the VS IDE improves I find I use/like it more and more over time.

Anyway, I joined in the discussion to answer the question on CF to .NET.

As a simply answer, you can do the following CF:

<cfincludes %headerPath%>
<cfincludes %footerPath%>

By using custom user controls:

<mycontrols:header/>
Content
<mycontrols:footer/>

A new elegant way to do this though is to create a .Master page that has your entire layout (header and footer) wrapping one or more <asp:ContentPlaceHolder ID="Main" runat="server" /> tag(s). In your individual pages you simply reference the master page and provide content.

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" MasterPageFile="~/MyLayout.master" %>

<asp:Content ID="Content1" ContentPlaceHolderID="Main" Runat="Server">
Content here
</asp:Content>

Hope that helps.
# Posted By Kevin | 5/21/08 8:37 AM
Vivek's Gravatar Very good examples from Kevin. As I mentioned earlier (I think), I work with both CF and several aspects of .Net (ASP .Net included) everyday. My company's product is written entirely in CF.

Unfortunately, we have not had the best experience with CFC. We tried it on a moderately complex function that calculates rosters and appointments, but it ended up crashing quite frequently. We had about 10 or so users hitting that particular function at a time, so it was a bit of a let-down. Anyway, that was with CF6. Its probably more robust with CF7 and 8. CFINCLUDE has its own performance issues. Overusing that in a CFM causes major performance issues since each CFINCLUDE results in a disk I/O and the re-write of the page markup for execution (CF is more an Interpreter after all).

One of the things I absolutely love about CF8 is the cfobject tag that allows me to use .Net DLLs on the server-side for caching etc. As you would know, HttpRuntime.Cache is a very robust caching mechanism. That's damn cool! The so-called fixes on CFDocument have been a major let-down. Anyways, as I mentioned earlier, its not about which language can do what.

In terms of features, ASP .Net and CF could probably go head to head. It boils down to usage and performance, and how the programmer's wired up - as someone who comes from the mystical world of inline scripting or from the VB world of event-based designs. I work with both kind of nutters and I can tell ya, its damn fun watching people arguing over the better paradigm.
# Posted By Vivek | 5/21/08 10:55 AM
rich's Gravatar Yeah, the <cfhttp> and <Cfloop> tag provide declarative contexts for the input parameters and cookie output, respectively. You could actually achieve much the same effect with .NET...

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Net" %>
<%@ Import Namespace="System.IO" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitiona...;

<script runat="server">

protected void Page_Load(object sender, EventArgs e)
{
String loginURL = "http://www.somesite.com/login.cfm";;
StringBuilder sb = new StringBuilder();

//A simple loop will format the web form parameters for the HTTP Request
foreach (Object cntrl in form1.Controls)
{
HiddenField hf = cntrl as HiddenField;
if (hf != null)
{
if (sb.Length > 0) sb.Append('&');
sb.Append(String.Format("{0}={1}", hf.ID, hf.Value));
}
}
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(loginURL);
request.Method = "POST";
request.ContentType = "application/x-www-form-urlencoded";
request.ContentLength = sb.Length;
request.CookieContainer = new CookieContainer();
System.IO.StreamWriter swriter = new System.IO.StreamWriter(request.GetRequestStream(), new ASCIIEncoding());
swriter.Write(sb.ToString());
swriter.Flush();
swriter.Dispose();

//Since the Cookies Collection implements IEnumerable, we can use it
//with Data-bound controls, such as a repeater
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
rpt1.DataSource = response.Cookies;
rpt1.DataBind();
}

</script>

<html xmlns="http://www.w3.org/1999/xhtml">;
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" method="post" runat="server">
<asp:HiddenField runat="server" id="userName" value="someUserName" />
<asp:HiddenField runat="server" id="password" value="somePassword" />
<asp:Repeater ID="rpt1" runat="server">
<HeaderTemplate>Cookies!!<br /></HeaderTemplate>
<ItemTemplate>Name:<%# Eval("Name") %> Value:<%# Eval("Value") %><br /></ItemTemplate>
</asp:Repeater>
</form>
</body>
</html>

It's still true that the above example is overly-complex. That's not because of anything you can see in this code. It's because virtually any ASP.NET page is derived from System.Web.UI.Page. The Page class provides support for things like ViewState and Postbacks and executes a rather elaborate Control Execution Lifecycle on each round-trip. This is where the page content is loaded in to the page object model, any cached and postback events are raised and handled and the page is then rendered back to the browser. While the page content is very small in this case, there's still a lot of stuff going on that we're not taking advantage of. We can skinny this down significantly by implementing IHTTPRequestHandler, rather than derving from Page...

<%@ WebHandler Language="C#" Class="CookieFetcher" %>

using System;
using System.Web;
using System.Collections.Specialized;
using System.Text;
using System.Net;

public class CookieFetcher : IHttpHandler {

public void ProcessRequest (HttpContext context)
{
String loginURL = "http://www.somesite.com/login.cfm";;
NameValueCollection nvColl = new NameValueCollection();
nvColl.Add("userName", "someUserName");
nvColl.Add("password", "somePassword");
StringBuilder sb = new StringBuilder(100 * nvColl.Count);
foreach (String key in nvColl.Keys)
{
if (sb.Length > 0) sb.Append('&');
sb.Append(String.Format("{0}={1}", key, nvColl[key]));
}

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(loginURL);
request.Method = "POST";
request.ContentType = "application/x-www-form-urlencoded";
request.ContentLength = sb.Length;
request.CookieContainer = new CookieContainer();
System.IO.StreamWriter swriter = new System.IO.StreamWriter(request.GetRequestStream(), new ASCIIEncoding());
swriter.Write(sb.ToString());
swriter.Flush();
swriter.Dispose();

//At this point, we can do whatever we need to do with the Cookies.
//For now, just write them out to the local Response object
HttpResponse response = context.Response;
HttpWebResponse webResponse = (HttpWebResponse)request.GetResponse();
foreach (Cookie cook in webResponse.Cookies)
{
response.Write(cook.Name + " --> " + cook.Value + "<br/>");
}
}

public bool IsReusable {
get {
return false;
}
}
}

Admittedly, in the second example, we've lost the elegance of a declarative form for holding the username and password parameters. But the Name Value Collection could be populated from a NameValue Section in the Configuration File. This would be an easy enhancement to make, if the ability to dynamically change the names, values, and number of the parameters to be included in the request content were required.

But if we're really looking for simplicity, why deal with a web application at all? If the issue at hand is to do nothing more or nothing less than the original code sample, we don't even need a web server, a virtual directory, or
anything more than a plain, old stand alone Windows process...

using System;
using System.Web;
using System.Text;
using System.Net;
using System.Configuration;

namespace ConsoleApplication1
{
class Class1
{
static void Main(String[] args)
{
if (args.Length != 3) throw new ApplicationException("URL, UserID, and Password parameters are Required");

String content = "UserName=" + args[1] + "&password=" + args[2];
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(args[0]);
request.Method = "POST";
request.ContentType = "application/x-www-form-urlencoded";
request.ContentLength = content.Length;
request.CookieContainer = new CookieContainer();
System.IO.StreamWriter swriter = new System.IO.StreamWriter(request.GetRequestStream(), new ASCIIEncoding());
swriter.Write(content);
swriter.Flush();
swriter.Dispose();

HttpWebResponse webResponse = (HttpWebResponse)request.GetResponse();
foreach (Cookie cook in webResponse.Cookies)
{
Console.WriteLine("{0}\t{1}",cook.Name,cook.Value);
}
}
}
}

The same enhancement of using a NameValueHandler in the configuration file is an option here, too.

You can't get much simpler than that! Plus, you get to look at those cookies in that sexy, DOS-style black-and-white console window. And you'll never do this with ColdFusion!
# Posted By rich | 6/18/08 11:34 AM
santosh kumar's Gravatar thnaks,
this is a very good article. this is helpfull for me.


santosh kumar
http://www.operativesystems.com
# Posted By santosh kumar | 8/25/08 8:00 AM
ike's Gravatar vivek says: [CFINCLUDE has its own performance issues. Overusing that in a CFM causes major performance issues since each CFINCLUDE results in a disk I/O and the re-write of the page markup for execution (CF is more an Interpreter after all).]

This is not actually true. A cfinclude results in a rewrite of the java class file for the singular include if the included file has changed *and* the server's cache settings haven't been configured to assume that files haven't changed. Or if you've configured the server to not cache class files, which you only do on a development server. So under most circumstances, cfinclude only results in a test of the file's last modified time. There were some unusual performance issues with cfinclude in CF 6 and possibly 6.1, though as far as I know those issues have been eliminated in 7 and 8.

I can't say if this is unusually complicated ASP.NET code. I do know that I worked with classic ASP during 9-5 for a year back in '99 and what were being promoted as the most advanced ASP techniques at the time involved complicated syntax and created unnecessary file I/O in comparison to what was available with ColdFusion. There was a time when a select-case statement around a series of SSIs for the header and footer were the ASP world's most vaunted techniques, and that meant if you had 4-5 potential headers / footers (which was common), the template would include all 4-5 of them, and then only use 1.

Technologies do change and I'm sure ASP.NET and C# have improved quite a bit on what was available then. That does not mean however that all programming is "just preference". My last boss liked to say that a lot, "it's all just preference". No comapred to <cfinclude template="#pageheader#" />, the select-case around a series of SSIs was *objectively* inferior in every way - performance, maintenance, legibility. Although the observation that CFCs didn't work very well for company X is also not an objective analysis of the merits of CFCs.

The reason why I stick with ColdFusion (and I will say that when I use my own framework it often rather closely resembles the code-behind technique), is because when I do a Google search to find a code sample for something in ASP or C# or VB or any of the other MS/.NET technologies, the code samples are invariably very verbose and complex. When I Google search to find a code sample for the same thing in ColdFusion, the samples are usually concise and simple (though there are exceptions).

Check out Brian Foote's comments about the "gentle learning curve". http://www.laputan.org/selfish/selfish.html#Gentle... (note he's not a CF guy), which I think is really getting at the guts of what Nathan was talking about.

I was asked this past week to write an article for the Fusion Authority Quarterly (FAQU) about ORM tools and made some similar analogies in the article. One of them was a comparison of the code samples that show up on a Google search for C# or ASP.NET versus the code samples that show up on a Google search for ColdFusion when all you want to know is how to get data out of a table in your database. Yes ASP and all the other MS technologies work. I'm just not convinced that they need the steep learning curve they have, or that having such a steep learning curve has any advantages. And I feel the same way about Java, which I use much more frequently than any of the MS technologies.

Performance issues will change as well... and are always, constantly changing underneath us. The Java world is host to a wide variety of "best practices" for performance that have become liabilities on later versions. People who created DLLs used to optimize them by moving frequently used functions to the front of the file, until changes to the operating system made them perform far *worse* than the unoptimized files had performed on the previous OS version. It's wise in general not to focus too much time and attention on performance. A system obviously must perform well enough for people to use it, but if the users can tolerate its performance even if they're not giving it sterling reviews in that department, it makes more sense to wait and allow the progress of hardware to handle what performance issues remain than to devote large amounts of time to shaving fractions of a second from something that works. If you take the time to do that work, it becomes irrelevant much faster than doing work on the business model. The business model work may last a decade if you're lucky. The performance work will never last more than 2 at most.

But now I'm really rambling. :)

I do find it humorous that "Me" and "Lol" both felt the need to criticize yet also felt the need to do so anonymously and without providing any URLs to any pages or sites that might demonstrate their points. :)
# Posted By ike | 8/29/08 4:21 PM
Vivek's Gravatar That was an excellent post, Ike. I agree with most of your points when coming from the background of a CF/ASP developer.

In terms of the sharp learning curve, I have recently been involved in training up my Coldfusion team in ASP .Net. While it can be argued that the number of lines of code are more, it makes more sense to look at if you come from a C++/Java background, which is the case for most of the newbies from Universities and schools. Also note that many of the examples on the Internet (say in codeproject) are written without design in mind. They are meant for explanation's sake, so practically everything (logic, DAL etc.) is put in one file. MSDN has some pretty good articles on design.

One thing I absolutely love about ASP .Net is the robustness of webcontrols. I can create a templatized set of controls to enforce UI design and extend existing controls. I have recently extended practically every control used in a Web Application, including the GridView control and stress-tested some pretty hefty transactions. I have gotten some pretty good results.

Another thing is the global caching, which I have found to be extremely efficient. For instance, I could generate my Locale based on certain parameters programmatically and cache it, and then use the cache when loading each page to set the locale.

Technical and feature differences aside, one thing we have observed at our company is that ASP .Net is far more marketable than Coldfusion. We have had customers backing out because Coldfusion is just not an acceptable technology to them. Its not because of performance or anything technical. Unfortunately, CF is often associated with the age-old ASP era, which is absolutely untrue. CF is far superior to ASP in both the back-end architecture of the CF Server and the features. However, its plain fact that ASP .Net and J2EE dominate the market right now and are the only two technologies that customers are willing to acknowledge. In these circumstances, the company has to make the smart decision. Probably not a relevant statement in this forum, though :-).
# Posted By Vivek | 8/29/08 10:50 PM
ike's Gravatar Thanks Vivek. :)

Caching is one thing I've recently realized that I could improve on... my caching techniques which I always thought were fairly sophisticated didn't allow for the use of soft references for starters and then there are a host of other new things available like memcached or Railo's cluster scope. One of the projects I'm working on currently is a caching framework actually -- that can be dropped into other frameworks or applications as a service in such a way that it can actually be invisible to the rest of the application. I.e. the application may or may not actually be using the cache, but doesn't know or care beyond very simplified instructions about where the cache should live (i.e. cluster vs. server vs. application). Under the hood it will analyze the volume of data and select an appropriate strategy automatically (which may change throughout the course of a day) to eliminate the need for all the cache-tuning that's common with CF applications currently. The project is called CacheBox and it's up on RIAForge.org - though I've barely begun to put any code into it mostly because of being busy with other projects.

None of that speaks to the merits of ASP or its caching tools at all, I just figured I'd mention it since the subject of caching came up. It might encourage some other folks to get involved in the project. :)

I've never perceived the marketability of ColdFusion as a problem. It was marketable enough to generate business early on and it's always been marketable enough for all the companies where I've worked and all their clients. As a matter of fact, I've never worked for a company where clients turning their nose up at ColdFusion was ever a problem. I have heard lots of people make that claim, but I have no first-hand evidence of it. And I've worked for a good handful of companies... Moreover the popularity of ColdFusion in the marketplace has been gradually increasing with every version. It went up between 3 and 4. It went up between 4 and 5, between 5 and 6, between 6 and 7 and again between 7 and 8. According to market analysis like the Tiobe index anyway. It's not always been aggressively marketed, but it has continued to grow steadily.
# Posted By ike | 8/30/08 1:11 AM
Clay's Gravatar Greetings,

I was reading through your post and I had a question. I am attempting to consume a webservice that utilizes the .Net CookieContainer to maintain the session login. I am having difficulty figuring out how to do this in CF and thought that you might be onto something. Got any ideas?
# Posted By Clay | 12/12/08 6:14 PM
Nathan Mische's Gravatar The CookieContainer is just .NETs way of interacting with cookies. Your ColdFusion code does not need to know anything about that. You just need to make sure your webservice calls pass the appropriate cookie HTTP request headers.

The code above shows how you might read set-cookie headers sent to you from the webservice. See the article below for info on how you can send those cookies back on subsequent requests: http://tjordahl.blogspot.com/2006/06/how-to-set-co...

Hope that helps.
# Posted By Nathan Mische | 12/18/08 3:12 PM
Dean's Gravatar Clearly some knowdgeable folks on this discussion. Exactly what I need. I'm taking my first step into web development, armed with only what I think are strong skills in VB, SQL, C and VBA. Sadly, my background is primarily Microsoft based. I'll be building apps for 150 internal and external clients. Anyone care to make a recommendation as to whether a 100% rookie should choose ASP.NET, CF or alternate?
# Posted By Dean | 1/7/09 9:59 AM
ike's Gravatar @Dean - ColdFusion has always been lauded for its ability to get rookies up to speed quickly. There aren't a whole lot of languages where that's the case, and actually rather frequently people who prefer more complicated languages like Java claim that a language being easy to use is a "bad thing". In essence, here's my thought: the people making ColdFusion set "easy to use" as their goal -- the people making Java (and other languages) set "mechanically efficient and highly configurable" as their goal.

However -- with a background in VB, ASP.NET may be more familiar to you. So even though you're a rookie with regard to web applications, you may still find it easier to develop them with a language that's closer in syntax to the ones you already know. It's hard to say. I'd probably designate a day to spend playing with each and see which you think has a better learning curve for you personally.
# Posted By ike | 1/7/09 9:21 PM
Dean's Gravatar Thanks for your response Ike. And that's a good point; perhaps something is sacrificed in order to focus on "easy to use". One might expect less functionality at the high end.
# Posted By Dean | 1/13/09 11:45 AM
ike's Gravatar I've heard people make the comment that ColdFusion might give you "less control" over things than other languages... I was reading one the other day where a guy was making that comment about using cfquery versus using Java/JDBC and controlling all the connection pooling, etc. directly within your application. With cfquery the connection pooling is all controlled by the server (though you have some options for configuration in the admin), so he sees cfquery as offering less control. In practice I've never seen a scenario in which such a lack of control caused a problem, either with database access or with other things.
# Posted By ike | 1/13/09 12:01 PM
Sebastian VanDyke's Gravatar I have twin brother that is a ASP.NET programmer. He's been trying to get me to go to the dark side for years now. Once you know CF, it's so hard to justify learning ASP but the bottom line is there's more opportunities for ASP.NET than for CF.

Also, less isn't always more. When it comes to enterprise applications, CF can handicap you in a lot of ways.
# Posted By Sebastian VanDyke | 4/6/09 1:26 PM
ike's Gravatar @Sebastian - I've heard lots of people make that claim, but the problem with me believing it is that the statement "When it comes to enterprise applications, CF can handicap you in a lot of ways", is unsubstantiated. It shouldn't be believed unless a person can provide evidence. The same principal applies in reverse. If I simply said "ASP.NET handicaps you in a lot of ways", would you believe it? Or would you demand proof? Like most folks, you didn't provide any evidence. What are examples of ways in which CF handicaps an enterprise effort? I've yet to see any that held up to any real scrutiny.
# Posted By ike | 4/6/09 4:15 PM
Nano's Gravatar @Ike - Sounds to me that you are about to start a CF religion. lol

I recently started to use ColdFusion because a client requested it for there web app. Something about being easier for them to maintane it since the developers there only know Coldfusion.
nativly i am a ASP.NET developer and found it somtimes @ first to use CF. But after a while i got used to it. I have to say that I prefer ASP.NET with all its goodies. .Net provides me with
a rich set of controls and the possiblity to use thirdparty controls (Coolite ext JS..damn awesome). It also gives me the possibilty to make custom control libraries and presist them into a
reusable dll. What .Net gives me that CF doesn't is control. I have a clear overview of my markup code, c# code and all my layers. I can easely locate problems and it's all more logicaly
structured.
# Posted By Nano | 4/23/09 3:20 PM
Chuck's Gravatar I have a .Net background and just recently started working with CF, and as a developer one of the big advantages I see to using .Net is the IDE. Maybe I'm just spoiled from having the intellisence but it definitely helped having all my class and method signatures right at my fingertips rather then having to flip back and forth to another page to the view the cf method signature. CF has come a decent way with Adobe's new plug-in for Eclipse, it offers a little more with intellisence and syntax checking for prior versions, but no where near what Visual Studio offers.
# Posted By Chuck | 8/4/09 2:10 PM
unknown's Gravatar You people braking my head! Looking for an answer on my question what to study coldfusion or asp.net i finaly lost myself. :-)
# Posted By unknown | 4/14/10 1:30 AM
Budi's Gravatar You guys compare 2 different things, ColdFusion is a commercial rapid application development platform (http://en.wikipedia.org/wiki/ColdFusion) and ASP.Net/C# is strongly typed, object oriented and event based (http://msdn.microsoft.com/en-us/library/aa479305.a...).
It's like SUV cars and minivan cars, Rav4 and Odyssey, they have different purposes. Of course, both can move from point A to point B.

They are different even tho you can create a login page with ColdFusion or ASP.Net but it's depend on your needs or company needs
# Posted By Budi | 7/30/10 10:04 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.