CGI routines are by far the most used way for a webmaster to transfer data between his web pages and his web server. This is because CGI is one of the oldest methods, as well as being the “lowest common denominator” in many ways. CGI is used primarily on Apache web servers, although Windows NT supports a CGI interface (albeit poorly).
Some of the drawbacks for using CGI are listed briefly below.
CGI can be very slow. This is especially true of routines written in interpreted languages such as PERL. While PERL scripts are very simple to write, they must be recompiled each time they are run.
CGI is hard on server performance. This is because an additional process is started up for each and every invocation of a CGI routine. This uses memory and other resources on the server machine, which can cause slow response time.
Improperly coded CGI can cause security risks. If a CGI routine is not properly coded, it can place the web site or even the entire host machine in danger. Since you can execute shell commands from CGI routines, theoretically a CGI routine can wreck havoc if error conditions are not checked for.
CGI has a difficult time maintaining state. Since each invocation of a CGI routine results in a new process, it is difficult for context to be maintained between invocations. This means a call to a CGI routine cannot easily pass information to another call to a CGI routine.
Functionality is limited. Due to the nature of CGI (how it is called, how data is passed and what is allowed), the actions that can be performed are severely limited. CGI is useful for sending information to a server and getting back an HTML page. It has other uses, but PHP, ASP and similar server-side technologies are much more powerful.
Some languages require an interpreter to be installed on the server. PERL and similar scripting languages require that the language be installed on the server before they can be used. This makes the CGI routine a bit less portable than it could be.
Languages such as PERL can be configured differently. Different system administrators have different requirements, and PERL (for example) has many options. Sometimes PERL is defined with all options, sometimes just a few. This makes the scripts less portable than otherwise.
Debugging can be difficult. PERL, for example, can be very difficult to debug. What CGI programmer is not familiar with the infamous 500 error. This means there is some kind of problem with the script. Good luck on figuring it out.
The amount of data that can be passed to a CGI routine is limited. An ASP or PHP script can get have access to just about everything on a web page, while CGI is strictly limited to the parameters that can be passed in a URL (if the GET method is used).