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