Well, this question is very interesting. I have been wondering what to reply to my Chief Development Officer, who is using Servlets where I would use CGI (with mod_perl of course).
So, I just did some fetching with google, and with 3 links that I found I could summarize the following:
This view of the situation is of course discutable, because I have heard that mod_perl was very reliable and very fast also. And extremely just argued that CGI is not bad for security either.
- Servlets are more secure because they are in Java and Java is inherently more secure (like any applet).
- Servlets handle multi-user sessions better because of their multi-threading capabilities.
- Servlets are (supposed to be) faster than CGI for dynamic content because they run in the same space as the server itself.
- Servlets are more portable.
This is basically the only reason, according to this article, of keeping your CGI scripts... Well, I am wondering if that webmaster (the author) was not born in a Java and is not going to drawn in a Java also :-)
- Java 1.1 specifications and the JavaServer and Java Servlet API are a hassle to learn.
This is all for that one, it is just a slide presenting the advantages of the Servlets... It's funny how people talk about security "just because it's Java". The author of that slide is apparently trying to convince us to see the world in Java, and this is probably a wrong idea. Besides the fact that using threads can be an advantage, all the other points have no real impact on Perl/CGI, IMHO.
- Servlets have iterative communication
- Servlets are more secure
- Servlets can run in the background
- Servlets can use threads for concurrent requests
- Servlets have all the other advantages of Java (Extensible, OO, etc.)
The first point is quite fun. With mod_perl, I don't think so. And everybody knows how slow a JVM can be, even with JIT. The third point, about development, might be true, but I have never really suffered of not developing Perl scripts in Visual Studio... About debugging, if the author would know about CGI::Carp and FatalToBrowser, maybe that he would not argue he prefers Java exceptions!
- Servlets do not require loading an interpreter (the Perl interpreter is 500kb in size), compile the code and run it.
- Servlets are more secure because they are in Java and because they are compiled, unlike Perl scripts (See the WWW Security FAQ's section on CGI scripts)
- Servlets development is easier, because there are better IDEs, from Sun, Symantec, Microsoft and because Java application development scales better for large projects.
- Servlets debugging is easier.
Duh! Excuse me, I have a hard time understanding what this guy means. This is contradictory with the development advantage presented above!!! Then, the end of the article compares an "Hello World" servlet with an "Hello World" CGI script, and this is pretty funny: 3 lines in Perl, and about 25 for the Servlet :-) - I know why I stick with Perl!!!
- CGI development is faster.
Well, maybe that Google likes Servlets better... This "Comparative View of Servlets and CGI" starts with the title "Servlets are better" - which is very comparative...
- Servlets are less "resource intensive".
- Servlets are plaftform independent.
- Servlets + FastCGI is best
Hmmm, what can I say? We got mostly Servlets advantages there. I don't think that those article authors spent enough time considering the CGI advantages. For me, developing in Perl is going to be *always*
the fastest and most powerful way to develop a CGI application. It requires more attention, maybe, to make the code portable and reusable, but people who have never developped a full project in Perl cannot know how much power can be hidden is so few lines of Perl code... It's almost evil, and this is what makes it so good!
More seriously, I do think that the future is in the neurons of Larry and the Perl6 development crew. The "Camel Lot6" talk by Larry last week says it: we do not want to throw Java (and its exceptions:-) away, we want to have a getaway to it from within Perl!