※ 引述《PsMonkey (痞子军团团长)》之铭言： : →《Is GWT the future of web development?》 : 翻译：http://pt2club.blogspot.com/2009/11/gwt-web.html : 原文：http://blog.balfes.net/?p=869 : →《Lost in Translation or Why GWT Isn't the Future of Web Development》 : 翻译：http://pt2club.blogspot.com/2009/11/gwt.html : 原文：http://www.cforcoding.com/2009/10/ : lost-in-translation-or-why-gwt-isnt.html : 以下简称《Isn't Future》 : 让我兴起想要写 GWT 推广文系列的念头 : （迷之声：系列？ 谁知道你能撑几篇... [殴]） : 在以传统教学方式介绍 GWT 之前 : 先针对反对 GWT 的论点作一些思考 我个人最熟的是ZK，目前正在Survey GWT(看看可不可以把两个合体，哈哈)。 在开战(??)之前，先说明一下，我很喜欢GWT。 今天如果专案开发的情况是： 1. 一个B2C网站，需要同时多人上线、Content-Base导向。 2. 开发团队熟谙Java Web 开发技术，有过Swing or SWT开发经验。 3. 开发团队具有资深硬底子的系统架构能力。 4. 开发时间足够。 我会大力推荐GWT，因为国外有太多专案都以他作为backbone跟後端沟通。 而且，多数时间少直接写Javascript确实开发效率比较好。 但是今天如果专案的情况是： 1. 企业用户的内部MIS系统。 2. 开发团队整体经验较不充足。 3. 时间紧迫，专案需求分析范围有限(通常是客户的问题...哈哈) 4. 画面客制化程度较低。 我会推荐ZK。 要说ZK vs GWT 上，哪几点是我较『不喜欢』GWT的地方，那大概就是： 1. 跟Server端的合作是靠类似RPC的技术达成。 很多时候，一些事件做了就是要Server端做一堆动作，然後UI元件呈现效果。 这件事情比较起来ZK做的漂亮、简单而且直觉。相较之下GWT只能RPC，这在 Event Listening 的programming上就比较罗唆了。常常一件多UI、Business 的操作会有好几重的Annonymous Inner Class叠上去。 (不过ZK为了在这点上面漂亮简单，也付出了代价。) 2. Swing Programming是唯一的选项。 虽然说ZK的ZUL(XUL Like Programming)对UI设计分析人员来讲还是有点辛苦 ，但是这是受个三天教育训练就可以克服的东西。而透过ZK的MVC架构也可以 确实解决Java code、Markup Language混杂一气的问题。 相较之下，GWT在这方面UI设计分析人员的介入只能就个别元件的视觉化设计 去做调整，整体Usability、Color Code上面的调整还是完全要程式人员介入 才行。 (不过，这件事情大多时间都是小问题，因为台湾不管有哪些工作都是薪水最低 的那一个人做，哈哈哈~~~) 3. 人员素质要求高。 AJAX应用程式开发我觉得最可怕的地方是，当你大量使用後发现架构设计错误 时，你已经是千年身了，GWT帮你把Communication Channel 还有差劲的 Javascript造成的负担减低，但是他要求UI架构的OO Design就跟Swing Programming时一样要做好。 这对没经历过Desktop Application Programming的人来说有点硬。 (话说回来，我觉得用GWT用到像Google Wave一样是特技动作，一般团队没那个 技术力别在实际专案中尝试阿。) 我个人的结论是，GWT是非常重视基本、而且单纯的架构设计。 他专注在如何利用Java OO的特性，减低Widget Design & UI Programming的负担， 并以最低的侵入性，连接Client端UI与Server端 Business Logic。 在没有Client JS冲突的情况，非常适合跟别人混用。 -- 我所信仰的科学是一种谦卑的理性，承认自身的无知与渺小才能观察到世界在我们贫 弱的知觉上留下来的痕迹。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 123.194.174.175