Friday, September 19, 2008

PHP vs. JSP

There is a lot of speculation in the web about what is better - JSP (java) or PHP. Some claim PHP is insecure, which is not exactly true. Others claim JSP is hard to use or slow, which is also not true, and I intend to show why.

First, I want to rebut some of the myths around PHP and JSP.

Myth 1. "PHP is insecure". Some PHP programs may be insecure, because of their creators' negligence. These are tips to make your PHP programs secure:
  • Use PDO for database access. This will eliminate the risk of SQL injection.
  • Do not include session ID in URLs, because those URLs may be sent to other sites as 'Referrer' HTTP header.
  • Do not use shared hosting. There are a lot of virtual and dedicated hostings on the market starting from $10/month. Neither can you run Java applications on a shared hosting.
Myth 2. "JSP is hard to use". Not that hard. If you already know Java, you will invest maybe 3-4 more days to learn JSF or Struts, and this investment will return soon enough. You can use one of free or relatively cheap IDEs to master your JSF pages, and these IDEs are more advanced then those available for PHP development.

Myth 3. "PHP is not scalable". Neither PHP nor Java is scalable, because those are programming languages. A system can be scalable, not a programming language. Well, there are of course programming languages like Erlang, Forte and CUDA C extension, which enable scalability through parallelization, but PHP and Java do not differ in this respect.

Scalability of a system is its ability to increase throughput by simply adding hardware and not changing the source code. To make your PHP software scalable, just store all the state, including large files and session variables, in a database, and use database clusters with apache server on each node. Then use Cisco Load balancer or simple DNS round robin to balance load between nodes.

Myth 4. "JSPs are slow". You may take that impression because it takes some time for a new JSP to compile into a high-performing native code. First, a JSP is translated into a Java class file. That class file will be interpreted during the first invocation, but are incrementally compiled into native code during following invocations. You will be surprised how fast server-side JVM can be. It trades memory consumption for performance, e.g. by more function inlining.

There are, of course, ways to make Java slow, like using EJBs, but the same applies to PHP development.

Second, let me postulate the rule of the thumb to choose between PHP and Java for web applications. Use Java when at least two of the following is true:
  1. You do not have programmers with PHP experience handy, but you've got Java programmers;
  2. You want to use some existing functionality written in Java, which is unavailable in PHP. There are a lot of (persistence, messaging, imaging, protocol implementation, file format) libraries and frameworks for Java. Also, don't miss existing open-source applications: http://java-source.net. This may seem to be a controversial point, because there are more scripts and applications available for PHP then for Java. However, only few of them are stable or maintainable. In other words, when you choose an open-source software written in Java, there are much more chances that it will work than for the same functionality written in PHP;
  3. Your projected project size is more then 50K lines of code;
  4. You will have a heavily loaded web site.
Use PHP otherwise.

Finally, here are some tips for those who's already made his choice.

You've chosen PHP
Welcome to the world of non-professional development. Most of PHP scripts you will see in the web will not work. It is not a good idea to base a new project on an existing open-source or commercial code either, unless you need only cosmetic changes or addition of minor functionality. While existing software like PHPNuke, osCommerce and its clones, ShopScript, or even Joomla, may seem pretty, making a totally different software on top of them will most likely be extremely time-consuming. Drupal is somewhat better in this respect. Consider starting a new projects from scratch, eventually adding independent scripts and libraries like Smarty. At least in this case you will be able to use modern PHP at full extent (I mean, features like PDO, SimpleXML, new OOP model). You will focus on functionality, not on a lot of legacy code written for PHP 3.

You've chosen Java
Java is a bit messy about those APIs. Remember: JDBC, plain JSP, and JAXP are not for use. Their mere existence is either nonsense or serves needs of middleware builders. Use JPA/Hibernate for database access, JSF/Struts for web logic, JAXB or jdom for XML processing. Use MyEclipse or other IDEs to master your web applications. Do not write JSF by hand, like most PHP programmers do!

Good luck.

4 comments:

Pesculiar said...

What kind of experience with ShopScript made you so god forbidding? :)

ndv said...

A client of mine had a website based on ShopScript. The ShopScript was heavily modified by programmers who worked with the client before me.
There were many problems with the site: it was slow, had a lot of bugs, not to say the web design was poor. You may of course blame those programmers who spoiled ShopScript, but I think some of the blame should be addressed to ShopScript, because:

1. ShopScript has no modular design. None at all. Just splitting functionality between functions is not modularity. This was the main source of bugs, because the programmers had to change a lot in the original code. When I write a plugin for Eclipse, I don't need to change anything in it. Granted that ShopScript is not object-oriented, I worked with another non-object-oriented shopping cart, X-Cart, and it was much easier to modify. Not to say there are truly modular shopping carts out there, Litecommerce for example.

2. ShopScript (the version I worked with) was not designed for performance. For example, in each php invocation it lists ALL files in a directory and include them all. No matter that only half of them are really required.

3. The naming of files and templates is not straightforward. You may spend half an hour looking for the necessary template.

However, the point in my original post was not to discourage using ShopScript. It was to encourage using libraries with a specified API instead of redesigning existing solutions. My client tried to make of ShopScript's product catalog something that was not a product catalog: they created additional tables which duplicated categories and included additional domain-specific attributes. This duplication turned out to be a pain in the neck. If had they dropped ShopScript's database structure and designed a normalized database for their needs, they may have spent little more time to get the product delivered, but they wouldn't have a long bugfixing cycle afterwards.

Pesculiar said...

Well, Shop-Script actually started as on the knee last year university student's project. It has grown sinificantly now and has moved to PHP 5 and its OOP functionality is used heavily. The original author does not do any programming now and provides general project management leaving actual coding to professionals.

I bet, if you come across it again, you would not recognise it. :)

ndv said...

I will look into it, thanks!