JSP vs PHP

Not to cause a flame war, but recently I compared JSP with PHP and here is what I got.

Sr. No.	Function / Feature	JSP	PHP
1.	Programming Approach	Completely object oriented Advantage: Clean code Disadvantage: Too descriptive	Scripting with object oriented support Advantage: Functional and quick coding, you can use OOP practices at your convenience Disadvantage: May get clumsy
2.	String and data manipulation	Rich library, too much descriptive and object oriented code	Rich functionality. Functional and easy coding.
3.	Web Oriented features Includes Mails File Uploads Form Handling Sessions	Almost everything is built in or supported by libraries. Complicated and too much of code.	Inbuilt functionality. Easy to use functions, written for the specific tasks
4.	Database Access features	Standard JDBC structure/ Use EJB/ Struts framework built over JDBC. Descriptive and too much overhead or boiler plate code involved. Uses the same API for all databases using JDBC drivers	Dedicated inbuilt libraries for most of the commonly used databases. Very tight integration with MySQL and PostGRESQL. Very minimal boiler plate code required. The libraries and results are straight forward and easy to use.
5.	XML/XSL/XPATH	Use standard SAX/DOM parsers. Too much boiler plate code involved. Well defined APIs and stable implementations are available for XSL and XPATH	SAX and DOM parsers available are easy to use and to the point. Another library, Simple XML provides very easy OO approach to handling XML data. XSL and XPATH functionality is also built in.
6.	Extensibility	Java Classes and Libraries. Run’s in sandbox and hard JNI approach needed to integrate with server programs.	PHP/C/Any thing executable by the underlying OS platform. Can very easily interact with programs on the server. Very good support for native code.
7.	Dynamic Graphics/PDF and bells and whistles	Almost everything has a readymade library	Supported internally or though libraries.
8.	Web Services/SOAP	Addon Libraries like Axis, JAX-WS, etc.	In Built
9.	Portals	Spec JSR-168 and 286	Many different Portal frameworks

Conclusion:

I have generally found that anything can be down in both the languages. Just while working with the Web Applications, PHP tends to do easy things the easy way and also manages difficult things in a fairly decent manner. JSP, being built over Java, a generic OOP language, involves more structure and coding.

Generally observed in my past experiences and by most of people who have worked on both platforms is production in PHP is quick as compared to Java. But maintenance of PHP code tends to be difficult due to lack of constraints on the developer for structuring the code. But this can be made over by following proper coding guidelines.

The lack of tooling for PHP is also many a times a concern.

But overall, PHP is much more well established with libraries, frameworks, patterns and code base for general Web Dev, while java’s base is much more standard’s oriented. For example we can take the Portals. Java has a standard Portal Spec, while PHP has hundreds of Portals/Frameworks available not conforming to any standard.

A note about the libraries:

Though Java tends to be very much standard oriented, there isn’t much effort on the community or user or promoter’s side to organize/gather/test generic or readily available libraries.

The PEAR project for PHP libraries hosted at http://pear.php.net/ provides a large library for PHP, most of which are actively developed and tested and in production use.

Gut feeling, there is a library for everything on both platforms. Java is much more commercialized than PHP. So chances of getting a free to use, unrestricted and one source PHP library is easier than for Java.

There are many implementations for similar tasks to be done. A central location like PEAR is a good pointer to have.

Design pattern wise, like for MVC, also both platforms have libraries available. The functionality and approaches vary from library to library.

There can’t be a more stronger reason to suggest the scripting benefits than JSR 223, which plans to bring Scripting languages, specially PHP to J2EE.

With a vast number of frameworks easily available, PHP shall be my obvious choice for websites and portals.

I will prefer Java or may be .Net depending on various factors for Web Based Applications, because, they are more structured and easy to maintain and moreover may be just because they have the enterprise appeal and wide array of tools.

One major consideration while this decision is availability of developers for the platform, which is much larger for Java.

Compiled vs. interpreted languages

A friend of mine has asked me today what the difference between compiled and interpreted languages is; so here is the answer for her and anybody else who needs it.

A compiled language is one where you have to compile the code before it can be executed. The compilation process, for those that don't know it, transforms the source code into object code; the later can be directly executed by the microprocessor (as it's formed by opcodes), while the former can't. So, more generically, a compiled language can be executed, after compilation, without any helper utility. Examples of these include C, C++ and assembler.

An interpreted language is one where you can execute the code without compilation, by means of an interpreter. An interpreter reads the code from the source file and executes it, without converting it to machine code (forget about JIT compilers for now). The way this is done depends on the specific interpreter you are using; but to get an idea, they often construct a parse tree - an in-memory representation of the code structure - from the source file and then evaluate it. Examples of these include Perl, Python, PHP, Basic and POSIX shell scripting.

So... where do Java and C# lay? You will get different answers from different people. But, in my opinion, they are interpreted languages. Yes, you have to compile them, but the code you get - bytecode - is not directly executable by the machine: you need an interpreter that runs it afterwards, which IMHO, makes them interpreted. If someone designs a microprocessor that runs Java natively (which is theorically possible, IIRC), this could change.

And at last, let's see what JIT compilers are. JIT stands for Just-In-Time compiler; they are used in interpreters (specially, in Java VMs) to improve runtime performance. How? They convert the original bytecode to native instructions before executing them, so that they can take full profit of the underlying architecture. Note that this process is completely transparent to the developer and to the user, and only depends on the specific interpreter you are using.