Women in Technology

Hear us Roar



Article:
  Why Web Developers Need JavaServer Faces
Subject:   Nice comments, but...
Date:   2003-07-25 13:34:10
From:   chuckcavaness
Canít say that I disagree with all of the comments here, but some are pretty biased. As far as JSP and Tags being a ďbig ugly kludgeĒ and a mistake, I would agree there are some issues but someone might want to inform the thousands of applications built and running using these technologies; successfully I might add. I know, I know, there are also many applications implemented with CGI, or Active Server Pages, or other non-perfect technologies. My argument doesnít necessarily make JSP good. But read on.


Hereís the problem as I see it. I want a UI technology where I can describe a UI separately from other aspects of the architecture, like business objects or data access layer. Have the UI architecture work for multiple channels, Web, Rich Client, Handheld, etc. and provide all of the typical features that as developers, weíve come to expect (localization, session management, security, validation, etc). And I want a consistent, portable approach. Note that I didnít say a standards-based approach. Although I think that inevitably an approach based on standards is beneficial, it doesnít bother me that if in the beginning there are no official standards if this helps to move the innovation along. Look at Struts and its popularity. There were no standards for its Tags for example until JSTL came along. This is fine with me.


However, we have to solve the problems I mentioned above. Just as people are tired of trying to decide what persistence mechanism to use for every new project, choosing a UI framework shouldnít be so difficult. However, Iím perfectly ok with letting the market settle that question. Regardless, I havenít seen a solution thatís perfect; each one comes with itís own scripting language or framework oddities. Why is choosing the best of all and combining into a single approach bad if it simplifies development and gets product to market faster?


So, whether itís JSF or some other technology or whether Sun and company develops it or it comes out of the Apache birthing ground, I donít care. The important thing is that we keep the innovation moving forward and donít settle on where we are currently at as an industry. Itís just not enough for large, multi-channel, enterprise-class applications.

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • Counterpoints ...
    2003-07-25 13:57:48  hlship [View]

    First off, there's a myth about the "pluggable, skinnable" UI ... that the difference between a desktop/browser UI, a rich UI and a cell-phone UI is just a matter of paring down the interface.

    I've found this to be anything but the case; these different interfaces are funamentally different applications ... new use cases, new storyboards, different functionality. Trying to leverage reuse in the UI is a terrible idea; the end result (whether using JSF, XML/XSLT or something else) is to increase unwanted interdependencies between these fundamentally different applications ... it's programming inside a big case statement and will simply not scale.

    Reuse is best reserved for the application layer (EJBs and beyond).

    Main point:


    "Why is choosing the best of all and combining into a single approach bad if it simplifies development and gets product to market faster?"

    Where did this statement come from? Under what circumstances is JSF an integrating approach? JSF is anything but ... it locks you into a very specific event cycle and requires extensive tools support. Additionally, each vendor is likely to provide vendor-specific JSF components; it's the only lockin they have left.

    More importantly, there's no evidence that JSF is capable of being the kind of integration technology that would allow developers to choose the best. It is something of a least-common denominator choice, partly because it is bound to JSPs, a limited and problematic technology.

    You are right that no Technology will address every need but I feel that Tapestry is better positioned than JSF to address real developer's issues. Tapestry works very well as an integration platform for varied technologies because so much of it is based on JavaBeans properties (and OGNL, a vastly superior expression language).