So this post is making the rounds amongst the kids. The gist can be summed up with the graphs:
It seems to me that people building LAMP, Ruby, django, or other applications think of themselves more as building web applications with whatever technology tools they need to use: web services, cron jobs, MySQL, ruby, PHP, python, maybe some Java: whatever. What matters is getting the web application working.
People who using Java see themselves primarily as building Java applications that happen to have a “view” (as we OO head-jobs would call it) that’s the web. Our primary goal is the metaphysical and headless application, not the delivery mechanism. Hopefully you can get a sense for my view of Java culture at this point: it’s more concerned with keeping the concepts, work-flows, and design of the application pure and tidy than optimizing the delivery mechanism, or implementation. Them UML diagrams should look good.
So here is my thing, as a Java developer, I am SQUARELY in BOTH camps here. I am going to give you all my dirty little secret:
I think JSF blows chunks.
I think Seam blows chunks squared.
While I can appreciate the design ideals of component based development on the web, each of these technologies, and especially stacked, represent an abstraction above and beyond what HTTP really is that makes me sick to my stomach to think about. I will freely admit, I am a GWT bigot. Once I saw GWT at JavaOne over a year ago, I had the same gut response I had to Java itself having come from the VC++/DCOM world: this is the way we should have been doing it all along. GWT still encompasses this layer on top of native idea, but does it at the right level. GWT doesn’t pretend HTTP is smarter than it is, it just gives you a “real” and reliable client API. Moreover, you still get to run PMD and FindBugs and have good refactoring support on your code as you develop it. Win. Win. Win.
For all the humor about what “QA” loves in the linked article, I have to say “Techops loves ‘technology tools they need to use: web services, cron jobs, MySQL, ruby, PHP, python, maybe some Java: whatever. ‘” One of the things that makes JRuby and Quercus compelling is getting the WAR deployment story. A “mish mosh” application that has 40 steps to deploy to 25 web servers sucks, and it sucks worse than taking time to QA, because deployment (likely) affects the end user and not the organization.
I am not going to say Java is the End All Be All. However, I am certainly not going to poo poo the Java ethos. Granted the Java Web Dev story has not been perfect, but I will hold it up against anything else out there proudly. Moreover, I will give your circa 2002 Struts app credit for maintainability against anybody’s hand rolled PHP, Perl or whatever else App. Frankly, GWT’s unified asset deployment and deferred binding for native hacks leads me to see it as the best successor to Java in “Web 2.0″ development, but frankly anything is better than where we came from. Even RoR, which I have espoused in this space as a PHP killer over a “Java” killer, represents a step forward in maintainable code in the web tier, but only in conjunction with JRuby. The “Check out a tag from svn to all the servers” deployment method will make Techops AND QA ill, nevermind force you to do some kind of rolling load balancer hack to make it happen smoothly.
I was playing around with Seam + JSF and have come to a similar conclusion. Its goal is admirable, but in the end it's a pain in the ass. I haven't tried GWT before, but now I'm tempted.
I'll put my "hand rolled PHP" 60-line framework up against Struts, RoR, ANYTHING, anyday: http://code.google.com/p/barebonesmvc-php/
I had the same flash of relief when GWT came along after using JSF heavily for a year. JSF is unnecessarily complicated where GWT is not. GWT is a pleasure to use.
I've done plenty of LAMP development and given my choices, I'll stick with Java frameworks for jobs large and small.
I've had some joy lately with Java. Stripes is a fun MVC, no xml, and the tags bind well without much fuss.
regarding the thought process of LAMP, Ruby..etc. developers vs. Java developers...The former are building web apps, the later are wondering if hosting costs will ever come down, and while they wait, they too are developing web apps using PHP, Ruby, ...
I thought I was the only one (Java developer using PHP, etc. waiting for hosting costs to come down)!
But having said that, I have become re-educated to the fact that the world of requirements for web apps doesn't always need a Skil saw. Sometimes a hand saw (maybe even a hack saw) does the job just fine, and a lot quicker too.
There's nothing like getting in there and massaging HTML by hand; JSF makes this practically impossible. I've used Rails, GWT and JSF over the past two years, and in terms of productivity I'd rank them in that order, with JSF lagging far, far behind. How much does it suck to have to redeploy every time you make a change: answer = a lot.
In most cases I think the best choice today is GWT. Reasons: ease of use; homogeneous dev env if your business tier is also Java; allows leveraging of Java libs/community; war deployment, which is well known/used/understood/supported and platform-independent; trivial and transparent JavaScript and AJAX.
For small to medium web apps that will have limited scope and wont need to interact with existing services or tiers, Rails is the way to go.
Strange. I too had this "this is how we should have been doing it all along" feeling several times. Only at very different times.
The first time was when I started to explore JSF. All of a sudden you could bind the elements of your pages resp. your view directly to the properties and methods of your POJOs without the nightmare of having to write something like form beans and code to convert input strings to different data types (like dates) and all the way back again.
Granted, the available implementations were very immature and integration with other aspects like persistence, security and so on was a pain. But the idea was right.
Later on, I started to experiment with Seam and discovered that it freed me of all the work to integrate different frameworks for different aspects into one application. Finally there was a framework which makes all the purely technical aspects of web application development (like logging, persistence, transaction management, validation, security, page/workflow) a breeze and allows me to concentrate on what serious applications are actually about: business logic. (Given the hype about Ajax you might rather think that application development is all about snappy user interfaces.)
So I also experienced my light bulb moments, only with completely different technologies.
How is the WAR file deployment going to deal with database schema changes? I expect you'll be in the same boat as everyone else, with planned downtime.
There are ways to transparently restart LAMP applications, but everyone has this problem when a shared resource is being modified.
Add me to the list of people that have implemented more than a small website in JSF to find it saves time in some area's only to cause mass frustration whenever I need to slightly deviate from the framework (and sometimes the deviation is for common web stuff - downloading a generated PDF).
Add Tapestry to the list of potentially successful but lacking frameworks. I think it suffers most from lack of documentation, updated documentation, and poor documentation.
Anybody for doing RPG on the System i5? Now there is a language that is meant for business but can play in many other spaces too - including CGI.
Aaron Bartell
http://mowyourlawn.com
It's funny Aaron mentions RPG. I'm trying to figure out which of the multitude of Java Web Frameworks/Libraries to use to do web development on a System i. The myriad of choices is daunting to me, coming from PHP and only the Java I've done is the regular command-line stuff.
SEAM: I had the opposite experience from you on Seam. I found it rocks. I was up and running with a complete database-driven site in just over a day, including user administration, AJAX, page caching, and captcha. Reminds me of RoR, but with the super-deep libraries of Java.