...My sense of it is that on Java, too many web frameworks - think JSF, or Struts 1.x - consider the Web something you work around using software patterns. The goal is get off the web, and back into middleware. Whereas a framework like Django or Rails is purpose-built for the Web; integrating with the internal enterprise is a non-goal...
Coté then proceeds to explain the abstraction levels of a typical Java web application in a somewhat sarcastic-al tone. Summarizing his points:
- - The VM itself is an abstraction from the OS.
- Libraries such as JNDI or JAAS start as classes that model possibilities.
- A UI may need to be swapped out in the future so abstract it.
Coté does go on to say that some abstractions such as file systems, sorting algorithms, collections work well for Java. However in general he feels:
- By the time you’ve written your abstraction layer, you’ve essentially written your own framework. Chances are, you’re not a good framework writer, and it’s going to suck, and you’re going to realize that one or two versions down the road and re-write it.
- New frameworks and ways of building applications will come along that you want to use (web applications, clustering, Ajax, mobile access) that don’t readily map to the metaphors, idioms, and expectations of your abstraction layer. At this point, you’ll get upward leak as the new things you want to do are bolted onto your abstraction layer.
- The chief reason it’s crap, and to Bill’s point, is that you’ll always be sacrificing fully taking advantage of things you’ve abstracted away, or making them harder.
The theory is then suggested that developers using technologies such as LAMP, Ruby, and Django see themselves as building web applications. Java developers on the other hand are more of the mentality that they are building an application which happens to have a "view" of the web.