Real-world ZK vs GWT experience

Viewed 11029

A fellow developer and I are putting together a proposal for a new application, and we've presented both ZK and GWT to be possible choices. After messing around with both, I'd prefer to move ahead with a ZK proof-of-concept, but one of the "senior architects" of the company (who isn't even on our team) seems to be trying to take over the project and tell us what technologies to employ. He's finding any excuse he can to push GWT onto us and call foul on ZK.

Now I'm not saying that GWT is inherently bad, nor that ZK is the be-all-and-end-all of web application development, but I don't like being told how to develop a application by someone who hasn't really done enough research to push a particular technology. Although this guy is not on our team, management tend to listen to him, and will probably "tell" us what to use.

This guy's arguments against ZK seem to be "browser incompatibility", "too much business logic in the browser", and "project immaturity". I disagree with all three of these. He also provides no arguments for GWT, which seems like he actually doesn't know much about either technology. He also claims that it's better to use a technology that someone within the company knows. There is only one team here that has actually used GWT, and that project has had... issues.

Could someone with some real-world experience with ZK and/or GWT suggest some arguments I can provide that would at least put both the technologies back on the table, rather than attempting to push a single technology with no real research?

7 Answers

Company directors hate risk and uncertainty. If there are many developers saying a framework is cool and one architect sucking through their teeth and muttering about risk then they are going to go with the naysay very single time. You need to get 3rd party independent references for the software which is possible even with opensource.

There is at least one company who sells support for ZK. They will be happy to put you into contact with architects at companies who have used ZK. Ask these independent third party architects a set of open ended questions such as "what did you most like and what did you most dislike" and "what was the main challenge you found" and "what most surprised you" and "what other frameworks did you consider and why did you pick ZK". Company directors love this sort of fact based research talking to senior people at other companies.

As the same time design an "assault course page" which is a fair representation of the sort of complexity you will have to build on the project. Have the team implement that page both in ZK and in GWT and have everyone try to improve both. Write up that experience as a team. Be sure to include the person who was against ZK and do not do this in an adversarial manner. Don't get into a them-vs-us or her-vs-me situation but keep it as an open team fact finding and training exercise where anyone can contribute to any bit. Wiki pages might be an ideal format for this.

You will have success with this approach as ZK has been used on multiple million dollar development projects with teams over thirty developers at billion dollar global financial corporations. You are amongst good company in preferring to use ZK.

ZK is much easier to use and has a lower learning curve API-wise. GWT on the other hand is harder to learn and more bulky in the sense the it might take ages to compile if you want to create all the permutations and you don't use appropriate plugins for just in time compilation. The latter provides a much faster user experience though. Use ZK if you want to create GUIs for intranet applications fast. If you are addressed to a larger audience use GWT instead (the lack of standard components in GWT is not a real factor since you can use GWT-ext instead and on the other hand most essential ZK components are proprietary).

Related