In February I evaluated Apache Wicket 1.5. I considered it for my Startup projects. My goals were to program within a easy to use and easy to learn framework. Combined with Apache Cayenne it should give me the chance to ramp up my Application in short time. I worked with it in March, then I did a Consulting job, and came back to it in April.
After my first excitement, I experienced several things which made me think twice about Wicket. Confused I started with Struts 2 and tried to port what I had as quickly as I could. Finally I decided to go with Struts 2 and leave Wicket. And here are my reasons. Apache Wicket is a very nice idea:
- don’t use HTML or JavaScript, everything is wrapped in Java Components. This makes you very quick if you don’t have a clue about HTML/JS/CSS.
- You have a compiler which checks a lots of the code you write (not all, though).
- You can use tons of freely available Components from anywhere.
- Community are nice people. They worship Wicket in the way some people worship their Macs
- Wicket is under constant development
- First pages are created pretty quickly and you can use it straight forward within a few days
But Wicket has drawbacks:
- Wickets internals are complex. I am not really a Java noob, but understanding what’s happening is not trivial.
- If you leave the standard path (which is the case in every application), there is no easy life for you
- You need to understand how Wicket works, when it comes to features which are not prepared. For example Authentication, Configuration, own Components
- You are forced to wrap your JavaScript in Java-Components. But why? Not everything needs to be a reusable components. This wastes my time. You cannot easily return a JSON String if you want to do it. I gave up at this point and downloaded Struts.
- It’s non-trivial to wrap JavaScript in Java-Components. Sometimes it simply does not work b/c of the JavaScript.
- You need to know HTML/JavaScript if you wrap something. And yes, you’ll need to wrap something. Except you have a dedicated guy in your team doing all the wrappings for you. But then he must know.
- Docs are usually outdated. They are not versioned. And they are incomplete. To be honest, documentation is one of the most worse things in Wicket. You need to read the JavaDocs and ask the mailinglists, if you need to do something special (which is very often the case)
- When you move the HTML/JavaScript complexity to Wicket, it will not disappear. It’s somewhere else and you have to deal with a more complex Java-Framework
- It seems people don’t care to much about backwards compatibility. Docs are often outdated and tipps from internet do very often not apply anymore. Methods disappear without warning.
- Wicket is like Swing. Swing is not to bad, but sometimes it is horrible.
- Sourcecode does not follow Sun Java Code Conventions.
Struts 2 on the other side helped me to port my app, which took to long to develop in Wicket, in only a few days.
- Struts is transparent: you can understand every component you use
- Struts is straightforward, if you know the underlying mechanisms
- It is doing everything as simple as possible. There is no magic. It is not hiding any complexity.
- Actions can be tested with JUnit (Wicket is testable too, even on a higher View-Level)
- Enough plugins around, for much cases. If it is not matching your needs, write your own. This is much more straightforward then writing Wicket components.
- Struts has been developed long time and there are no big surprises or huge code changes
- “The sky is your limit” - as I read somewhere in the docs. That’s true. You can do whatever you imagine.
- The programming model is more to my taste: less Swing, easier MVC. No Listeners or Observers. This makes everything boring, but understandable and readable.
Of course Struts 2 has downsides too, but I can live really good with them:
- You need to know Javascript/HTML/CSS.
- You should know about Spring and Dependency Injection. This really will help you.
- You will get a lots of Actions. This leads to huge mapping files (which you can divide - but still a lot of XML).
- The compiler is not a big help. It just helps you on Action level. But you need to work on the view, map requests in XML and so on. In other terms: some portions of your work cannot be compiled, you’ll need to read carefully and organize well.
After all you could say, I favor Struts because I can do what I want without caring about internals. I have already learned about all the technologies I need to do my job. Therefore I could use it straightaway. Meanwhile I become pretty quick with it.
From feature level both frameworks are similar. Localization is so similiar, I even didn’t have to rethink. Both Frameworks use or can use Spring. In Wickets case it’s optional, but I recommend to use it - I really think there is no way to avoid it.
The most important benefit of Wicket is, if you don’t have a clue about Web development and have no special Requirements. If you can accept the restriction to use the ready Components, you might want to give it a go. In my case i didn’t want to care about the framework - I want to develop my Application quickly. I had to much things I could not understand in Wicket. Struts isn’t limiting me and I can understand everything.
Conclusion: I use Wicket only if I am forced to do so. For rapid prototyping I can use scripting languages. For real Applications I will use Struts. At the moment I do not see anything Wicket would give me in addition.
My Wicket adventures end here. I am bit disappointed after the big hype around the framework. Probably I didn’t understand something, but even then it’s a fail in the documentation. Probably it simply was not my taste. However, back to daily business and some Struts / Cayenne… and JavaScript.