Seam vs Spring Web Flow – vs Wicket
In the fifth part of this four part series, I decided to give a non-conversational framework a try and implemented the same application with Wicket which is a semi-stateless framework.
(update : If you have already read the previous version only chapter 5 is new and has the Wicket example and final comparison.)
Enjoy,
18 thoughts on “Seam vs Spring Web Flow – vs Wicket”
Comments are closed.
1. it’s a Filter, not a Servlet.
2. Although with Wicket you do have to write a little more of html, css, and javascript (mostly because it uses pure HTML, and all styling is your responsibility), comparing it to assembly isn’t really fair, the gap on abstraction isn’t that large.
3. Astronaut Architects will do the same mess in any technology. I’ve already seen two or three in-house frameworks on top of Seam.
4. Spaghetti code also happens (much more frequently, I guess) in JSF code, but instead of happening in Java code (which has a fair amount of tooling on organizing, navigating and refactoring), it happens in XML code (.xhtml, .page.xml, etc.), which has very poor tooling, even with the latest plugins installed. SWF, at least, encourage structure – flows are first-class citizens, and defined in units, with a start and an end. With Seam, on the other hand, conversations are defined in a completely ad-hoc manner.
5. Be clear, Seam and SWF also abuse the session, much, much more than Wicket. Where do you think the ‘conversation’ is kept between requests? Again, in SWF you at least have to explicitly declare that you want this behavior, while in Seam all bad practices are enabled by default.
That aside, it was a very fair comparison, and if one reads the article and ignore the last paragraphs, its hard not to think of Wicket as a much simpler alternative to ‘stateful’ frameworks 🙂
Hi Tetsuo,
1) Yes, you are correct.
2) It is not only the view side that requires more coding, you need to manually add each component to the view and hook them up to the source data.
3) If you have used Seam and or SWF, you can see how there is a fairly well defined avenue to take for most (CRUD) operations. In fact, for basic CRUD, I do very little coding whatsoever. My point was that any discussion is at a much higher level with Seam & SWF than with Wicket where you have to tackle issues such as top level versus anonymous classes and whether to attach models to panels or top level forms or pages etc..There needs to be a discussion of style and then there needs to be monitoring to ensure everyone is using that style.
4) SWF does a nice job of compartmentalizing the flows, just as Seam does so for pageflows. Seam conversations are ad-hoc and that causes a lot of problems for some people. Again though, the spaghetti-ness is at a higher level than with Wicket. Also JBoss Dev Tools has some good refactoring for JSF pages although personally, I never found JSF that awful to use.
5) I did make this comment about session abuse by Seam and SWF and commended the fact that with Wicket, you can have more control over it (i.e. Detachable models). However Seam and SWF can both make improvements on their side regarding session abuse and the user gets the benefits when they upgrade. This is the benefit of a managed environment. Granted, with good developers, you never have to worry about session management.
I think Wicket is totally and absolutely simpler that the other frameworks. It also has less features, but the ease with which you can code around those missing features is a strength for Wicket. (Just like assembly language)
My criticism for Wicket is that you need to be a strong Java and OO developer. I have trained people on Seam and they can see code I’ve written, they understand it somewhat and copy it and produce something. I can probably do the same with SWF. I can’t envision walking someone who isn’t a great Java coder through a Wicket app, and then having the confidence to go write code on their own without producing crap.
However, in the right hands, Wicket is an awesome lightweight framework which can let you build great, well structured and organized applications. I just question what gets produced in the wrong hands and whether I have to maintain it! 😉
“…the view and hook them up to the source data. ” I’ve used Spring MVC heavily in projects and have a look at Wicket recently. I found that from time to time I have to prepare the data from the domain object model in such a manner that the “view” (mostly jsp) can use them comfortably. I usually assign these responsibilities to the “controllers”. From time to time I have to create intermediate objects to make the preparation. In Wicket they recognize such “intermediate objects” as “model”. So unless that is a trivial page view, “hook them up to the source data” is not an extra process, but an existing one that has to be addressed anyway.
In all cases, you have to fetch the data which in JSF terms, means assigning it a name which makes it available to the view as a named EL expression. You have to put a line of code in the view HTML or JSF page to place the component, and in Wicket you assign it an Id. In JSF, you could/should assign it an id, but you could just bind it to the EL variable. In Wicket, you then have to declare the component in the java page and add it to the page which is an extra step of approximately one line per visual component. If you need to use a DTO between your domain model and your view, then chances are that this stage is equal among all frameworks, although I haven’t had any problems binding my view to my domain model so far.
Hi Andy,
one aspect was not mentioned in your article: testability.
It is hard to unit-test JSF-based frameworks because they have to be executed in a container. Wicket was however designed for testability and can be used in development team applying techniques like TDD.
Hi Andy,
Really nice article. I totally agree that Wicket in wrong hands can have hazardous results. Even an average developer using Wicket needs to have a good understanding of its session management mechanism. Session bloat is common problem with Wicket and quicly runs out of hands.
The best thing about Wicket is, its extensible and a person with good understanding of Wicket can build robust AJAX enabled applications.
Shirish, yes, I think Wicket is very powerful, but makes it easy to go astray.
Daniel, I’m not a big fan of that kind of interface testing so I didn’t really cover it. However, Seam has a test template you can use to test JSF/Seam applications which handles the container for you. The back end stuff (Daos etc..) in Spring can be tested outside the container easily in a POJO world.
Appreciate the effort you put in to this detailed article. Some responses:
I ported the Seam Hotel Booking application (which uses conversations) to Wicket and did a head-to-head comparison with code – here: Seam / JSF vs Wicket: performance comparison
So I don’t think it is correct to say that Wicket doesn’t provide conversational and flow functionality. This article explains it best: On Page Navigation
If your argument is that sphagetti code is a bigger risk with Wicket, I disagree, along with commenter #1. I have worked with a large project team using Seam and I recently posted some of my observations here:
Ans: Are there any disadvantages to SEAM?
Please refer the performance / memory comparison of Seam with Wicket I linked to.
Wicket 1.4.0 just became GA and the changes from 1.3 are very few, see this migration guide. You can optionally start making use of generified models of course. The best part is when you update the libraries, your IDE will helpfully tell you which parts of your code don’t compile. Of course this “low level”-ness could be what prompted you to label Wicket as like “assembler”. Heh.
You also should have mentioned that Seam 3 is on the horizon, which has to conform to 2 very new specifications a) JSF 2 and b) WebBeans. Sounds like a lot of changes from Seam 2 to me.
On the surface, this does indeed appear to be a Good Thing. However I’m not really convinced, this is my side of the argument:
– adds to the learning curve of Seam
– Seam has to now track and update integration points with multiple third-party libraries which are moving targets.
– the integration (which IMHO is nothing but glorified “wrappers” will always be a step behind the latest versions available. For example the project I was in had to use jBPM directly because of the need to use new features not supported by the version supported by Seam
– if you have resources already experienced in iText (PDF) or POI (Excel) for example, their skills cannot be leveraged if you choose to use the Seam integration
– IMHO the Seam integration would work for the simple cases, but once things become complicated, you start hitting walls with the “wrappers” and you either have to put effort into workarounds or redo everything from scratch
Hi Peter,
I have previously read your Seam / JSF posts and found them interesting reading, I know it takes a lot of work to put them together!. The page navigation article describes my stance on Wicket pretty well. You can build any kind of navigation or conversation management framework you want in Wicket which gives you great flexibility, but at the end of the day, you still need to build /test/maintain it yourself. With Seam and SWF, this is out of the box at the expense of flexibility. This is why I say Wicket doesn’t come with those functions, but it does give you a very easy way to write your own. (This is mainly why I think of Wicket as Assembler),
With the Wicket/Seam Session performance issues, yes, Seam can be session heavy, but at the same time all that session state comes with a feature, It’s not just there because someone was sloppy, it is there to support a feature in the framework that Wicket doesn’t have. It’s like saying a speedboat is better because it can go faster than an aircraft carrier. When you start adding those features in Wicket, you will no doubt start accruing session issues. Again though, Wicket gives you finer tuning, but Seam/SWF are managed frameworks which means developers could work on the memory problems and reduce the overhead just by upgrading.
I found we have very little spaghetti code with Seam, we mostly use the entity and entity query beans from the Seam framework. Our actual code was quite minimal, just a few ajax event handlers etc. I personally, don’t mind JSF, especially with JBoss tools which provides auto completion and refactoring from java to JSF pages. OTOH Wicket seems to (optionally)rely on a lot of anonymous classes which apart from cluttering code up can be a challenge for new developers and offers all sorts of ‘opportunities’ for different developers to write code in different styles. I’m sure we won’t agree on that so we’ll have to put it down to personal preference and style.
In the Stack Overflow article, most of those disadvantages relate to the fact that Seam can be troublesome if you are not using the technologies it was designed for. In general, fair point, but if you are using JSF, Hibernate (EJB doesn’t even matter) then Seam is a great framework to support those choices. JBoss Tools now supports Maven too I believe, but I haven’t checked it out so I don’t know how far their maven support goes with Seam.
I started looking at upgrading to Wicket 1.4 with a mini-project I had, not too many problems, the biggest problem for me now is my IDE complains when everything doesn’t have a generic type assigned. New projects with generic Wicket should be a delight. Seam 3 will be interesting since it will be backed by Web Beans and I think upgrading Wicket will be much easier than a Seam upgrade.
On the topic of the Pdf, Excel plugins etc.. I mostly disagree there. It’s not a case of leveraging the iText, POI skills to use Pdf and Excel in applications, you don’t need to, you just leverage your existing skills in Seam. iText is writing documents in code while the Seam wrappers let you write documents in an XHTML/ JSF syntax, and leverage the use of facelets to boot. It really is an indication of the strengths of the JSF architecture with a pluggable view framework that can re-use technologies so I can re-use my JSF view know-how with my Seam backing beans that I’ve already created.
Overall, I do like Wicket and I find it unfortunate that it hasn’t received the attention it should although the users it does have are very dedicated and for good reason. I think Wicket is more my level in terms of being able to build a custom mini framework on top of Wicket. This is also why I think of it as assembly language which I also enjoy using. Clay lets you build any shape, Lego only lets you build rectangular angled shapes.
FWIW, Mojarra 1.2 *does* run on GAE. Ryan Lubke, with the testing help of some of our users, did the leg work to get that working.
IMO the key strength of Wicket is that it specifically does not aim to provide you a bunch of complex components that you can use out of the box. The problem with such things is that they never quite do what you want. Instead it provides you with extremely powerful abstractions and building blocks for you to craft reusable components yourself.
If you’re no good at writing code and want to play with lego instead, pick something else. If you want a powerful abstraction that leaks remarkably little that lets you easily build truly reusable components across your company, Wicket is for you.
So in that regard, Wicket isn’t really like assembler at all. It’s much more like Java – the basics are simple and powerful, and it has a good set of comprehensive abstractions just like the JRE does.
Seam is more like C++, in that you need to manage things much more and work harder to make things work, err, seamlessly (ho ho).
JSF is much more like Delphi. It comes with a bunch of components that promise the world but don’t quite do what you want, and even has a healthy set of third-party components you can buy that promise to make your life easy, but still don’t do what you want. So you end up implementing your own and hating every minute of it. 😉
Hi Jason, that’s great news, I was basing my statements on the original Will it play in App Engine list which listed the technologies that will and won’t run in the google app engine. It seems that list has been updated to indicate that JSF will run with a tweak or two. Nice.
Alastair, for the most part I agree, except that sometimes that Lego does meet your needs and you get a lot of productivity out of it and it makes it easier to train people without having to get into some of the more complex webby stuff. Wicket also abstracts the HTTP pieces, but as you say, you need to be a good coder and for some people, I think it’s easier to teach them to use Lego than to be a good Java coder.
I do wish Wicket were more popular though, certainly in the jobs market. I prefer component frameworks and only JSF has really made a dent in the market. Beyond that it is mostly Struts and Spring MVC.
Yeah, I remember the pain of Delphi components and trying to get 3rd party components to do what I needed.
Hi Andy,
Is the complete source code for these projects posted some where? I think it would make for a useful learning tutorial – at least for me. I’ll try going through the steps as described anyway.
Regards,
Scott Langley
Hi Scott,
I have thought about including the source and have no problems doing so. I am just not sure of the best way to release it in a way that is usable. If I release it as-is, chances are that it can’t be run without an appropriate IDE and having the appropriate jars included. Of course, there is still plenty of value in just looking at the source code, most of which is already in the articles.
I’ll try and take another look at it soon.
Cheers,
Andy Gibson
Hi Andy,
thanks a lot for this thorough and practical comparison. Any news from source code? this would help me so much, even if it does’nt work directly 🙂
thanks.
You know, I keep looking at trying to get the source for it all out of the door, but every time I look at it, I start wondering about the best way to deal with it given that none of it is in maven and they have dependencies required to run. I think I may have to just release the source and put it out there for people to peruse. I’m not sure how much it would help since just about every piece of source code is in the final articles.
I’m trying to get another open source project released, but I’ll try and squeeze it in there, even if it is just the code source with no easy way to build and run it.
Cheers,
Andy
Hi Andy,
we are discussing on which framework to use 1. Spring webflow 2. JBPM (drools, jbpm 5). I have experience in implementing projects using spring webflow but not JBPM. The project it self uses complex user interactions as well as SOAP calls and Quartz jobs to perform certain tasks. Please help in understanding in knowing technologies that can be best used for this project.
Thanks
Sree