Hello,

We have stateful, desktop-like Web applications based on Struts 1.x. We want
to migrate them to a modern Java Web framework so we are trying to choose
what framework to use. The decision will be left up to myself and another
colleague with buy-in from other key people.

The other colleague wants to use Spring MVC, which she just received
training on from SpringSource. I want to use a component-based framework
like Wicket. I think Wicket looks great, so I have been telling her that I
think we should consider using it instead of Spring MVC. I think it is a
better fit for the type of applications we produce.

My colleague emailed the instructor from SpringSource and asked what he
thought of us migrating to Wicket instead of Spring MVC. His response is
below with my comments inlined. I would appreciate any convincing comments
from Wicket experts.

Thanks,
Richard Allen

Rich,

Some background on what I am forwarding along...

During last week's Spring Rich Client class I took full advantage of the
fact I had unlimited access to a SpringSource consultant/instructor.

When he asked people why they were there, I brought up that we were
transitioning from Struts 1.X to something else, and the likely
candidates were Spring MVC and Wicket.

Many of my questions to him over the course of the 4 days were focused
on that particular topic.

And when he offered up his email address for contacts after the
class, I wrote it down and got back in touch with him this week (getting
our money's worth out of the face time, I like to think!) with some
well-deserved adulation for the course, some questions about the Spring
3.0 release schedule and finally, a summary of the Spring MVC vs. Wicket
decision we face, trying to synthesize what I took away from the class.

***

Specifically, in my email, I asked the question that you, an
experienced web developer, posed to me about moving our Struts app to
another MVC oriented framework (Spring MVC) vs. moving to a component
framework (Wicket).  What I heard you say in so many words earlier this
week, was:

    "Why switch to something that is a little better than Struts 1, such
as Spring MVC,  instead of moving to something altogether better like
Wicket?"

And that is indeed a good question that cuts to the heart of the matter
we must decide going forward.

We have a lot invested in MVC technology right now, and our developers
understand this approach. My instincts and experience on other
migrations say that a transition from Struts to Spring MVC will be an
easier migration than a movement to a different approach than Wicket.

 Wicket *is* an MVC framework, like Java Swing is an MVC framework. I would
argue that Wicket is *more* of an MVC framework in the classical sense than
Struts or Spring MVC. There is no doubt that Wicket absolutely does a better
job of separation of concerns (one of the key philosophies behind MVC) than
any JSP/Velocity/Freemarker based framework. If developers are comfortable
in Java and OO (ours should be), and if they have ever done any Java Swing
development (many of us have because we have Swing applications), then
Wicket will feel natural. It is an easy transition. I do not believe that
getting our developers up to speed on Wicket will be as difficult as you
think. I believe, as a whole, Wicket is less complicated than Struts or
Spring MVC. If you have ever tried it, you would know what I mean. You
should read this page: http://wicket.apache.org/introduction.html.

And besides, Spring MVC is significantly different than Struts 1.x -- so
much so that I think the transition from Struts 1.x to Spring will be nearly
as tough. The only thing you gain is the overall framework concept:
action-based. Once the developers understand the component-based concept
(which is not hard to grasp -- think Java Swing), than you no longer get an
experience advantage by using Spring MVC.

But as you correctly pointed out, it's not just the ease of migration
that drives our choice of technologies (again I'm paraphrasing what I
heard you say)

    "If you end up with a product that is easier to maintain and grow in
the long haul, it's worth it to pay the upfront cost in the migration
process to get there."

Absolutely true - we need to focus on the long term, not the short term,
so that the redesigned framework that results will be as solid as
the framework you and the original team put together based on Struts 1
however many years ago that was.

But when I think about long term solutions, my sense is that Spring MVC
addresses the shortfalls in the Struts approach head on. Plus, the
overall integration of Spring MVC with other aspects of the Spring
Framework offers us still more options down the road.

 I do agree that Spring MVC addresses the shortfalls in the Struts approach.
However, Spring MVC does not address the short-falls in the action-based
approach for a stateful, dynamic, desktop-like Web *application*. I believe
that is one reason why Sun developed JSF.

I'm still studying Spring MVC, so the jury is out, but as of yet I do not
see how Spring MVC's integration with Spring Core provides you any more
value than Wicket's integration with Spring Core.

Therefore, a migration to Spring MVC would not be a solution that is
just a little bit better, but a genuinely good solution which can stand
on its own merits as a robust and maintainable approach.

 True, but I think there are better solutions for our problem.

***

So here's what he had to say about Spring MVC vs. Wicket choice. See
what you think - his arguments make sense to me.

Note his comments about JSPs...is something like Freemarker a
replacement technology for JSPs we should consider in this migration?

 Freemarker and Velocity do some good in improving over JSP, and we could
readily use them now with Struts 1.x. However, from what I have seen, they
are not as clean/easy-to-maintain a solution as Wicket or Tapestry for
templating.

   With regards to Spring MVC and Wicket, firstly as you rightly pointed
out, to say that Spring MVC is slightly better than Struts is incorrect.
It is more correct to say Spring MVC was built on the same philosophy
but otherwise sits on a much stronger architectural foundation. This is
what makes it easiest to understand for Struts developers while at the
same time being very versatile. And by the way this philosophy, the
"request-driven approach" is not about to go defunct as Struts did. The
stateless approach is one of the 4 REST principles.

 The "request-driven approach" is certainly a good solution for many
applications. I just don't think it is the correct solution for ours.

 Consider how the Spring MVC DispatcherServlet can be used in all these
scenarios: HTML browser requests, remoting requests (HttpInvoker,
Burlap), Web Service requests (SOAP). Additionally it serves as a
foundation of both request-driven (Spring MVC) and stateful JSF requests
(Spring Faces). On the view side unlike Struts it was built to support
many technologies. Indeed JSP's are not the best markup and you will
read that a lot in Wicket marketing. If that is a main concern suggest
using Freemarker as templating technology.  It is supported in Spring
MVC and so is Velocity. Another suggestion is jspx.

 I went actively looking for a better solution to JSP several years ago. I
didn't happen upon Wicket until about 7 months ago. So it's not "Wicket
marketing" that has driven me to the conclusion that JSP is not the best
solution. It's having developed in JSP for several years that lead me to
that conclusion.

In regards to jspx, the examples I have seen of writing JSP in XML, and the
examples that I wrote myself, created very ugly code.

 This flexibility has found Spring MVC well suited for both Ajax
interactions and for REST applications. Version 3.0 of Spring MVC will
have slight enhancements that make it a top choice. I'm not sure how
Wicket competes here. I suspect it doesn't quite because it is much more
stateful.

 It is certainly correct that Wicket is a stateful framework, but so are *
our* applications. We make significant use of server-side state
(HttpSession), and transitioning to a full REST application would be a large
transition. If you know REST, you know that there is no server-side state,
but instead the state must be maintained via URL parameters. I think the
concept of REST is great for certain scenarios, but I do not think it is
fully appropriate for a desktop-like Web application. For example, in our
applications, REST would be useful for providing bookmarkable URLs to GET
documents. And that is elegantly supported by Wicket:
http://stuq.nl/weblog/2008-06-20/create-restful-urls-with-wicket

 For Ajax, there is now Spring JavaScript as you know and Spring will
continue to expand its support in this area integrating more of Dojo and
taking the best-of-breed approach. I know that you're on Ext right now
but Wicket custom approach isn't going to help with that either.

 Wicket has great support for integrating other JavaScript libraries. There
is already integration with YUI, Dojo, Prototype, Scriptaculous, and some
other libraries (see
http://wicketstuff.org/confluence/display/STUFFWIKI/Wiki). From what I have
read, the next major version of Wicket will use YUI internally.

 In the end customers we talk to have chosen Spring MVC because it has a
much larger community and this is something that is very important if
you put in the context of migrating from one framework to another.

 I don't know how big the Spring MVC community is if you separate out those
that just use Spring Core and not Spring web features. I do know that Wicket
has a significant and very active community. Just post a question on the
mailing list and see how fast you get a response. Wicket is a top-level
Apache project and is not going to disappear. Besides, if we were solely
judging by user base, then JSF would clearly be the winner.

 The burden is on those proposing Wicket  to demonstrate it should be chosen
over Spring MVC that is a more natural fit on *multiple* levels.

Reply via email to