Kevin Hester writes:
> John Goerzen writes:
> > I would certainly not use Java for CGI. libapache-mod-perl, FastCGI, etc.
> > if necessary.
>
> I'd definitely encourage anyone to use servlets with wild abandon. So easy
> and clean - I haven't had to write CGI cruft in over a year. In exchange
> for servlets I have a logical/maintainable tree of server side classes.
I second that.
John, you wonder about the technical advantages of Java. Java is all
about balancing easy to write and easy to read code against runtime
performance. Think C versus assembly language. And the real question
is, "Is the runtime performance of Java adequate?" For all but the
tiniest web servers, the answer is yes. Is servlet development time
less than Perl development time? For substantial apps, we have always
found that to be the case. Are Java servlets more maintainable over
time than Perl? I don't think that's even a serious question.
Are you doing database work? PHP3 is a great tool for integrating
databases with the web, but try doing a sophisticated interactive user
interface with PHP3 -- it bogs down your server and produces really
abysmal client-side performance when compared to applet+servlet. And
the code is a nightmare to maintain.
For me, the clue is that you've only seen cute applets, not useful
ones. That's a big indication that you're not using real
client-server over the web. What do I mean by "real" client-server?
I mean the case where you have a "real" software system -- not the toy
programs we tend to think of when we think of the (consumer) web --
with a user interface, some non-database-related processing, and one
or more databases that the server talks with while doing that
processing.
If that's what your problem looks like (and that's what a lot of
enterprise software looks like), CGI is a joke. Sure, you can spend a
while getting your database interface to talk with your C++ server,
and you can spend ages getting your C++ server integrated with CGI --
and after all that, you end up writing a Java applet because it's the
only portable way to present an interactive GUI via a browser. So you
spend time interfacing your applet with CGI, debugging the whole mess,
and then it still runs slowly.
With servlets and applets, you write your applet, it communicates
directly with the servlet via RMI, the servlet communicates directly
with the database via JDBC, and you don't have any integration and
debug problems. And because the servler is threaded, initial
connection speeds blow away CGI.
Best,
daniel dulitz Peak Performance Real-Time DSP
State College, PA
