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)

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. "

What I meant to say was that CGI "applications" tended to be too drab.

Conceded, especially considering the time of writing. Webdesign has moved quite a bit beyond what was common then.

Makeshifts last the longest.

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