![]() So in that spirit, we revisit what is it mean to be in the job market today, and we talk about the advice we can give to those that are looking to either jump to a new opportunity or advance their career. Even so, winds seem to be changing and a slowdown looms over the horizon. FAANG and others are really really looking for new developers, and have been poaching any talent they can grab. Maybe we are a deadly threat to them, or they just pour too much resource in marketing.So markets are changing, and we have a crazy two years. I thought their competitors are RichFaces and other tens of Ajax JSF providers. I am very much satisfied with Icefaces course, Arif sir gave many concepts to us and which are more than enough to grab a job and to get job sustainability. It is somehow amusing to see someone considers us as the major competitor. And, yes, we will be more than happy to improve it as we did year over year. However, I do prefer to come out with a real question like what ZK Server Push cannot do, why it is important. 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. I agree with Macros about thanking for their point something out to improve. ![]() 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:) It is too easy to confuse and mislead the readers with the jargon they invented. I really don't like this kind of jargon-based comparison. If a developers knows POJO and threading, he can do server-push. ![]() The application developers don't need to know so-called Push Render Manager or whatsoever. A simple API surface is not only easy to learn/use, but also the key to have an elegant and reliable system.įor Server Push, we introduced only three APIs (enableServerPush, activate and deactivate). When we design a new feature, the most important thing is what are the minimal APIs we have to introduce. However, complication itself is not a feature. JSF is complicated, so are Ajax JSF solutions. I addition you should watch performance of ZK in all new released version like those made by It is necessary to improve Rendering performance and Java heap consumption. I believe that you can improve it, because now there is points to work. In addition, ICEfaces works hard improving Ajax Push, while ZK looks like stopped improving Ajax Push. I already see great produts using. to have great concurrency support. I used "." for compatibility concurrency framework across <= jdk 1.4 while building an Console Real Time Application running AS400 with Java. ![]() I previous said that, the chat example is compatible with JDK 1.4 which is not full capable of using actual framework. 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 IMHO, you should know that ICEfaces Ajax Push is really better than ZK Ajax Push, if you think contrary, prove it. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |