Forum Moderators: phranque
I have done some research on JSP and PHP. I found that:
1. JSP is more performant than PHP. Particularly people mension that PHP needs to be compiled into byte code every time a *.php page is invoked, while a *.jsp is compiled into a *.java and further to *.class file only once.
2. PHP is easier to learn (not a big issue for me because I have used Java for a long time)
3. More hosting services support PHP than JSP.
I have more question on number 3. I tried to use JSP server (Tomcat in particular) and PHP server on my own PC (Apache + php module), I have the impression that JSP application requires more server configuration than PHP application. (A lot of times I need to change server configuration and restart server for things such as defining data source).
I imagine that most ISP would use the same web server for multiple of their clients. So they would not let me touch the server configuration and start/stop server at random. Is this the case? Anyone have good/bad experience with JSP/PHP server hosting? Do ISPs allow you plug in optional modules or change server configurations?
Is it performance?
Is it dynamics?
Is it an economical solution?
Is it a SE friendly solution that will do well in the SE’s?
I think you need to evaluate your wishes and choose the technology after this. Each technology has its own pros and cons (as I’m sure you know)
JSP is THE most robust server side language short of writing C++ executables on the back end.
it's also the most complicated to master.
There's nothing "risky" about it.
If you want a simple site, stick with PhP. If you want to do some really intense processing, JSP is the way to go.
Particularly people mension that PHP needs to be compiled into byte code every time a *.php page is invoked, while a *.jsp is compiled into a *.java and further to *.class file only once.
This is true, but it's really not an issue, because PHP's compilation is extremely fast.
A while back, I was part of a team that developed a site using JSP, and then rewrote it in PHP. JSP turned out to be slower, and more difficult to manage. At first, there were some features of Java that I liked, but PHP has those features as well.
I can also say that of the other sites that I've used, JSP sites always feel much slower than PHP sites to me.
I do like the JSP, compile once scenario but there are ways round that in php. I am also most familiar with PHP so it makes sense to stay put for now.
ta,
Hughie
People who claim one technology is slower than the other just don't know the other technology well. And those that claim that one of them is harder to install just haven't done enough installations.
As for performance, the way you code will have a much greater effect than the technology you use. "Hello world" page will display fast enough in both cases; the rest is up to you.
You can get a VPS for as low as $20/mo these days. That way, you can install anything you want.
But I've never found PHP to be inflexible, and the combination of PHP and MySQL is, to me, very effective and elegant.
But I've never found PHP to be inflexible, and the combination of PHP and MySQL is, to me, very effective and elegant.
I just decided to do a split-run test for a shopping cart persistance: half of people got a cart that expired when they closed their browser, and the other half would get a long-term cookie. After that, I check conversion rate difference and average order total for both groups.
With JSP, all I had to do is add a few tags to the top of the cart page.
<%@ taglib uri="store" prefix="store" %>
<%@ taglib uri="sm2-ca" prefix="sm2-ca" %>
<sm2-ca:ContentAlternatorSeed keyIndex="K18" valueList="A,B"/><sm2-ca:ContentAlternatorMarker keyIndex="K18" valueList="A">
<store:PersistentShoppingCartTag/>
</sm2-ca:ContentAlternatorMarker>
<sm2-ca:ContentAlternatorCookieSetter/>
Now, how many hundreds of lines of PHP code you would have to rewrite in how many files to add similar functionality on top of an exisiting store, if it were written in PHP?
And all you need to do is get a random number, and use it to decide whether or not the cookie is persistent when you set it. Less than 10 lines.
Have you ever done split-testing of anything more than some (otherwise) static content? Or any non-static modifications of alredy non-static content or application logic?
I have. Both in PHP and JSP. And I have to say that you are mistaking. No offence, but if you think PHP is as flexible as JSP - you haven't done much of either JSP or both.
It all comes down to conditional statements and iteration.
In JSP, it's done with tags, in PHP it's done with nesting of yet more if-statements right inside the presentation layer.
PHP is great for smaller projects, but once you have to make _unanticipated_ changes it becomes a nightmare.
Did I mention that the example test I stated wasn't planned when the store software was designed? As a matter of fact, neither split-testing not persistent cart were planned.
At some point, split-testing logic (and that's just an example) was added _on top_ of the existing application.
And the persistence of the cart of added on top of that.
Things just get developed independently and plugged in when they are needed. There is nothing even close to that possible in plain PHP.
I'm not trying to put you down or anything. I'm sure you know your stuff, but I get the impression that if you actually used JSP, you haven't used it enough to see all benefits of maintaining a project over a long period of time.
It all comes down to conditional statements and iteration.
In JSP, it's done with tags, in PHP it's done with nesting of yet more if-statements right inside the presentation layer.
I'm used to conditional statements and iteration. I grew up on BASIC, C, Perl, PHP, and VB, in that order. I don't have much of a background in Java, C++, or XML.
It can be ugly, and yes, trying to modify someone else's PHP code can be tricky. But to me, object-oriented code is much more scary. I've tried modifying C++ programs, and I couldn't for the life of me even find the logic that was doing all the work.
_unanticipated_ changes
Yes, sometimes the changes have a ripple effect that mandates changes to many functions.
added _on top_ of the existing application.
And the persistence of the cart of added on top of that.
Shopping cart code should always be persistent by design, then if you want it non-persistent, all you have to do is flip a switch (in any language) to make the cookie non-persistent. How could a non-persistent cart convert better?
Have you ever done split-testing of anything more than some (otherwise) static content?
Split testing - no, not really. But I have implemented major and minor code changes in production. I think that the language you're most comfortable with (and that works best for the user) is the best.
I'm used to conditional statements and iteration. I grew up on BASIC, C, Perl, PHP, and VB, in that order. I don't have much of a background in Java, C++, or XML.
That's not the point.
It can be ugly
That is.
I don't have much of a background in Java
That's what I was stressing. People who don't have experience make judgments about the technology. No offence.
Shopping cart code should always be persistent by design
That's also not the point. I said that the cart persistence WAS NOT planned, but was added later one, with ease.
Turning something off is much easier that adding something.
Anyway, it seems like a slow day with holidays and all, so I'll make this a long post that
should illustrate the beauty of using JSP.
Hopefully, some people will get a better idea of what it's all about.
Let's say I'm creating a store.
My most basic data structure is Product; that will be one class I'll
use.
I create a tag ProductDisplayer with a single attribute - field.
This tag accepts a Product object from a parent tag and displays the
value of the field that I need. Let's assume some standard fields like
name,price,refnum. ProductDisplayer is a subclass of Displayer - a
generic tag, I created just to utilize various functions, like
converting time or floating point numbers to string in the format that
I want.
This tag does not need to know where or how to obtain Product
objects. They are handed to it by it's parents.
In my templates, I would have something like:
Buy <ProductDisplayer field="name"/> at $<ProductDisplayer field="price"/>I don't care about the layout either. I can just drop the field
wherever I need.
Since, in reality I need to get the product data from somewhere, I
declare an interface ProductProvider. This interface states that any
tag that implements it is capable of providing a Product object to
it's child tags.
Let's say I need to list all products in a category.
I create a tag ProductListForCategoryRetriever which implements
ProductProvider - meaning, it will provide Product objects to it's
children. At the same time, it will require information about
category, for which to locate the products. As in the case with
Product, our ProductListForCategoryRetriever does not care where the
category data comes from. It expects it's parent tag to implement
CategoryProvider and hand a Category object down to it.
So once, it gets category data, it locates all products for that
category and start iterating. On each iteration, it passes one Product
object down to it's children.
Now, I have to get category data from somewhere.
So I create another tag, CategoryFromRequestRetriever, which
implements CategoryProvider. This tag's job is to check the request
parameter called "catid," get that number, retrieve category data,
construct Category object with that data, and pass that object down to
it's child tags.
What do we have so far?
Let's create a simple template.
<CategoryFromRequestRetriever>
<ProductListForCategoryProvider>
Buy <ProductDisplayer field="name"/> at $<ProductDisplayer field="price"/> each.<br>
</ProductListForCategoryProvider>
</CategoryFromRequestRetriever>
We would get output like:
===
Buy Some Widget at $9.95
Buy Another Widget at $19.95
...
===
Now, we would also like to display a title of a category, so we create
a tag CategoryDisplayer. Which works on the same concept as
ProductDisplayer. It gets Category object from a parent tag, and
displays a field.
So we add this to our page:
<CategoryFromRequestRetriever>
<CategoryDisplayer field="name"/><br> <ProductListForCategoryProvider>
Buy <ProductDisplayer field="name"/> at $<ProductDisplayer
field="price"/> each.<br>
</ProductListForCategoryProvider>
</CategoryFromRequestRetriever>
And now the output looks like:
===
My Best Widgets
Buy Some Widget at $9.95
Buy Another Widget at $19.95
...
===
Now, how about we create a path listing like:
Catalog > Widgets > My Best Widgets
For that, we would only need to implement one more tag.
We already have CategoryDisplayer tag, so we can display them.
We also have CategoryProvider interface, which defines child-parent
contract.
So let's create a tag called CategoryPathForCategoryRetriever.
This tag's job is to take category data from it's parent, traverse
to the top of the catalog, create a list of categories on that path
and provide that list to it's children, one Category object at a time.
So this tag both uses CategoryProvider and implements it.
It does not care where the category (for which it needs to find path)
comes from; parent provides it. It also does not care what is going to
happen with the list of categories - children will deal with them.
So let's add it to our template:
<CategoryFromRequestRetriever> <CategoryPathForCategoryRetriever>
<CategoryDisplayer field="name"/> >
</CategoryPathForCategoryRetriever>
<CategoryDisplayer field="name"/><br>
<ProductListForCategoryProvider>
Buy <ProductDisplayer field="name"/> at $<ProductDisplayer
field="price"/> each.<br>
</ProductListForCategoryProvider>
</CategoryFromRequestRetriever>
And now we get the output:
===
Catalog > Widgets > My Best Widgets
Buy Some Widget at $9.95
Buy Another Widget at $19.95
...
===
You see, CategoryFromRequestRetriever gets our category based on the
request parameter.
It then provides it to CategoryPathForCategoryRetriever to find the
path for that category. That tag, in turn, passes Category objects to
CategoryDisplayer inside it (one at a time). And ones it's done
iterating, it displays the original category (as provided by
CategoryFromRequestRetriver).
Right now, I reused the same code in multiple places.
And I'll keep reusing it whenever I need to display any info about
categories or products.
And the best part - I don't care what my stuff will look like, until I
actually get to designing it. I'll just plug the tags into HTML any
way I need.
Now, I need to create the same path on the product details page, and
not just on the category page.
So I add a tag CategoryForProductRetriever, which needs
ProductProvider parent and in turn provides Category obejcts to
children.
Following the same logic, in order for me to have
Catalog > Widgets > My Best Widgets
on the product page, I need
<ProductFromRequestRetriever>
<CategoryForProductRetriever> <CategoryPathForCategoryRetriever>
<CategoryDisplayer field="name"/> >
</CategoryPathForCategoryRetriever>
<CategoryDisplayer field="name"/><br>
</CategoryForProductRetriever>
</ProductFromRequestRetriever>
How much of my code I just reused?
And did I mention that I don't care about the layout?
I can keep adding tags as I go.
If I need to display product info in the shopping cart, I'll create
another tag ShoppingCartProductListRetriever which would act as a
ProductProvider.
I would have something like:
<ShoppingCartProductListRetriever>
<ProductDisplayer field="name"/><br>
</ShoppingCartProductListRetriever>
There are two important points:
1) You absolutely don't give a flying f*ck about the presentation,
when you code logic. I just can't stress this enough.
2) You keep reusing more and more code as you go.
Right now, I have around 90k line of java code, counting only servlets
and JSP tags, which is a result of a code-base that was maintained
over several years. That means I have hundreds of structured tags that
describe all data structures used in the store:
Product,Category,Discount,Affiliate,ShoppingCart,Order,OrderAddress...
the list goes on. And more importantly, a lot of relationships between
that data, such as products for category, orders for affiliate,
discounts for customer...
So when I need to add or change something, I simply write new tags,
when I need (and most of the time I don't need new tags, I just
operate with the existing ones) and then I plug those tags into JSP
templates.
So when I need to create a confirmation e-mail for a customer, I have
something like:
<OrderBlahBlahRetriever>
<ProductListForOrderRetriever>
<ProductDisplayer field="name"/>
</ProductListForOrderRetriever>
</OrderBlahBlahRetriever>
...still using the same ProductDisplayer I coded on my first day.
Hmm, you know what. After spending all that time coding, I just
realized that some of my products have quotes in the name, and when I
use them inside alt of images, I need to change them to ", but
when I send text e-mail, I need them in plain text _"_.
What should I do now? Should I define a new module or a method to
display products? And use two of them, and keep updating two of them
whenever I make more changes that deal with the Product object?
No, I just open my good old ProductDisplayer class and add an optional
attribute, let's call it outputMedium. It can either be HTML or TEXT.
If it's not specified, ProductDisplayer assumes HTML.
Based on that attribute, my tag can now be used in the confirmation
e-mail logic with just a simple change to:
<OrderBlahBlahRetriever>
<ProductListForOrderRetriever>
<ProductDisplayer field="name" outputMedium="TEXT"/>
</ProductListForOrderRetriever>
</OrderBlahBlahRetriever>
So I only spent 5 minutes updating the tag's class, and 30 seconds
updating the e-mail compilation logic.
If I needed to add that functionality for all tags that display data,
and not just ProductDisplayer - then I would update the Displayer tag
instead.
Business is good, I'm expanding, and now I ship world-wide.
This brings a problem. Product objects have a field called eta, which
carries a date of when the out-of-stock product will be back in
stock. I used to display the date as MM/DD/YYYY, but now I need to
change it do Month DD, YYYY. I need to write out the month to make sure
people don't confuse month with day digits.
I have two choices, either look for each place where I used
<ProductDisplayer field="eta"/> or edit the ProductDisplayer class,
and updated formatting.
But now, I realize that I need to display time in a different format
based on different circumstances, and for different displayer tags,
not just ProductDisplayer.
So I update Displayer tag, and add another attribute timeFormat, which
controls the output of time stamps.
After that, I change the deployment info of all the displayer tags
that need to use time/date formatting and specify that all of them have this attribute.
All my displayers are sub-classes of Displayer, so if I modify the
output processing or Displayer, it affects all of those classes.
I just need to change the deployment info, and then I can use
something like:
<ProductDisplayer field="eta" timeFormat="MM/DD/YYYY"/>or
<ProductDisplayer field="eta" timeFormat="YYYY-MM-DD"/>
So as time passes and you add more tags to your toolbox, you'll soon
realize how much time you are saving whenever you need to add a
feature or make an update.
What if I need to display a sign "In-Stock" or display the eta date for an
item?
I create another tag (without having to make any changes to the
existing code base).
Let's call this tag ProductStockInfoMarker, with an attribute
markType, which can either be INSTOCK or OUTSTOCK.
This tag expects a product handed to it by a parent tag and if the
stock info matches the markType, then it iterates once. It also acts
as a ProductProvider for it's children; simply passing the same
Product object it gets from the parent.
So we would have something like
<ProductBlahBlahRetriever> <ProductStockInfoMarker markType="INSTOCK">
<ProductDisplayer field="name"/> is in stock and ready to be
shipped.
</ProductStockInfoMarker>
<ProductStockInfoMarker markType="OUTSTOCK">
<ProductDisplayer field="name"/> is out-of-stock, but we expect a
new shipment on <ProductDisplayer field="etd"
timeFormat="MM/DD/YYYY"/>
</ProductStockInfoMarker>
</ProductBlahBlahRetriever>
Depending on the stock status, one if those tags will iterate.
So I'll get something like:
My Widget is in stock and ready to be shipped.
or
My Widget is out-of-stock, but we expect a new shipment on 10/02/2004.
And the best part is, I can now reuse this tag, ProductStockInfoMarker
inside category listings. I list all products in a category, and
either display a price or a sign "N/A". Let's modify our first
example.
<CategoryFromRequestRetriever>
<ProductListForCategoryProvider> <ProductDisplayer field="name"/> -
<ProductStockInfoMarker markType="INSTOCK">
<ProductDisplayer field="price"/>
</ProductStockInfoMarker>
<ProductStockInfoMarker markType="OUTSTOCK">
N/A
</ProductStockInfoMarker>
<br>
</ProductListForCategoryProvider>
</CategoryFromRequestRetriever>
We would get output like:
===
Some Widget - $9.95
Another Widget - N/A
...
===
How much code did I just reuse? In how many different places?
Now imagine the same thing not with 10 tags, but with 500, and you'll
soon understand that JSP is simply on another level.
I still get surprised sometimes when I need to change what seems like
a serious feature or add somewhat major stuff, and I get it done in 10-20
minutes instead of a few days or a week that I thought I would need.
You really see the difference when you have implemented all the
basics.
Oh yeah, did I mention that I don't care about the layout? - I just
plug the tags wherever I need them :)
Very interesting indeed, nice post!
It's got the same advantages though, in terms of code re-use as well as separation of logic from presentation.
In terms of internationalization, PHP has got a long way to go. Currency, number and date formatting are much easier in Java, as there are already classes that will format it for the visitor's locale.
Kind of like CSS though, it only clicks when you actually use it for a little while. I recently had to do a bit of PHP work and couldn't believe I used to work with it- how did I ever manage?
Hmm... my JSP code looks very, very different! For example, I prefer using filters that aren't even in the JSP at all to handle such things as cookies/sessions.
I'm writing an ebook about testing and tracking, and here is what I wrote some time ago:
===
The basic concept of such implementation consists of inserting the tracker function at the top of every page (the beginning of the request/response). The details are completely dependent on the specific technology that you use. For example, if you use Java filters, then your original content won't have to be modified at all, but with something like Perl CGI, you would have to rewrite each and every file.
===
So no argument here. I just posted those tags for tracking because that's what I use. And I don't use filters for those purposes, simply because filters weren't finalized yet when that part of the code-base was programmed.
I recently had to do a bit of PHP work and couldn't believe I used to work with it- how did I ever manage?
LOL. Happens to me sometimes. So true.
But i would definitely not choose JSP as it mixes
code and presentation.
(Also wouldnt use struts or taglibs)
What are your framework choices these days?
