Fog Creek Software
Discussion Board

J2EE vs. PHP for web app development

One company I work with (as a consultant) has begun moving to a J2EE environment with Struts as the framework for web development.

Certainly n-tier has its place, but many (or most) of the web apps that the organization needs developed - custom developed for internal use in the financial services industries - are limited in scope, have a small amount of direct interaction with a database backend or LDAP directory and change frequently, requiring many iterations as the business changes requirements.

So my question is:  should many of these apps - the ones that don't require n-tier - be PHP-based?

The reason I mention PHP specifically is because it has a small role in the organization already.  Months back, two similar projects kicked off at the same time in this company.  One is being done in J2EE, the other in PHP.  The PHP project is already in production, considered successful and revving for the second generation.  The J2EE application is still under development, users are complaining about performance and there's the possibility that it may be further delayed.

And a followup question might be:  if PHP is a reasonable choice, why not figure out a 'demarcation line' - a set of rules where the choice between J2EE and PHP is crystal clear.

Any of this babble make sense - and any thoughts on these issues?

Name withheld
Friday, November 8, 2002

Forgot to mention that .NET isn't an option.  Vendor-lockin is anathema to the organization in question.

Name withheld
Friday, November 8, 2002

What about an in-between solution -- Java+Struts without full blown J2EE? We've been very successful in building webapps in Java using Struts without using any of the J2EE service/entity bean and app server madness.

Recently I had to make some changes to a PHP-based PIM front-end (horder/imp/turba) and found it to be quite difficult to maintain the code. On the other hand, maintaining the Java-based web apps (which, BTW, are much more complex) has been much easier.

I think the J2EE app server model has been way overengineered for a typical web app. It looks like Sun has realized this and is now focusing more light-weight solutions, like JDO.

Friday, November 8, 2002

My company is in the same situation as yours. Unfortunatly, we have not been given much as a choice because for some unknown reason our director decided that Java is the only say to go.

Currently, my group has software written in PHP that changes rapidly and supports well over 300 users a day. We run on relatively modest servers and have very few problems. Most of our problems relate to poor database design when the system was first designed (which we are currently in the process of correcting).

There is another group here at my company that has about the same number of programmers but programs only in Java. They can only handle a smaller number of projects and there developement cycle is much longer. They also only handle 5-10 users at a time before there servers start to slow down to a crawl.

I can't think of hard and fast rules about what should be written in what language, but anything that involves rapidly changing requirements should be written in a language that can handle it like PHP.

Good luck with it all.

Friday, November 8, 2002

Friday, November 8, 2002

The reason you can't draw a "demarcation line" is that there are many more factors involved.

Does this company already have a staff of Java programmers? It sounds like there are people who *know* Java and PHP already there, but are those their main jobs?

Do they have existing libraries of business logic (not necessarily on an app server) they need to include?

Do they need to connect to and use legacy data? (AFAIK PHP is good at the former but not so good at the latter)

I'd agree with igor that PHP tends to be difficult to maintain for non-PHP people. The page creation paradigm is foreign to people in a way that Java/Struts isn't, even if the person doesn't know either.

Also, you don't need to use every aspect of J2EE. There's nothing wrong with a Struts + Servlet Container + Persistence Framework (e.g., Hibernate) + RDBMS if you don't have heavyweight needs. Entity beans in particular can be major overkill.

Finally, rapid development isn't solely a function of a language. It's primarily a function of design, no matter what language you're using.

Chris Winters
Friday, November 8, 2002


If you check out the "Why not JSP, Servlets, J2EE" section of that presentation, you'll see that the *only* reason that such solutions weren't chosen was because Yahoo is tied to FreeBSD, which (according to the presenter) does not play well with Java because of some thread performance issues.  I'm not a BSD geek, so I can't say whether multithreaded Java is a dog on FreeBSD, but it's certainly not the case that Yahoo rejected Java on the server due to its overall profile of functionality, performance, and platform independance.

Chas Emerick
Sunday, November 10, 2002

either PHP or java should work fine for "1 tier". there are plenty of JSP/Taglib/Servlet packages that have a "paradigm" nearly identical to PHP.  i would say it is a more of a factor of what languages the other programmers at the company prefer. 

Sunday, November 10, 2002

I have seen way too many CRUD apps developed over 3 tier architecture

I think it is imperative to have your migration path mapped out when you start - you can still revise it as you get wiser though

Thus start with Data-driven php/taglib apps and add processing logic either in stored procs or new tags/php classes. At some point when  it gets justified, found a 2nd tier &  move your stored procs /custom tags/php classes into middle tier.

Monday, November 11, 2002

PHP will probably be easier to develop initially. But you can guarantee that, if you've got anything even resembling a deadline, your code will become horribly unreadable given enough time. Since you talk

If you're going the Java Servlet based route, and staying away from the scary stuff like EJB (it has its place, but avoid it if that's at all possible), I highly recommend Cocoon for your web development. Its pipelines are an excellent tool for separating business logic from presentation, and adding new features or a new way of presenting existing information is incredibly easy.

Daryl Oidy
Tuesday, November 12, 2002

Dismissing a platform because of developer sloppiness is pretty weak.

If you've got a deadline, it doesn't matter what platform you're on, the likeliness of sloppier code is about the same.

PHP is just as valid a platform as JSP/Struts. I've been on JSP/Struts on projects where it was total overkill, and performance was somewhat pathetic compared to a "pure scripting" environment like ASP/PHP.

Quality code and clean architecture are more a product of a smart approach than the platform itself. Platforms don't make bad developers smarter. I seen enough bad Java code to prove that.

Steve Ng
Wednesday, November 13, 2002

I really don't mean to knock PHP, and I've certainly seen terrible Java. And my complaints about PHP apply just as much to JSP - and, as you say, the performance will be considerably worse. So if it is PHP vs JSP, PHP wins. But there are Java alternatives to JSP which are better than both.

Daryl Oidy
Thursday, November 14, 2002

If you've got a primarily Java environment, and you're looking for a lightweight way to develop bang-em-out small apps, consider a pure JSP model, using the JSTL.  The JSTL's got a very powerful and elegant tag library, and if you throw use the SQL taglib, you can do things as quick 'n' dirty as you please -- but still have them in Java, so that if the app grows, you can move toward a more architected solution without throwing away all your code (as you'd have to in a move from PHP to J2EE).

Mike Kozlowski
Thursday, November 21, 2002

Just to add my 2 cents years later. As someone stated, you don't blame the platform for what people produce. I do PHP (and Perl before that) and I use Smarty or similar tools to separate tasks (and TT in Perl).  I don't write monolithic pages which many, too many, people do in PHP. I try to keep my classes decoupled etc. etc. I've been able to adjust to many, many changes to the app over time. Now, we are having to move to Java owing to corporate pressure. I guess they want everyone to produce code as slow and as buggy as they do.  It thought we'd go to an jsp/apache/tomcat environment but for some reason they are talking about some bizarre stuff where we can only use a SUN IDE (Sun One maybe) and when we make a change to one file we have to push some megabIte sized war file or something ... this sounds terribly complicated and I'm wondering what it will make easier to compensate? I think it comes down to blaming the architects and not the platforms.

Friday, March 19, 2004

*  Recent Topics

*  Fog Creek Home