Often people keep asking which path to follow regarding UI technologies. On the one hand, there are standards, such as JSF - and usually standards are something „long-lasting“, so if you decide to use a JSF implementation for your app you can be pretty sure that your application and the technology behind will survive the next few years. But „next few years...“ is a little bit weak, isn’t it? Basically we are talking about STANDARDS, so we should be able to expect survival of the technology for more than „few years...“. Just think about car manufacturing: certain screws are used in order to mount the wheels - and there are wrenches with standard sizes, exactly these standard sizes ensure that people still will be able to mount new tires to their Dodge Nitro or whatever twenty years later...

But regarding Software development we are far away from unmounting tires in twenty years. Of course Software development is a pretty fast changing environment, but even during short periods standards are adapted only very poorly. The problem: often these standards keep growing somewhere far away from real software development, in consequence the standard is far away from closing gaps between software development and industry. You still remember EJB?? EJB is as well one of these standards causing rather headache than adressing productive software development...and suddenly there was Spring, not a standard, but adopted in nearly any Java project!

The same refers to the UI layer and JSF. There are thousands of projects using JSF, but there are as well billions of developers complaining about JSF coding - especially in case JSF is used „from the scratch“ without any framework above implementing JSF. So if you are thinking about usage of JSF for a small project without any JSF implementation such as MyFaces or ICEFaces, forget about it, project cost will explode and after two weeks developers will start suggesting usage of plain HTML/JavaScript as they are so slow using JSF...

But even if you refer to a framework implementing JSF standard the question remains whether the framework is really best choice, just for the reason of adopting JSF. ICEFaces is one of the most spreaded JSF frameworks, on the other hand there is zk which is currently one of the most spreaded „Ajax-Non-JSF“ frameworks. If you compare these to frameworks regarding development speed and ramp up time, the question „ICEFaces or zk...?“ results in the question „Standard or Comfort...?“. The ICEFaces WYSIWIG editor is very poorly so usually developers end up in plain JSF tag coding. But aspects such as development speed and ramp up time are only minor aspects when deciding about UI technologies. It’s much more important to have a clue regarding scalability of technologies: will the ICEFaces application still perform when the app is deployed to a server? What about x concurrent users accessing the app? Recently we came across a nice paper comparing exactly these aspects, on the one hand ICEFaces, on the other zk;

we thought this is a pretty interesting comparison, reason enough to share within the richability info space.

Have fun reading this comparison (simply click the report below), maybe this report is a little help for your next UI technology choice in a project.

Tags: ICEFaces, zk, Ajax, JSF

Recently zk 3.6.0 has been released - there are couple of new features, for a detailed feature description refer to the feature list.

By the way, zk now provides a WYSIWIG editor, which can be easily installed as Eclipse plugin. So you can drag and drop your GUI without switching to your browser and hitting continously F5.



One more point we would like to mention: zk framework is growing rapidly! Some time has passed since we downloaded the last release, but as we took a quick look into the zk explorer we were really surprised about the number of new components. Check out the zk explorer it will give you a clue on what we are talking about...! We will keep focused closely on zk, as from our impression zk is (becoming) one of the leading enterprise Ajax frameworks. If you did not evaluate zk for now, you should give it a try in order to move away from clumsy JavaScript coding with simple Ajax frameworks...

Tags: Ajax, zk, UI choice

We were positively surprised to find a session about zk being offered in the conference schedule of the Ajax in Action this year. As there was a slight touch to "JS-only" frameworks within the conference, people were really happy to listen to Daniel Seiler from processwide who offered a nice session about zk. He demonstrated that Ajax frameworks can cover much more than the client part of an application, unfortunately there is no video cut for this session. But we decided to put his slides here, so anyone interested in giving a quick summary to his boss about when and why to use zk can refer to the slides...


Read full post...

Tags: zk, Ajax

Recently we came across an Ajax framework called „zk“; the most interesting point about this framework is the promise that developers would not have to deal with JavaScript when using zk. So we started a little evaluation and we were really impressed about this framework, that's the reason we decided to share the results of our development here in the infospace. Below you will find our Drag & Shop application, a web shop demo based on zk and some simple Java services. Source is avaliable below as well...Read full post...

Tags: zk, showcase