PHP vs Java, dispel the myth...

Hi all,

there are tons of threads with similar topic but no one that point out every pros and cons of developing a small/middle/big/huge application using the two languages.

What will you choose if you need to develop a small application and why?

And what will you use for a middle app and why?

And what for a big and huge?

14 Replies

Actually, I would follow hoopycat's lead and develop it using sendmail rewrite rules, regardless of project size. Then, I expect someone will port it to Fortran.

This is like asking, "should I use a spade or a snow shovel when I want to dig small, medium, and big-sized holes?".

The size of the shovel isn't the question at hand. If you are digging dirt, use a spade. If you are digging snow, use a snow shovel. PHP and Java are two different tools.

Separately, without a very compelling use case, I would run hard and long from requiring Java today. If it is a specialized application that needs something exclusively offered by Java, perhaps. But with JavaScript, HTML5, and Silverlight/Flash much more acceptable to end users, meh.

Building on the snow and shovels example, I think the better comparison is as follows.

If you need to dig out a small hole, use a shovel (PHP). If you need to dig out a trench for an industrial complex where in fact it's a few dozen different sized trenches interconnected and in support of a larger infrastructure, and basically your spec defines exactly what tools you need because anything else won't be supported at the enterprise level, a shovel can do it, but an excavator (Java) will probably do better.

However, if you use the excavator be prepared to differentiate between ExcavatorFactoryCaterpillaSmallInstance and ExcavatorFactoryBomagLargeInstance. I hope they both use the same Interfaces, or you're toast.

If you use a shovel, make sure you remember if it was shovel() or shovel()…. or was it a spadeto_shovel() that you needed? No, wait, it was spade2shovel(). Oh, wait, no, it's SplSpadeShovel(). Yeah…. wait, what namespace was it, again?

Edit: I'd choose, and have been for the past few years, Python with Pyramid framework. So releaved after almost 10 years of trying to remember sho_vel() vs shovel()…

I made an assumption in my reply that client-side Java would be used if a Java application is written. That influenced my point and it probably made my response confusing.

If this is purely a server-side issue, I would object to Java on different grounds. However, one of the advantages of Java in "larger" projects is that it can be used to insulate the project from bad programmers. If the architect properly designs the application, the classes simply have to provide the proper interfaces and outputs, and the implementation is hidden by encapsulation.

However, this allows for sloppy, unmaintainable, poorly written code which ultimately serves no one well. So the "large application" advantage of Java rests mainly in its ability to allow bad work to "run". This is not to say that it can't be used well, but in my practical experience it rarely is.

Most Java apps I have to deal with are configuration sensistive, resource hogs, and leak memory like a sieve. I use them, but I wouldn't choose to use them if there was a viable alternative.

Other options for server-side applications are also vulnerable to bad programming, particularly when they involve a large codebase, or employ large, neophyte, or unstable development teams. Perl, Python, and PHP can all be used to great effect in large projects but they can also be used to create a terrible mess.

PHP is particularly vulnerable to making messes because of a combination of language design and programmer community. Perl can be a nightmare or a dream, dependent entirely on the developers skill and experience, and the willingness to invest in the required effort to do it right. Python probably offers the best object model, and though it lacks enforced encapsulation, if the team is disciplined, naming conventions can deal with that issue.

If I had to choose something for server-side, it wouldn't be Java or PHP unless something very compelling in the business case pointed at either of those. If I was choosing, a priori, a language for server-side applications, it would be either Perl or Python. Perl for my own reasons, and because I know it can be a very good choice when properly employed, and Python because it has also proven itself, and it offers a bit more orderly structure than Perl.

@Azathoth:

Edit: I'd choose, and have been for the past few years, Python with Pyramid framework. So releaved after almost 10 years of trying to remember sho_vel() vs shovel()…

I used Pylons (now Pyramid) for a while. Once I moved to Django I never looked back.

James

I use C# runs

Actually, I'm serious.

@Guspaz:

I use C# runs

Actually, I'm serious.

So do I. ASP.NET MVC for my day job.

@Guspaz:

I use C# runs

C# gives me the runs, too.

James

Ruby on Rails for the win!

Drupal if you want it fast and don't care about security.

Like the guy with the beard said, there are no easy answers. It all depends on what you want and what you need to integrate it with.

I love Java but I've considered switching to PHP, there seems to be more telecomute/remote opportunities listed for PHP coders.

How long have you got to do your development?

If you want something developed quickly look at a PHP framework like Yii / CodeIgniter. If you want to spend 3 times longer doing development use Spring MVC :twisted:

For Java, I really like the Play framework (haven't used version 2 yet)

Currently am starting a small project using Sinatra, which has been good so far.

@sednet:

Drupal if you want it fast and don't care about security.

Drupal may be many things, but fast it ain't.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct