In addition, we all have our own priorities. JL clearly wanted to avoid any and all XML. Tapestry seeks to minimize Java code and preserve scalability and clusterability.
>
> Simplicity. Consistency. Efficiency. Feedback.

Wicket has all of the same goals as Tapestry plus a couple.
In particular, Wicket has a goal of safety/security, which
means NOT exposing session state.

 o EASY (SIMPLE / CONSISTENT / OBVIOUS)

   - POJO-centric
   - All code written in Java ala Swing
   - Minimize "conceptual surface area"
   - Avoid overuse of XML configuration files
   - Fully solve “back button problem”
   - Easy to create bookmarkable pages
   - Hibernate integration for easy database persistence
   - Maximum type safety and compile-time problem diagnosis
   - Maximum diagnosis of run-time problems
   - Minimum reliance on special tools
   - Components, containers and conventions should be consistent

 o REUSABLE

   - Components written in Wicket should be fully reusable
   - Reusable components should be easily distributed in ordinary JAR files

 o NON-INTRUSIVE
  
   - HTML or other markup not polluted with programming semantics
   - Only one simple tagging construct in markup
   - Compatible with any ordinary HTML editor
   - Easy for graphics designers to recognize and avoid framework tagging
   - Easy to add tagging back to HTML if designers accidentally remove it

 o SAFE

   - Code is secure by default
   - Only explicitly created external page links can expose state in the page or in the URL
   - All logic in Java with maximum type safety
   - Easy to integrate with Java security

 o EFFICIENT / SCALABLE

   - Efficient and lightweight, but not at the expense of other goals
   - Use of “sticky sessions” can achieve scalability (without failover)
   - Clustering via session replication more heavyweight, but possible

> I haven't looked at the code, but based on the notes here, it sounds
> like Wicket instantiates complete pages and stores them in the session
> ... and goes on to say that clustering is not a real option. By
> contrast, Tapestry goes to great lengths to ensure that very little is
> stored in the session, and make use of pools for efficiency.

Yup. This is a design decision difference that makes Tapestry and Wicket
very different. Wicket's design assumes that software is expensive and
complex to create and that hardware is cheap and plentiful. I think this
scenario will increasingly play out in the future and that the assumption
is a good one. I think saving the cost of a $300 e-machine (or two or
three!) by spending days fixing pooling and state bugs is just not worth
it in the end.

Failover clustering (you can always do sticky session clustering) does
not exist simply because I've been the only one working on Wicket and
I cannot create a worthwhile failover clustering strategy by myself
inside the 1.0 release timeframe. Actually, I'm currently looking for
help to do this for 1.1. Questions remain about exactly how to do
clustering, but I can think of several good basic alternatives. The
trick will be making the replication really efficient. I believe that
will turn out to be do-able.

Page state is very lightweight in Wicket because it seeks to make the
maximum amount of each page immutable. The immutable state is shared
among all pages across all sessions. So what ends up in the session is
typically fairly small and in the future there may be ways to further
reduce that state. Benchmarking of object sizes shows that a typical
page is a few KB in size. While this is signifiant, you can immediately
cluster wicket using sticky sessions and in the future there will be a
failover clustering strategy of some sort.

> On the other hand, Wicket looks like it uses very little reflection, whereas
> Tapestry (via OGNL) uses quite a bit.

Correct. Wicket actually uses OGNL in language internationalization, however.

> I think the HTML templates are pretty equivalent. I'm concerned that,
> like older versions of Tapestry, the HTML templates must be stored in
> the classpath with the Java classes, which hampers the efforts of HTML
> designers to work with, and preview files.

This was a design decision, and while I agree with your concern, I think
packaging the associated markup files in a modular way is more important
than lumping files together for designers to work on. For one thing, it
makes component software easier to produce and maintain. And a simple
copy or zip filter or other solution can always be used to handoff the
HTML files... although they ultimately DO have to have the same folder
nesting.

> Wicket does get high marks for consistency; especially consistency
> with the ideas behind Swing. Tapestry's long evolution has resulted in
> a wide range of choices.

Yes and no. Wicket is very Swing-like in its component/container nesting.
But I'd say it's a lot less verbose.

> Tapestry wins on feedback ... I munged some of the Wicket URLs and got
> nothing but a simple stack trace.

This is actually just a bug. Wicket has substantially good feedback pages,
including detailed stack traces and HTML which highlights the location of
errors. If you can repro the bug, please enter it in the Wicket bug db!

> I didn't see internationalization issues addressed anywhere.

I18N is addressed throughout, as well as "skinning". See the PUB
example, where you can switch between American and Canadian English
Locales, eh. You can also do some really neat stuff with OGNL to
localize strings used in web applications.

> Like Tapestry (3.0) everything runs through a single servlet, causing
> issues with leveraging J2EE declarative security (which is effectively
> folder based).

Correct. I think there may be a solution to this in the future, although
I'm not sure what it might be yet. One possibility would be to make the
underlying servlet so that you can attach it to multiple folders.

In the meantime, you can manage security programmatically. The Library
example shows how to make pages authenticated and secure by using Java
inheritance. I think this may ultimately be a better approach to the
problem anyway...

> I know it isn't fair to compare his early code to Tapestry 3.1, which
> has barely been started yet. But the features we're looking forward to
> in 3.1 are pretty important:
>
> - Portlet support

Agree.

> - Persistent page state as query parameters and/or HTTP cookies (as well as traditional HttpSession)

Disagree. Form cookies are supported in Wicket (if you use them
explicitly). However, transparently storing page state in this way
is explicitly not a goal of the Wicket framework since it increases
complexity and the tendency of programmers to create security bugs.
I thought about this for a long time and decided I'd prefer a framework
that is safe by default and where you have to make very explicit
decisions to make usage of it unsafe.

> - Prettier URLs

Prettier URLs are already available for external pages that need to be
bookmarked. Although it might be nice in the future to come up with a
way to present prettier URLs to users, I think the current URLs are good
enough for 1.0. A scheme can easily be added in the future.

I also think there is a good argument for adding obfuscated URLs in the
future for people with extreme security issues to solve (i.e., NO state
in the client). It would be very easy in the future to guarantee this
with Wicket since it already ensures that all the state is on the server.

> - Significantly simplified XML

Disagree. There is no plan to make Wicket XML configured.

> - Extreme extensibility via integration with HiveMind

> Wicket looks like a good piece of engineering. It's exteremely hard to
> gain market share in this overcrowded space. Competition is always
> good and I'm sure we'll cherrypick each other's best ideas!

Yup! Happy trails, Howard!