Ajax Push - ZK versus ICEfaces

answered 2009-04-30 02:30:57 +0800

robbiecheng
1144 ● 2
http://robbiecheng.sys-co...

Regarding server push, this is a slender from IceFaces, as you might know it's one of our competitor. We have a on-line chat application using server-push, you can take a look. http://www.zkoss.org/zkchat/
And I don't see any example application from IceFaces.

Moreover, we have another example, stockwatcher, which combines server push and model of ZK.
http://docs.zkoss.org/wiki/Integrate_Server_Push_with_ListModel_-_SimpleListModelSharer
And it's usage is simple, you can refer to the developer's guide.
http://docs.zkoss.org/wiki/Long_Operations#Alternative_1:_Server_Push

We hope you enjoy ZK, and feel free contact us if there is any issue.

Regards,
Robbie

answered 2009-04-30 10:00:39 +0800

sousa1981
573 ● 4

Hi Robbie,

It is good from one of yours competitor (ICEfaces) to answer, an comparison started by ZK, because you could take notes to improve your product.

IMHO, you should know that ICEfaces Ajax Push is really better than ZK Ajax Push, if you think contrary, prove it.

ZK should improve Ajax Push according ICEfaces blog in:
> Shared Connection Management
> Portal Support
> Connection Monitoring
> Scalable ARP Integration
> Advanced Push API
> Push Render Management

I previous said that, the chat example is compatible with JDK 1.4 which is not full capable of using actual java.util.concurrent framework. All other example has the same problem.

I used "edu.emory.mathcs.backport.java.util.concurrent" for compatibility concurrency framework across <= jdk 1.4 while building an Console Real Time Application running AS400 with Java.

I already see great produts using edu.emory.mathcs.backport.java.util.concurrent to have great concurrency support.

In addition, ICEfaces works hard improving Ajax Push, while ZK looks like stopped improving Ajax Push.

I believe that you can improve it, because now there is points to work.

I addition you should watch performance of ZK in all new released version like those made by @dennis.
It is necessary to improve Rendering performance and Java heap consumption.

I will write an comment to ICEfaces blog

Regards

answered 2009-05-06 03:44:17 +0800

tomyeh
610 ● 1 ● 3
http://blog.zkoss.org

updated 2009-05-06 06:05:47 +0800

JSF is complicated, so are Ajax JSF solutions. However, complication itself is not a feature.

When we design a new feature, the most important thing is what are the minimal APIs we have to introduce. A simple API surface is not only easy to learn/use, but also the key to have an elegant and reliable system.

For Server Push, we introduced only three APIs (enableServerPush, activate and deactivate). The application developers don't need to know so-called Push Render Manager or whatsoever. ZK components are just POJOs. If a developers knows POJO and threading, he can do server-push. It is not rocket science.

I really don't like this kind of jargon-based comparison. It is too easy to confuse and mislead the readers with the jargon they invented. The author definitely knows their own product very well, but does he really know about ZK? Does he know how ZK deals with Internet instability and the notorious 12030 problem of IE? Does he know ZK Server Push is pluggable that a developer can choose Client-Polling, Server Push or his own implementation? If he really know, he might consider apply a job here:)

I agree with Macros about thanking for their point something out to improve. We are not perfect and I believe the competition among vendors does bring some innovations that inspire and stimulate the improvement of the whole industry. However, I do prefer to come out with a real question like what ZK Server Push cannot do, why it is important. And, yes, we will be more than happy to improve it as we did year over year.

It is somehow amusing to see someone considers us as the major competitor. I thought their competitors are RichFaces and other tens of Ajax JSF providers. Maybe we are a deadly threat to them, or they just pour too much resource in marketing.

Regards,
Tom

answered 2009-05-06 03:45:09 +0800

tomyeh
610 ● 1 ● 3
http://blog.zkoss.org

updated 2009-05-06 05:56:30 +0800

Hi Macros,

The chat application is only a demo (for tutorial). You can use whatever threading model you like. Actually I really welcome you to write a small talk to illustrate the use of the new concurrent API with ZK Server Push. It will help the community a lot.

Regards,
Tom

answered 2009-05-07 08:38:21 +0800

sousa1981
573 ● 4

Hi Tom,

Unfortunately, I am currently without time to write an small talk. So, thanks for invitation. But I think we will have always another opportunity.

Your comments really put me more clearly, that ZK is the right choice.

I believe that ZK has better roadmap, and introduce complicated things to be easy to learn/use.

We are still using ZK deep. We have one complete new project monthly using ZK.

Yesterday I see that you will start work over "Button automatically disable itself after clicked".

I am happy with the introduce of Applet Component, I believe that we soon will be using it to communicate with printers, readers, etc, in other words to use JXFS.

Regards,