Jörn has posted 4 posts at DZone. View Full User Profile

Barrier to Entry for PHP and Java Web Applications

05.22.2008
| 11558 views |
  • submit to reddit

Jeff Atwood's latest post on PHP sucking hard, while powering a very decent amount of the internet, got my attention. Not so much by the content itself, but rather because I was thinking about PHP and Java web applications a lot lately anyway.

This blog is powered by PHP and I write little PHP scripts once in a while to mock a server for testing my jQuery plugins. On the other hand, I'm designing, architecting and writing a web application in Java. In the case of testing jQuery plugins and the application, the tool is the right one for the job. I'm not so sure about this blog, Wordpress and PHP. Jeff's post links to more than enough arguments why PHP isn't the right tool...

But the quality of the programming language is a too small part of the picture. I consider the barrier to entry an important part. Its a hell of a lot easier to get started writing a PHP application. Just create a new file. Finding a hoster for that application is easy, too, and can be as cheap as a few bucks per year, literally. Setting up a shared-hosting enviroment is rather easy, too, as each PHP request runs in its own shared-nothing process.

Installing Wordpress is frickin' easy, too. Download the current release, upload it via FTP, enter DB info into a plain text file ("plain text" in contrast to verbose xml configuration buried within JNDI datesource defintions), and done!

The barrier to entry for writing and deploying Java web applications is a bit higher. Java hosting is rare and expensive. Writing a Java web application requires at least two files and one folder, one file being an XML configuration file placed inside that folder. Deploying applications heavily depends on the hosting enviroment. Usually it involves uploading a war-file via FTP or webinterface, I don't even know how it works in shared-hosting enviroments.

A few hosters support JSPs: Just upload a .jsp file and point the URL. Pretty close to the PHP model, arguably much worse. JSPs invite you to mix HTML and Java, which is much worse then mixing HTML and PHP. A JSP has extra tags to import classes, and of course tags for SQL queries, if you are really desperate. You loose the benefits of static styping while still bearing the cost, unit-testing is somewhere between extremely hard and impossible, certainly not worth it anymore. In other words: JSPs provide no reasonable benefits over PHP.

That leaves us with a lot of work ahead to lower the barrier to entry for Java web applications. The most potential is creating applications. The create-a-file-to-create-an-application mode is as easy as it gets, so we'd need some abstraction that allow you to create a servlet application with just one file, and no xml configuration, please.

Once creation is a matter of creating a file, deploying should boil down to uploading that file. Once that is possible, hosting will improve - its than a matter of supply and demand.

I hava few ideas for the necessary abstractions and will post about them. Thoughts and ideas are very welcome - maybe I'm looking in the wrong direction here.

Published at DZone with permission of its author, Jörn Zaefferer.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Kevin Daly replied on Thu, 2008/05/22 - 7:55am

I think that providing some sort of hosting framework based on Groovy's GSP could be the answer to providing a lower barrier to entry for Java, service providers could easily provide the same sort of hosting that PHP offers with GSP and it would be fairly easy for them to restrict access to certain api's.

 The main problem with hosting Java/jsp/servlets is that with access to the full Java API, a hosting provider cannot maintain control of the resource usage. GSP could be easily modified to provide this sort of functionality.

Thierry Schork replied on Thu, 2008/05/22 - 9:06am

The problem with PHP is that being so simple and easy to start with, a lot of bad developers do bad things with it.

This is beginning to become annoying...
The quality of the developpers has nothing to do with the language.

I did spaghetti code when I started PHP. So did I when I started java. So did I when I started Python.

Now, almost 10+ years later, I can write clear and proper code in PHP and python, in a MVC vision.
At least, since I left java the java boat in the mean time, I can do that in PHP and Python.
Design patterns, test driven development, unit testing and agile methods can be applied to any language.
And I love PHP for it's lack of enforcement.

It's exaclty why I feel that frameworks are not that good.
When I use turboGears, I wish that I could not use an ORM mapping. It's something I personally dislike.
I like SQL, and I want to control the structure of my tables.
I want to choose where to put the joins, and in which order.

But beforethis freedom that PHP gives you, I must say that I rejoin your view Jörn.
Deployment of PHP "apps" is a breeze.
The last sleepless night I spent tryingto integrate turboGears to apache is the consequence of that fact.

Once java or python apps installation will resume to upload files to the server, then you will see a growing usage of those technologies.

Honey Monster replied on Thu, 2008/05/22 - 1:48pm

Once creation is a matter of creating a file, deploying should boil down to uploading that file. Once that is possible, hosting will improve - its than a matter of supply and demand.

+1. Spot on. 

I hava few ideas for the necessary abstractions and will post about them. Thoughts and ideas are very welcome - maybe I'm looking in the wrong direction here.

You may want to look in the direction of ASP.NET and IIS for inspiration. Build providers observe the directories and invoke compilers whenever a file is uploaded. Page handler factories will observe for changes in templates and codebehind. If a central assembly (the equivalent of a .class or .jar file) is changed, IIS will seamlessly spin up a new process with a new thread pool and drain the old one in order to activate the newly compiled unit with no service outage. Minor changes is handled without creating a new process. The result is the same experience as with scripted languages: Just upload or change the file, no configuration (unless you want to override defaults), no compilation.

Maybe JavaRebel has something to offer in this department?

Collin Fagan replied on Fri, 2008/05/23 - 11:54am

Back before tomcat and JVMs that ran inside web servers one could have accessed java via CGI. The VM would only exist long enough for the HTML to be generated and returned. This is very close to the PHP model, every page request has it's own process. Today one might integrate the new Compiler API and a templating engine like StringTemplate to create a simple "remember nothing" system based on a java source file and an HTML template. Now we all know this type of thing won't scale well. Every page request is going to pay the price of VM start-up time. Sometimes it's going to pay for compiling time. It also will have to do file I/O to read the template every time. But this isn't about scaling, right? It's about saving resources in an idle system, right?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.