On Tue, Feb 16, 1999 at 08:03:26PM -0500, Daniel W. Dulitz x108 wrote:
> 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
This is not really the point. The point is that for a heavily-loaded
server, even a small difference in performance can make a tremendous
difference in the system -- possibly the difference between running well and
not running at all.
> less than Perl development time? For substantial apps, we have always
> found that to be the case. Are Java servlets more maintainable over
I do not disagree that Java's strong typing is useful for large apps.
> time than Perl? I don't think that's even a serious question.
I do disagree that Java is more maintainable than Perl in general. If you
know Perl, it is quite easy to read and maintain. The regexp support makes
it far easier to code and maintain anything that parses things that are even
vaguely complex.
> 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.
I do not, and have never, reccommended PHP3 for anything "serious", for just
these issues, and others. But mod_perl and FastCGI are quite good for CGI.
> 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.
No, I've seen Java programs, and even a "serious" applet or two. The point
is that this is not an acceptable or useful paradigm in my opinion. The
fact that the language used is Java is really irrelevant.
If one really wants this sort of thing, embedded X may be a better solution,
but it has lots of problems, too. I don't think it's a good solution either
(except perhaps for corporate LANs.)
> 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
You're clouding the issue. The point is that HTML itself is not adequate in
the case you're describing. In fact, the whole Web idea is not adequate
here, and it was never designed to be.
I have never disagreed that a Java-based GUI application (note, not applet)
as a client would be good, and in fact, in the message to which you are
replying, you snipped the part where I said so.
> 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.
I wish people would stop comparing a current Java idea with an outdated CGI
one. If you want to compare it to CGI, please do us the favor and compare
it to current CGI ideas.
But you are comparing HTML to something that is not appropriate for HTML.
You're describing a whole application.
