Apache Wicket Initial Thoughts

So I looked into Apache Wicket last week. Here are my views on the project. First the good:

  • It separates the controller and the view cleanly
  • It is easy to pick up
  • It enables reusable components easier than other frameworks
  • It does not break html viewers and designers during development
  • You can split the work cleanly between designer and programmer
  • It is an Apache project (bias toward Apache projects here)
  • It is a huge step up from jsp/adf/tags/…. j2ee’s way of doing web development

Next the Bad…

  • Actions need to go to the server to be processed
  • The page needs to reload often (can be worked around with ajax)

Basically wicket has a lot going for it. It really is a fantastic alternative to the classic fat server thin client solutions. Although… if you are looking for a zippy web client that can do funky transforms, make use of the html canvas elements, do clean popup’s and generally have more control of the front-end… then you will primarily be using javascript. Consumers are starting to expect less page refreshes from their applications, such as gmail.

So yes, you can look into wicket for the server side of things to separate the logic from the view, but if you going to have a very powerful view, then most of your calls will be ajax’d with jQuery or something of the sort. Which means that you will be calling restful type services and therefore not really be making use of Wicket. In such a situation you would be looking for a way to create fast reusable services (I still find straight vanilla servlets do the job effectively, sending on data in JSON format).

However, if you are in the position where you have high security and most of the work needs to be hidden and done on the server, I would highly recommend taking a knock on the UI and use wicket instead of something like the j2ee front-end solutions, j2ee for the back-end sure, but not the front-end. Yes, you could use the restful approach described above, but then your components are written in JavaScript, IMHO a really crappy language, I like flexibility, but JavaScript gives it at too much of an expense for me.

Lastly, you could do a combination of the two, but it would over complicate things and your primary goal is to keep things simple and fewer technologies someone needs to learn to work on your project the better. It could work nicely if your team know both technologies, as wicket really is easy to pick up. You would have components that are driven by wicket and made pretty with JavaScript. This is definitely the only way the two should be combined, and coming from a JavaScript viewpoint, you will want to do a lot of the control and ajax in the JavaScript effectively voiding wicket. And too much reliance on wicket will give you not as pretty, usable components. The line would be a difficult one to draw.

On the side though, I did find that using the jRebel plugin for IntelliJ really made this development a breeze. Highly recommended! Next I will be looking into HaXe for JavaScript generation because I really do not like the current way IDE’s handle JavaScript in general, even though it is really respectable language.