ZK

27. October, 2011

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.

We looked at Wicket, GWT, Vaadin, ZK, Roo and a couple of others.

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.

Vaadin looks good, it’s free and based on GWT which is backed by Google. The main issue with Vaadin is that the technology is … unapproachable. There is a decent set of components but tweaking them is a pain. Plus the Java -> JavaScript compilation takes a lot of time. It’s better than most other frameworks but doesn’t compare to ZK.

Why?

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.

You can use JavaScript but the JavaScript isn’t hidden in pseudo-native functions. That ZK5 is based on jQuery is an additional bonus if you really need to get your hands dirty.

The demo page contains lots of useful examples (instead of simply listing the available components like many other frameworks). There is a sandbox where you can modify small ZK projects online.

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.

Well done.


Spring Roo again

3. November, 2010

A while ago, I tried Spring Roo — without much success. One of the main obstacles was the fact that most of the dependencies come from a special, internal repository and not from Maven Central. Which is odd. It’s OSS after all, so why do I need a special repository? Is it too much work for the Roo people to push their changes to Maven Central?

Whatever. A few days ago, Spring Roo 1.1 was released. I downloaded it and followed the tutorial.

Everything worked fine (good work, guys!) until I tried to run the tests.¬† Again, I had to fight with Nexus to fix all the missing dependencies. Seems like the problem with the dependencies is still there. Bug #ROO-1111 just improved the situation by listing the necessary repositories so you don’t have to figure them out yourself. But if you’re behind a corporate Maven proxy, you’re still doomed.

Okay. All dependencies are there and … 9 generated tests work. What worries me are two things:

  1. Compiling a project with a single class and field takes two minutes.
  2. This simple project needs 976KB sources.

I know this is all generated code but in the end, I will still have to wade through all this to get to the place where I have to make my changes. I prefer frameworks which take the ten lines from the tutorial and put them into a script where I can run them again and again. Generated code is not an issue as long as I don’t see it. Take Grails: It will add everything that you omit in the background. It’s still too slow for my liking but at least the source isn’t bloated with stuff that I don’t care about just yet.

Conclusion: Not quite there, yet.


Google Relaunches Instantiations Developer Tools

29. September, 2010
Google Web Toolkit

Image via Wikipedia

From the website:

In early August, Google acquired Instantiations, a company known for its focus on Eclipse Java developer tools, including GWT Designer. We’re happy to announce today that we’re relaunching the following former Instantiations products under the Google name and making them available to all developers at no charge:

  • GWT Designer
    Powerful Eclipse-based development tools that enable Java developers to quickly create Ajax user interfaces using Google Web Toolkit (GWT)
  • CodePro AnalytiX
    Comprehensive automated software code quality and security analysis tools to improve software quality, reliability, and maintainability
  • WindowBuilder Pro
    Java graphical user interface designer for Swing, SWT, GWT, RCP, and XWT UI frameworks
  • WindowTester Pro
    Test GUI interactions within Java client rich applications for the SWT and Swing UI frameworks

I played a bit with CodePro. The tools look promising even through there were some glitches, namely:

  1. The JUnit editor looks cool but the table with the current unit results often hangs.
  2. It was more complicated than I liked to generate test cases
  3. I couldn’t get the code coverage tool to work
  4. The dependency works but didn’t play with it long enough to say for sure how useful it is
  5. The code analysis shows a lot of numbers but the workflow is clumsy. For example, it says that something has a cyclomatic complexity of 16 but I couldn’t find out what and where.