Thread: Re: PHP or JSP? That is the question.

Re: PHP or JSP? That is the question.

From
"Bas Scheffers"
Date:
Cott,

You are right, for just a servlet engine, Orion doesn't add too much value
or be much faster than the free alternative, other then it being quite
nice to use. Most other benchmarks I have seen were for EJB performce,
something wasn't done for this test. In EJB use, Orion wipes the floor
with most competitors, especial the free one! (JBoss)

Guy,
I have no idea what you mean when you say: "With the java application
running at the client end providing the interface, and the java servlet
running at the server end doing the I/O, JSP can make a more fluid feeling
interface." How do you mean? A JSP page on the browser is as static as a
PHP one.

As for Tcl, ever since 8.0, it compiles the code into bytecode at runtime,
which does speed up the use of procedures, but it being a higher level
language than java and not as strictly typed, it is not as fast in all
cases. But for a web app in a fast enviroment like AOLserver, it is
unlikely you will see any performance difference, there are too many
factors influencing that and your actual code on the page is a tiny
fraction. (database access being the worst offender)

Laimis,
With regards to PHP having more libs out of the box and easy to use, you
are right. But Java 1.4 has built in regex as well, and a nice one too!
Most other APIs are available and all you usualy need to do is add the jar
to the classpath. You say: "I do like the idea to catch as many bugs as
possible at compile". I say: I use both methods and have to say it doesn't
matter much. In any case, in testing you have to always test every
possibilty wether you compile or not (NullPointerException, anyone?) and
quite often changing the code and hitting "refresh" in your browser is
quicker than recompile+deploy+server restart. And as for the much touted
"type safety" of Java: anything the user sends in via the browser is a
string, which you will have to convert to integers, booleans, etc. So
there goes most of that argument, the only data you have no control over
is likely to be the culprit in a mismatch!

So in my book neither enviroment is superior except in very special cases,
 and the one in question here doesn't seem to be one of those. The thing
that mostly influences performance and maintainability is the way you
write the code. In the case of Java, it forces you to be stricter, but
once you have coded yourself into a corner and realise it is the wrong
one, it is hard to get on track again. At least with PHP/AOLserver, you
have the option of referencing pretty much any variable from anywhere,
which, especialy for beginners, can be a real project saver at times! :)

Bas.

Re: PHP or JSP? That is the question.

From
Guy Fraser
Date:
This is an example of what I mean :

1) Fill out form to get data.
2) Server responds with java and set of records.
3) Java applet displays one of the records and with out further
intervention from the
server, tha java applet can be used to scroll back and forth through the
other records.

Because data from the set of records is now at the client side,
manipulation of the
data seems faster to the end user than retrieving each record one at a
time every
time they want to move back or forth through the search results. This
allows the
records to be nicely formatted and displayed one at a time rather than
as a table.

Bas Scheffers wrote:
...snip...

>Guy,
>I have no idea what you mean when you say: "With the java application
>running at the client end providing the interface, and the java servlet
>running at the server end doing the I/O, JSP can make a more fluid feeling
>interface." How do you mean? A JSP page on the browser is as static as a
>PHP one.
>
>As for Tcl, ever since 8.0, it compiles the code into bytecode at runtime,
>which does speed up the use of procedures, but it being a higher level
>language than java and not as strictly typed, it is not as fast in all
>cases. But for a web app in a fast enviroment like AOLserver, it is
>unlikely you will see any performance difference, there are too many
>factors influencing that and your actual code on the page is a tiny
>fraction. (database access being the worst offender)
>
>
>
...snip...

--
Guy Fraser