{"id":871,"date":"2012-01-02T10:22:00","date_gmt":"2012-01-02T10:22:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/zk-web-framework-thoughts.html"},"modified":"2012-10-21T22:52:44","modified_gmt":"2012-10-21T22:52:44","slug":"zk-web-framework-thoughts","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2012\/01\/zk-web-framework-thoughts.html","title":{"rendered":"ZK Web Framework Thoughts"},"content":{"rendered":"
I\u2019ve been asked several times to present some of my opinions about ZK<\/a>. So, based of my experience of 4 years as a ZK user, here\u2019s some thoughts:<\/p>\n

Overall developer experience, the community and documentation<\/strong><\/span><\/p>\n

\u201cIt just works\u201d<\/strong><\/p>\n

Most of the stuff that ZK offers works very well, and the functionality is usually very intuitive to use if you have developed any desktop Java applications before. In 2007 I did a comparison of RIA technologies that included Echo2, ZK, GWT, OpenLaszlo and Flex. Echo2 and OpenLaszlo felt incomplete and buggy and didn\u2019t seem to have proper Maven artifacts anywhere. GWT seemed more of a technical experiment than a good platform to build on. Flex was dropped because some important Maven artifacts were missing and Flash was an unrealistic requirement for the application. On the other hand, ZK felt the most \u201cnatural\u201d and I was able to quickly get productive with it. During my 4 year long journey with ZK, I\u2019ve gotten plenty of those \u201cwow\u201d moments when I\u2019ve learned more and more of ZK and improved my architectural understanding of the framework.<\/p>\n

Nowadays I\u2019ve got a pretty good understanding of what in ZK works, what doesn\u2019t, and what has problems and what doesn\u2019t. But still, after gaining all this good and bad insight, I consider ZK to be a very impressive product out of the box. The downside of this is of course the fact that the framework hides a lot of things from newcomers in order to be easy to use, and some of these things will bite you later on<\/i>, especially if your application has lots of users.<\/p>\n

It\u2019s very, very, very flexible<\/strong><\/p>\n

ZK is very flexible and has plenty of integrations. Do you want use declarative markup to build component trees? Use ZUL files. Do you want to stick to plain Java? Use richlets. You can also integrate JSP, JSF, Spring, and use plenty of languages in zscript. The core framework is also pretty flexible and you can override a lot of stuff if you run into problems.<\/p>\n

The downside is that there are very many ways of doing things correctly, and even more ways of screwing up. Flexibility itself is not a negative point, but I think that the ZK documentation doesn\u2019t guide users enough towards the best practices of ZK. What are the best practices anyway? Many tutorials use zscript, but the docs also recommend to avoid it due to performance reasons.<\/p>\n

The forum is quite active<\/strong><\/p>\n

I think that the ZK forum is one of the best places to learn about ZK. It\u2019s pretty active and the threads vary from beginner level to deep technical stuff. I read the forums myself almost every day and sometimes help people with their problems. There\u2019s one thing that troubles me a bit: the English language in the forums isn\u2019t usually very good and people often ask too broad questions. I know, it\u2019s not fair to criticize the writings of non-native English speakers, especially when I\u2019m not a native speaker myself. Regardless, I think that such a barrier exists. For example, take 5 random threads from the ZK forum and Spring Web forum.<\/p>\n

The threads in the Spring forums are typically more detailed and focused instead of \u201cI\u2019m a newbie and I need to create application x with tons of features, please tell me how to do everything<\/i>\u201d-type threads you see in the ZK forums and people clearly spend some time formulating good and detailed questions. You\u2019ll see that you have to spend a bit more time in the ZK forum in order to understand the threads. It\u2019s not anybody\u2019s fault or anything, nor a bad thing, this is just an observation. Unfortunately for me it means that some of my limited time I have for the ZK community is spent just trying to understand what people are saying. Usually I answer a thread only when I know the answer right away, or if the thread concerns some deep technical stuff.

<\/div> <\/div><\/p>\n

There\u2019s plenty of documentation<\/strong><\/p>\n

In the past the ZK documentation was scattered, out of date and some of the more important stuff was completely missing. In the recent years the docs have improved a lot, and there\u2019s now separate comprehensive references for ZK configuration<\/a>, client-side ZK<\/a>, and styling<\/a>. I think the documentation is today very good, and most basic questions can be easily answered by reading the docs.<\/p>\n

As I mentioned above, ZK has a tendency to \u201cjust work\u201d. The overall technical quality is impressive and on par with most Java web frameworks, but I believe there are some parts of ZK that are less impressive.<\/p>\n

Stuck on Java 1.4<\/strong><\/span><\/p>\n

ZK is built with Java 1.4, which greatly limits the flexibility of their API and internal code quality<\/p>\n

Negative effects on ZK internal code<\/strong><\/p>\n