|
in reply to Ignorant Article
I strongly disagree. The article is not a result of ignorance. Rather, the article is the result of the author feeling the pains of CGI. Think about it -- CGI truly *IS* an inefficient interface, especially for web applications that require frequent interactions with the server. The only people that are not forced to recognize this on daily basis, are the people that have only played with 20 lines CGI scripts. Everybody else knows that CGI provides a convenient entry point to dynamic web content, but it stops there.
This site (http://perlmonks.org/) uses mod_perl. Why? Because using CGI would not work. The site would crawl about 20X slower than it does now.
I suggest that people retain an open mind when reading criticism of technologies. It is entirely possible that the person writing the criticism has experience or knowledge beyond what you have.
The advent of FastCGI, ASP, PHP, mod_perl, ... is a DIRECT result of CGI sucking. |
Re^2: Ignorant Article
by Aristotle (Chancellor) on Feb 19, 2003 at 07:17 UTC
|
| [reply] |
|
|
If I were to apply your criteria when considering whether any article is 'ignorant', I would probably find that a lot of articles you write are 'ignorant'. Finding two or three conclusions that you can argue against does not force the entire article to be 'ignorant'. Mistaken, perhaps, but don't you think this whole thread is a little bit harsh?
The CGI interface deserves criticism. The real benefit of CGI is quick-and-dirty hacking, it is not the ability to design an efficient web application (although, on another topic... the idea of an efficient web application may be a contradiction in and of itself).
CGI is simpler, in that some people find writing 20 print statements to be easier to understand than a loop construct. Heck, when cutting and pasting to hack together a script, 20 print statements over a loop construct is actually *common*.
Don't get me wrong -- I'm not saying that CGI has no use. Just that for any application that is designed to be used by more than 2 or 3 people, CGI falls short in a number of categories.
If you want to attack the specific points, yes, the 'CGI tends to produce ugly output' stab is probably better worded 'CGI authors tend to get lazy, and therefore the aesthetic value of the application suffers.' For maintaining state? Consider that for a CGI written in Perl, modules must be loaded in order to store and fetch state information *EVERY SINGLE INVOCATION*. mod_perl solves this problem by keeping modules, and even some data, in memory. mod_perl is not CGI. mod_perl is necessary because CGI is defficient.
CGI should be used for proof of concept, or for cheap hacks. For a real interactive web application, CGI is always the defficient choice. The users *can* notice the difference. Think about it... how slow is perlmonks.org, and how slow would it be if it was written using CGI?
The only times I would prefer CGI over mod_perl or PHP, or some such alternative, would be for one shot scripts that do complicated queries, where it is not expected that the script would be invoked later by the same user, or when I am too lazy, or time pressed to get it to work under mod_perl. Some consider lazy or time pressed to be qualities, so I know that some will disagree with me. I only consider laziness an attribute when the quality or efficiency of my resulting code does not suffer. (i.e. lazy enough to prefer not to re-implement the wheel over and over)
| [reply] |
|
|
Yes, yes, yes. I earlier said that I agreed that the argument about ugliness was not really very strong. But at the time, I was comparing a web application using CGI and HTML to client server apps using VB.
But you are right that this was not communicated in the article as well as it could have been. What I meant to say was that CGI "applications" tended to be too drab.
As for the right tool for the right job, I would like to quote the conclusion to the "full" article that I have provided links to below...
"As any good technician knows, there is no such thing as a "best" tool. The best tool is dependent on a whole host of factors from the type of task at hand to the personality of the marketing director. The best tool is a fantasy.
Instead, every web developer should have at her disposal a wide array of tools to solve problems. Sometimes a server-side solution will be appropriate, other times a client-side solution will be best. Your main goal as a web developer is to develop an intuition about when to use which. "
| [reply] |
|
|
| [reply] |
|
|
Hmmm, I always thought that mod_perl made use of CGI as well.
Note that CGI does not mean "one request to
server - one new process". CGI is a (simple) protocol between
the server and the application. It defines how information
flows from the server to the application (mostly by environment
variables, and STDIN), and from the application to the
server (STDOUT/STDERR).
It doesn't mandate the technology. The server might use a
seperate process, but it might use threads or something else.
The problems discussed in this thread are mostly stemming from
the fact HTTP is *stateless*, and people try to use it get
state (sessions).
Abigail
| [reply] |
|
|
