InfoQ

News

Java and Web Application Development: Is Too Much Abstract A Bad Thing?

Posted by Scott Delap on Jul 26, 2007 08:28 AM

Community
Architecture,
Ruby,
Java
Topics
Web Frameworks
Tags
Django,
Ruby on Rails
RedMonk analyst, Michael Coté, has written a lengthy opinion piece comparing Java web application development to to development with frameworks such as Rails and Django which embrace the idea of building web applications closer to the core of their design. The commentary stems from a statement by Bill de hÓra:

...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.

7 comments

Reply

Java Developers vs. Web Developers by Matt Raible Posted Jul 26, 2007 10:10 AM
Come again? by Steven Devijver Posted Jul 26, 2007 10:35 AM
"Replace"ability of the technologies by Renat Zubairov Posted Jul 26, 2007 11:59 AM
Re: replaceability by Alex Popescu Posted Jul 26, 2007 12:56 PM
RoR: is too little abstraction a bad thing? by Jason Carreira Posted Jul 26, 2007 12:26 PM
Re: RoR: is too little abstraction a bad thing? by Michael Campbell Posted Jul 27, 2007 7:54 PM
The point is... by Remember Objective Posted Jul 26, 2007 4:06 PM
  1. Back to top

    Java Developers vs. Web Developers

    Jul 26, 2007 10:10 AM by Matt Raible

    To me, it seems like the Java Web Frameworks were built by Java Developers, whereas PHP, Ruby and Python frameworks were built by web developers. Java frameworks target Java developers, the others target web developers. It'd be cool if a Java web framework targeted web developers, but that may be difficult to do.

  2. Back to top

    Come again?

    Jul 26, 2007 10:35 AM by Steven Devijver

    The only point that I got from this article is that when programming in Java *people* tend to abstract things too much. In case of JSF that's certaintly true. But look at Spring MVC. It's the most powerful way to plug into any part of the HTTP request/response lifecycle along the lines of the MVC pattern. And yet it's pretty intuitive to use since you can ignore the intersection points you're not interested in. As far as I understand Rails and Django also implement the MVC pattern. I guess I don't get the point of this article, at all.

  3. Back to top

    "Replace"ability of the technologies

    Jul 26, 2007 11:59 AM by Renat Zubairov

    I guess the topic of replaceability of the underlying technologies was already discussed multiple times and I guess this article raises it again, when author considering replacing technologies usecase as irrelevant I strongly disagree, because of different development environments, different OSs and flexibility we gain from these abstractions.

  4. Back to top

    RoR: is too little abstraction a bad thing?

    Jul 26, 2007 12:26 PM by Jason Carreira

    When you look at things like RoR it's like they were designed to build prototypes... No referential integrity? Who needs it anyway? We won't ever need more than one way to do x, y, or z, so let's make it really hard to do it any way but the way we've hard-wired in. That's more like using Microsoft (our way or the highway) tools. Sure, abstraction can be taken too far *cough*JSF*cough* but it's put in there for a reason, because we've seen these needs before and we don't want to paint ourselves into a corner.

  5. Back to top

    Re: replaceability

    Jul 26, 2007 12:56 PM by Alex Popescu

    I guess the topic of replaceability of the underlying technologies was already discussed multiple times and I guess this article raises it again, when author considering replacing technologies usecase as irrelevant
    I don't know what camp Michael Coté is from, but even Guido van Rossum (as in Python creator) expressed his concern about the web framework technology lock ins. bests, ./alex -- .w( the_mindstorm )p. ________________________ Alexandru Popescu Senior Software Eng. InfoQ TechLead&CoFounder

  6. Back to top

    The point is...

    Jul 26, 2007 4:06 PM by Remember Objective

    Java plain sucks for web apps. The only thing that'll save it is Grails. That'll be 25 bucks. --Johnny "Article Writer" Bravo

  7. Back to top

    Re: RoR: is too little abstraction a bad thing?

    Jul 27, 2007 7:54 PM by Michael Campbell

    When you look at things like RoR it's like they were designed to build prototypes... No referential integrity? Who needs it anyway? We won't ever need more than one way to do x, y, or z, so let's make it really hard to do it any way but the way we've hard-wired in. That's more like using Microsoft (our way or the highway) tools. Sure, abstraction can be taken too far *cough*JSF*cough* but it's put in there for a reason, because we've seen these needs before and we don't want to paint ourselves into a corner.
    Jason, c'mon. The FUD is a bit much. There's nothing in Rails that negates referential integrity, and I haven't heard anyone (realistically) say there's no need for it. And, last I checked, it's in the database, where Rails can neither dictate its absence nor presence. Nor is Rails "really hard" to do many, many things that are defaulted. Webwork is great - I have a commercial site on it. But other things can be good too. And lastly, Rails never proposed to be the end-all be-all. It's SUPPOSED to be for the one corner you seem so afraid of being in. Granted, some zealots have tried to make it be a lot more than that, so blast those zealots, not the framework.

Exclusive Content

Agile Project Management: Lessons Learned at Google

In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.

AtomServer – The Power of Publishing for Data Distribution

In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.

An Introduction to Virtualization

It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.

REST Anti-Patterns

In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.

Choosing between Routing and Orchestration in an ESB

In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.

Enterprise Batch Processing with Spring

Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.

User Story Estimation Techniques

Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.

Security (CAS and OpenID) with Ruby

In this talk from QCon SF 2007, Justin Gehtland explains two open solutions to distributed identity and their Rails integration components: OpenID (using ruby-openid) and CAS (using rubycas-client).