Java on the Server: Too Many Choices, Too Few Real Problems Solved
- By Matt Stephens
- October 23, 2005
A few weeks back, I blogged about the choices available to developers of client-side Java applications. It’s a healthy sign for desktop Java that such choices have become available, and indeed are thriving. (Swing in particular is doing especially well).
On the server-side, there are even more choices – but this, unfortunately, proves that you can get too much of a good thing.
Having choices is great, but Java is beginning to suffer for its overabundance of server-side frameworks. It doesn't help that the competing frameworks typically are created to address a technical issue or to take advantage of new language features. It's techie heaven, but we're not seeing very many business problems being solved.
The signs of frustration are increasing in number. Recently, buggy/defunct web browser pioneer Marc Andreessen predicted that PHP will oust Java EE as the default choice for web applications. (This struck me as odd, because going by webserver stats, PHP already is way more popular than Java for web applications).
Website hosting companies typically provide PHP by default, leaving Java support to “specialist” Java EE hosting companies.
But the reason PHP is vastly more popular is because it’s targeted at a completely different audience: the breed of developer who just wants to get the job done. Unfortunately that’s, like, most developers on the planet.
PHP is great for cobbling together a simple web application quickly. People often make short-term decisions: they see the short-term productivity gain in PHP and so decide to “go with it”. But what they then miss out on is the longer term maintainability of Java-based webapps.
It doesn’t help that any programmer deciding whether to use PHP or Java will be overwhelmed by the organic landscape of choice in the Java world – not to mention the endlessly swirling discussions over the merits of each framework. JSP, JSF, Spring Web MVC, Spring WebFlow, Struts, Cocoon, Velocity, Tapestry... the list is endless.
Fair enough, in that list I’ve mixed in some frameworks that serve different purposes: Velocity and JSP are about templating, whereas Spring and Struts are more about channeling web requests to the server-side logic via “actions”, providing an MVC separation of concerns.
But for developers unfamiliar with the whys and wherefores of all these Java web frameworks, they’ll opt for PHP simply because it doesn’t baffle them with a myriad of choices and no clear winner.