InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

A Wicket User Revisits JSF

Posted by Scott Delap on May 18, 2007

Sections
Development
Topics
Web Frameworks ,
Java
Tags
Wicket ,
JSF
Peter Thomas recently took a second look at JSF after developing most recently with Wicket. The evaluation was prompted by his recent writing on migrating from Spring MVC / Webflow to Wicket. Many readers of his thoughts on that process were curious if he'd seriously considered JSF. Thomas uses the creation of a simple discussion forum for his comparison of JSF and Wicket. He shows the various portions of the web application side by side including web.xml, dependencies, and business/presentation components of each page. Some of the highlights of his findings:

Project Structure -Wicket does not require any extra XML config like you have faces-config.xml for JSF. It also does not require JSPs.

Footprint and Dependencies - Thomas uses Jetty in his evaluation. Removing JSP support from Jetty for the Wicket version saves over 5MB. JSF has around 3MB of library dependencies compared to the 2MB for Wicket.

Page Complexity - In Wicket complexity moves into Java code. In JSF a large amount of complexity is in the JSP pages themselves.

Comments on Thomas' comparison consider if it is a fair one:

Can you fast forward to 2007? Look at JBoss Seam which makes JSF development much more pleasurable. Don’t get me wrong, I like Wicket and its philosophy but this isn’t a fair comparison to modern day JSF, especially with a trivial example as you’ve shown.

Another reader writes however:

Excellent article. I’ve worked with both technologies, but seeing them side-by-side like this was very easy to follow and clear to read. While some of the vendor-specific technologies mentioned above might make JSF easier, I think your comparison was fair.
Wow by Jacob Hookom Posted
Re: Wow by Eelco Hillenius Posted
Re: Wow by Tim Fennell Posted
Re: Wow by Jacob Hookom Posted
Summary: Bloke who likes to do everything by hand doesn't like to use tools by Steve Jones Posted
Re: Summary: Bloke who likes to do everything by hand doesn't like to use t by Peter Thomas Posted
Re: Summary: Bloke who likes to do everything by hand doesn't like to use t by Eelco Hillenius Posted
  1. Back to top

    Wow

    by Jacob Hookom

    Footprint and Dependencies was a comparison point? Wow, I don't know if I can spare an extra MB of dependencies. The point of moving page complexity into java code as a pro for wicket is somewhat misleading, considering you can do the same in JSF by simply placing a "bind=#{foo.bar}" in any JSF tag/component and accomplish the same thing. And Wicket still faulters with reflection-- EL/property string-- same thing. I have to say though, the zero config works really well for small, 3 page apps.

  2. Back to top

    Re: Wow

    by Eelco Hillenius

    Wicket still faulters with reflection-- EL/property string-- same thing.


    The example uses property models, which indeed are based on introspection (like EL). However, you can just implement IModel directly, and you can build your application as statically typed as you wish.


    I have to say though, the zero config works really well for small, 3 page apps.


    And 1000 'page' apps alike. You don't *need* configuration with Wicket like you would with JSF.

  3. Back to top

    Re: Wow

    by Tim Fennell

    > I have to say though, the zero config works really well for small, 3 page apps.

    That's very unbecoming of you Jacob. It's almost (well, maybe not quite) like saying EJB2.0 scales better than 3.0 because it uses so much more configuration ;)

  4. Back to top

    Re: Wow

    by Jacob Hookom

    it was a comment on the scope of comparison, not on wicket itself

  5. Back to top

    Summary: Bloke who likes to do everything by hand doesn't like to use tools

    by Steve Jones

    A whole JSF article using "Netbeans" (Studio Creator 2 would have been a better bet) and the comparison is on size of server executable (got to save that disk space, its such a problem these days) and the JSF bit being a bit of a pig to work with.

    THAT IS THE WHOLE POINT. This reads like someone comparing RMI with socket writing and complaining that RMI was a complete pig, while not using any of the RMI tools. Its very sad how we continue to have an industry with an obsession with hand cranking pages.

  6. Back to top

    Re: Summary: Bloke who likes to do everything by hand doesn't like to use t

    by Peter Thomas

    Size of the server executable and the number of dependencies are just the first in a series of side by side comparison points and the full blog post has more details, (including comments from JSF users acknowledging that the comparison is fair).

    BTW Wicket has tools as well, there are plugins for Eclipse and *NetBeans*.

  7. Back to top

    Re: Summary: Bloke who likes to do everything by hand doesn't like to use t

    by Eelco Hillenius

    Its very sad how we continue to have an industry with an obsession with hand cranking pages.


    If it wasn't for these pesky programmers with their obsession for 3GL languages, everyone would have been using 4GL tools by now. ;)

Educational Content

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.