This thread starts with Bill de hÓra’s excellent Design for the web, which has useful links and commentary about problems with Java web frameworks. Coté follows up with Java’s Fear of Commitment, also very good, and interesting discourse breaks out in both parties’ comments. Obviously, Bill and Coté are correct; embracing the Web is going to get you a better result on the Web than not embracing the Web. If you want more evidence, look no further than PHP, a deeply-flawed tool whose success is based on (admirably well-done) Web-centricity. Normally, I’d leave it at that, but Coté is wrong about Java and Bill is wrong about both ETags and MVC, and I think all of those things are important enough to push back on.
ETags · Bill highlights the ETags support in Rails and Django as evidence in his argument that embracing the Web is a good thing. That’s true insofar as Rails and Django at least recognize that ETags exist; but in fact the default implementations are very nearly useless.
What do ETags do? They allow you, when you fetch a Web resource, to send a short string along with the request saying “this is the signature you sent me for the version I know about”; then the server can look and see if the signature is still good, and if so not bother sending the data redundantly. Which is potentially a big, big win.
But also potentially not. If you look at actual real-world servers that are maxed out, they’re mostly maxing out on computation or back-end database traffic, not on bandwidth to the Net. So the saving that would be really valuable would be if you didn’t have to rebuild the requested page. Unfortunately, both Rails and Django rebuild the requested page, then compute the signature, then check the ETag. Which is extra run-time work in order to conserve a resource (Web bandwidth) that probably isn’t the problem.
What you want to do is compute the ETag based on the underlying data resources that actually drive the page creation; the input to that process, not its output. This is often going to be a small number (sometimes one) of timestamp or version fields in a database row, or metadata from the underlying filesystem. It’s also going to be application-dependent. So a framework that was really designed for the Web would expose the ETag generation to the application programmer in a way that let them be smart about conserving the resources that actually matter.
For example, when the Apache webserver accesses a resource which is a static file, the ETag is based on its inode number, size, and last-modified time. Which you get almost for free from the OS without even having to open the file.
MVC · While I’m beating up on Bill (and once again, let me emphasize that his central thesis is right-on), over in Coté’s comments he praises Django, saying “it does not follow MVC. MVC is for desktop apps not web sites.” Well, I hear gripes about Rails, but they typically aren’t about its MVC-ness; in fact I mostly hear warm-fuzzies about that, just because it’s a maintainability boost, helping you find the code you need to hack to kill a bug or build a feature. So on this issue, I don’t think the evidence is with Bill.
Java · Coté invests multiple sarcasm-laced paragraphs sneering at Java’s insistence on making as much of the underlying infrastructure swappable as is reasonable. Then he backs off and says “There are some things that it works well for in Java — file systems, sorting algorithms, collections, and all sorts ‘low level’ API things.”
Well, d’oh. And in fact Ruby and Perl and Python and PHP let you swap out pretty well all the same stuff. WORA isn’t just for Java any more, and WORA is a very very good thing indeed. Even the bloody C code I’m wrestling with for mod_atom already runs fine on OS X and Linux and Solaris, and will probably be easy to get going on Windows, because of Apache APR; you know, swappable infrastructure stuff.
The problem with those Java frameworks isn’t about swapping or abstraction, it’s that their designers couldn’t bring themselves to embrace the Web as it is. BTW, check out the recent EE work and the REST JSR and Grails. The Java community has noticed.
Anyhow, like I said, Coté and Bill both get the answer right and their pieces are worth reading. Which is why I think it worthwhile to point out missteps along the path.