Ok found a great artilce by John Paul Ashenfelter
http://www.webreview.com/2000/09_01/developers/09_01_00_1.shtml
that addresses this question:
What Makes ColdFusion Great
According to the market research, ColdFusion is the best-selling Web application
server. But to put that in perspective we need to look at the competition:
Microsoft ActiveServer Pages (ASP), Sun's Java Server Pages (JSP), Perl, PHP,
and similar products. One thing to notice is that all of these competing
technologies are basically free. So this puts CF in competition with the big
guns in the "best-selling" categoryOracle Application Server, Apple WebObjects,
Vingette, Sapphire, and so on. So again, it's no surprise that ColdFusion sells
better than tools costing tens of thousands of dollars. But underlying the hype
is a significant factor: Well over 100,000 people develop with ColdFusion (at
least according to its creators at Allaire). Cost or no cost, that's a huge
number. Why would all these people choose ColdFusion over other tools? There are
three core reasons.
Reason 1: Simplicity. One primary reason many developers choose ColdFusion is
because it is so easy to learn. Most developers with HTML skills find
ColdFusion's tag-based scripting language extremely intuitive. Here's an example
of a ColdFusion tag:
<CFSET x=5>
This tag, as I'm sure you can figure out, assigns the value 5 to the CF variable
x. Clearly a trivial example, so let's make things one notch more complicated:
<CFSET x=5> <CFOUTPUT> the variable's value is #x# </CFOUTPUT>
This time, the value is displayed after it is set. The CFOUTPUT tag "turns on"
output processing which looks for ColdFusion variables delimited with the pound
sign (#x#).
That's it! You've learned the basics of ColdFusion. Tags start with CF and
variables are delimited with pound signs.
Reason 2: Power. Despite the fact that ColdFusion is simple to learn, it is also
extremely powerful. There are over seventy tags in the ColdFusion language,
which is often referred to as CFML (ColdFusion Markup Language). Here's an
overview of the major services offered through CFML:
Programming constructs such as flow control and decision making Database
access, including stored procedures and transactions Network protocols,
including LDAP, POP3, SMTP, HTTP, and FTP Enterprise integration, including
COM, CORBA, and EJB Custom tags which can be written in CFML, C++, Java, or
Delphi Application framework for CF applications, including security
That's not even including the 400+ functions built into ColdFusion.
More importantly, the power does not come at an appreciably higher price. Once
you've learned the basics of ColdFusion, the main obstacle in implementing
anything more sophisticated is often your understanding of the service you're
accessing other than ColdFusion itself. For example, you can use the <CFLDAP>
tag to get LDAP directory information quite easily, but I'm guessing that you
might not know what to do with it once you've got it.
Reason 3: Community. One of the strongest reasons to choose ColdFusion is the
community of ColdFusion developers. The open source community is well-known for
producing communities of developer/activists that focus on a particular product
or tool. A similar group has coalesced around ColdFusion. From the extremely
active Developer Forums at the Allaire Web site to the active ColdFusion users
groups (CFUGs) around the world, there is always someone to help you with a
problem, offer you a solution, or create a tool to meet a need. The active
development community has led to literally hundreds of custom ColdFusion tags,
dozens of applications that run on top of ColdFusion, and a solid offering of
books and magazines.
ColdFusion vs. the Competition
"ColdFusion sounds like a great tool," you may be saying by now, "But why should
I choose it over some of the other tools?" This is an especially important
question, since there is so little time to spend on learning new tools and so
many technologies vying for your attention. To be as fair as possible, we should
see how ColdFusion compares with its closest competitors.
The most relevant competitors to ColdFusion in terms of popularity are ASP, PHP,
JSP, and Perl. I have built real-world projects using each of these tools, and
more importantly, have built the same two sample applications in all four tools
for the sole purpose of comparing them. To end your suspense, I find that JSP is
the only worthwhile competitor to ColdFusion (and that the difference between
them is slowly being bridged by Allaire, as discussed below). But in order to be
fair to the technologies involved, I will discuss each one in the following
sections.
Active Server Pages. ASP is one of, if not the most widely used Web application
development tools in terms of numbers of users. There must be some reason so
many people like it, right? There are a number of reasons to select ASP, but the
two most important are that it is free and bundled into Internet Information
Server (IIS) on Windows NT. This means that ISPs running shared NT hosting
servers can offer ASP to all clients on that machine at no additional charge. It
also means that NT-based projects are often built using ASP, since all the tools
are right there. Furthermore, it is a core Microsoft technology that is tightly
integrated into COM and DCOM. And there's even a pair of companies (ChiliSoft
and InstantASP) that make Unix-based ASP environments.
Since the default scripting langauge in ASP is VBScript Programming, it is not
too difficult, especially for VisualBasic programmers and VBA developers. To
make things even easier, ASP can also be scripted with Microsoft's version of
Javascript (JScript) or standard Javascript (and even in Perlscript or REXX if
you're really a masochist). There are only a few objects that make up the core
language architecture (Session, Application, Request, Response, and Server).
Also included with ASP is a solid set of COM database objects (Connection,
RecordSet, Query, and so on).
The biggest problem with ASP is that it is not a complete Web application
development platform by itself. Do you need to add FTP or HTTP services? LDAP?
CORBA? You're on your own. Of course you can build a COM object to handle that
particular service if you're a good C++ programmer. Or you can buy a third-party
COM tool that provides that service. But now you're spending money to add
required services to your "free" application platform, you've got multiple
vendors creating the COM objects, and you're relying on the vendor for solid
multithreading support if you plan to deploy on multiprocessor servers. You're
also spending more money if you want to run ASP on a Unix-based server, since
you have to buy the ASP environment for Unix from a third party. Not quite the
bargain it seemed at first glance.
PHP. PHP has developed an especially strong following in the open source
community, since both PHP and its preferred database (MySQL) are both now open
source tools. It is used by a number of technical Web sites, including Slashdot.
It can integrate with a wide array of databases, including some fairly esoteric
Unix-based databases. And it has all the advantages of an open source tool:
committed user base, ability to modify or extend the code, no licensing fees,
and ports to many operating systems.
Unfortunately, PHP has two crucial problems: performance and database
portability. The development team has done a remarkable job of improving the
performance over the past two releases, but it is still slow in comparison to
most of the other competing tools. More importantly, each database that PHP
supports requires a separate set of commands and offers a different array of
features, capabilities, and bugs. Migrating from MySQL to Oracle requires
changing every line of database code and probably changing some of the PHP
functions as well, depending on the features available in each database library.
That's not even considering inherent differences between the databases
themselves. PHP is fine, as long as you're going to run it with a single
database, particularly PHP/MySQL. But its hard to use if you're building systems
for a number of other people, or if you prototype in one database and deploy in
another.
Perl. The venerable grandparent of Web development tools, Perl still plays a
role, ranging from duct tape to application platform at a number of Web sites.
It has libraries for database connections and a wide range of other services
ranging from low-level socket connection capabilities to its outstanding text
processing capabilities. Furthermore, a large percentage of Web developers
already know Perl. Thus, from a number of perspectives it seems like a good
choice for application development.
The principle drawback to Perl is that it is not designed for Web page
generation. All of the other tools integrate into the HTML source code of a Web
page. Perl has to print out the Web page line by line. This is not impossible
(it's also how Java servlets work), but nowhere near as easy to build and
maintain as a script interspersed with HTML. Perl is also not really designed
for Web applications. It uses the lethargic CGI as a primary method of
communicating with the server. Of course there's mod_perl for Apache, FastCGI,
and a host of other tools that improve this aspect of Perl, but it is not
exactly what Perl was originally designed for, and it shows.
JSP. JSP is literally the Java equivalent of Active Server Pages. It has a very
similar set of objects (Request, Response, Application, and so on) and is
scripted using Java. It has an extremely low learning curve for Java
programmers. It also can easily be extended since any Java class can be
instantiated in the JSP code. This opens the entire gamut of Java capabilities
to the JSP developer.
The only real downside to JSP is that it is more challenging to learn than any
of the other tools. Not impossible, and not even a bad idea, but a significant
learning curve, especially for those without a strong programming background.
There are also a number of competing JSP engines on the market, which makes
choosing and administering server components a little more challenging.
ColdFusion and JSP have an interesting relationship, and it's only getting more
complex. Allaire now owns Live Software, which basically invented JSP and their
Java/JSP platform JRun. So in one sense, Allaire markets competing products in
their ColdFusion Server and JRun server. But in the next four to twelve months,
Allaire is migrating ColdFusion to a Java taglet library. In a nutshell, this
means that JSP and CF will be two different scripting languages and application
frameworks that run in the same environment. It won't make JSP as easy to learn
as CF, but it will give you the option to choose the right tool for the right
job.
Michael Smith wrote:
> CF is a good language because:
>
> easy to learn
> uses standards - SQL, HTML etc
> easy to read the code - ASP code is harder to read and spot typos I think
> easy to extend with custom tags
> full feature set - lists, structures, email, ldap etc
>
> and most important of all I think...
>
> it has a large friend communuity of people who will help you when you get stuck. The
>lists, CFUGs, conferences etc.
>
> There is nothing wrong with other languages - each can be good for certain projects.
>But for general web-database
> projects CF is the faster to code in.
>
> I think people worry too much. If you have clients who are happy with CF then do CF.
>If your clients want Java,
> PERL or ASP then do that. But don't start doubting yourself just 'cos some javahead
>is beating up on CF! This
> reminds me of the Visual Basic vs C debate - both are good languages depending on
>what you want to do. And both can
> write good or bad code in depending on the programmer!
>
> - Michael Smith, TeraTech, Inc http://www.teratech.com/
>
> Erika L Walker wrote:
>
> > Oh god....someone posted this to CF-Talk.....I know we probably all belong
> > to CF-Talk, so you saw it,...but now I am curious about any OT reasons
> > people may have, rants that they might not necessarily put over on CF-Talk.
> > (I for one am afraid of inciting any wars over there... <g> ... over here,
> > well, I get such a warm fuzzy feeling over here.....)
> >
> > I enjoy other languages myself. I'm not afraid of diving into Perl or ASP or
> > even Java....I just don't prefer it. Not when productivity is such an issue
> > and we are just a small company without the financial backing to have dozens
> > of programmers at our beck and call, on salary...sitting around waiting for
> > the projects to roll in.
> >
> > If a client needs us to do ASP or Perl or JSP or PHP, we'll find the right
> > resources to get the job done. But, if we have a choice, then I believe, as
> > most of us do, that CF is the right tool, and will be for some time,
> > providing, Macromedia does its job right and keeps it at the forefront.
> > Making people aware of its existance is key.
> >
> > It's posts like these from this guy that bring little fingers of doubt, out
> > from under the covers....wiggling and waggling...saying...."hmmmm...maybe he
> > has a point. Oh no. Should we change? Should we keep going?" Then I bring
> > out the big Sledgehammer, and BAM!BAM!BAM! Smash them to smithereens and go
> > about my merry way. Or is this just running away from a potential problem?
> >
> > What's everyone else's opinion?
> >
> > Erika
> >
> > "Friendship is never an accident. It is always the result of high
> > intentions, sincere effort, intelligent direction and skillful execution. It
> > represents the wise choice of many alternatives." - unknown
> >
> > -----Original Message-----
> > From: Joseph Grossberg [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, April 20, 2001 3:28 PM
> > To: CF-Talk
> > Subject: Is CF still relevant?
> >
> > Now, before you dismiss this as a troll, please let me elaborate. This isn't
> > so much an instigation or a whine as it is a call for us to take a step back
> > and reevalutate things periodically.
> >
> > Over the course of my career as a web programmer/developer, I have worked
> > with a variety of sever-side languages and technologies: ColdFusion, ASP,
> > JSP, PHP, Perl and Python. I like some more than others, but I'm not an
> > evangelist for any; they each have their uses. And I recognize some of CF's
> > strengths: easy to learn for people who know only tag-based HTML or don't
> > have significant programming experience; built-in admin tool; specialized
> > editor; comes with pre-built tags and web-based administrator. There are
> > also major flaws: broken/sketchy tags; no XML parsing; not OOP; relatively
> > small community; etc.
> >
> > Right now, I work at a web development firm that is primarily "a CF house"
> > (besides me). Our more senior programmers are looking at honing their CF
> > skills, while our less experienced webmasters are trying to learn
> > ColdFusion. But, I can't help but wonder whether they are wasting their
> > time. Would they be better off spending their time learning ASP, Java or
> > another non-CF solution? Why or why not?
> >
> > And how would we tell if and when it was time to give up CF and try
> > something else, as all but the most stubborn experts in also-ran languages
> > (Ada, SmallTalk), applications (Netscape, Lotus Notes) and Operating Systems
> > (Amiga) have resignedly done?
> >
> > Lastly, why do *you* still use CF? Is it because it's what you're best at,
> > and you don't want to try something new (where, temporarily, you'd be a
> > novice again)? Is it because your ccompany's legacy code is all in CF? Is it
> > because you genuinely think that ColdFusion is, generally speaking, the best
> > solution for web application development in 2001?
> >
> > Joe
> >
> >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
