I’ve been developing web applications for the past few years. Recently, we evaluated many of the web frameworks out there to select one for the next major release of our product.
Wicket was quickly dropped from the list. It’s a nice framework but it lacks one important feature: A library of reusable, cross browser components. Yeah, there are a couple but they are all very basic and building complex UIs with Wicket is done in HTML and that’s just painful.
Roo is too slow and immature and suffers from the same problems as Wicket. Maintaining cross-browser compatibility for a complex web application is something that a small team of developers can’t do anymore today.
GWT was dropped because Vaadin is based on it.
That left Vaadin and ZK.
ZK has a big set of well designed components with a huge documentation how to tweak them. The docs explain in detail how the components are built from HTML elements, which CSS styles are used and how you can override them. There is even a visual CSS editor that helps doing this.
When working with ZK, you often run into situations where something doesn’t work but so far, I’ve found a good solution within a short time. This might also be possible with Vaadin but it didn’t happen for me.
There are a lot of powerful layouts to arrange your UIs. You can cleanly mix ZUL (the UI descriptions) with Java code to get the best from both worlds: A clean UI description and compact code to attach listeners, publish events and connect components.
Also, ZK hides the request cycle. This is one of the biggest source of problems with developers. Yeah, the request/response cycle makes it easier to write web browsers and server frameworks but it’s a major pain for application developers. With ZK, you’re writing code that looks like a desktop application. It’s a bit like GWT in this respect but GWT feels … “proprietary”. In ZK, a lot of the API is public. In GWT, a lot of the API is hidden away in final static factory methods buried in calls between 50 classes.
ZK does have its share of problems, too. Testing is a weak point. Selenium probably works well enough for mouse-driven apps but if you have components which can be controlled by keyboard alone, Selenium doesn’t cut.
The documentation on the web site could be better; for beginners, it’s especially confusing that the documentation for ZK3 and ZK5 is hard to tell apart.
But all in all, I’ve been faster to solve any problem I’ve had so far with ZK than with any other web framework.