为什么selectGWT？ 使用这个RIA框架的优点和权衡
我一直在阅读一些关于GWT的“最高票数”的问题。 其中几个问题谈论GWT的陷阱或问题。
在文章中： 哪个Javascript框架（jQuery vs Dojo vs …）？ 和最大的GWT陷阱？ ，一些海报似乎表明，GWT不够轻便，或者有更好的替代品可以使用。
你们大多数人是否觉得在GWT 2.0中没有解决GWT问题 – 这会让你倾向于build议使用一个更简单的框架来完成一个新项目？
在某种程度上，GWT不应该有些面向未来（因为你不必担心它从发布到版本发生巨大的变化，并且是由Google支持的）。
我意识到这个问题的答案很大程度上取决于你想要做什么或者你想做什么。 我正从开始一个新的Web应用程序的angular度来看待这个问题，这个应用程序最终将被数百万用户使用。
权衡
让我们从所有我能想到的取舍开始：
- 您使用的是Java – 这意味着您的webdevs在JavaScript中的熟练程度将不会如此（如果您涉足JSNI，这将有所帮助）
- 与search引擎索引问题 – 恕我直言，这应该是使用GWT，或纯粹的JS Web应用程序的一个最大的缺点。 由于内容，布局，所有东西都是用JS实时创build的，所以search引擎只会看到一个非常短的HTML页面，这就是你必须自己照顾这个（比如使用隐形 ） 。 谷歌终于开始为这个解决scheme工作 ，但对我来说似乎并不吸引人。
更新： Google 终于解决了这个问题。 但是，我将这个作为一个折衷，因为使应用程序可爬行仍然需要比其他框架更多的努力。 至less现在我们有一个“标准”可以遵循，而不必使用一些可疑的技术（如隐形 ）。 - 这很容易（特别是对于GWT中的初学者， 特别是当这个人来自HTML / JS背景 – 没有太多的面向对象的经验），所有的“哇，这些”对象“的东西是如此的酷，让我做我的一切
<div>分成不同的对象，这将使代码都很好，很整洁。 当然，我过分夸大了它，但是你明白了 – 很容易想象一个没有经验的程序员可以在FlexTable每个单元中放置一个拥有大量Handlers的成熟Widget。然后，他会浪费很多时间，想知道为什么应用程序会感觉迟钝;） tl; dr：GWT的初学者很容易通过编写符合文档/样本/常识的代码来使应用程序变得“笨拙” ） build议
这就是我所能想到的折衷 – 如果有人想添加一些东西，请添加评论。
优点
现在的优势。 我会跳过一些像国际化 ， 跨浏览器兼容性的免费，容易与其他谷歌图书馆等整合，因为它们有点明白，容易掌握。 我会试着把重点放在不那么重要但仍然非常重要的特征上：
- 编译器 – 现在，大多数我和GWT谈过的人都没有意识到GWT的这个部分有多么了不起 – 对于初学者来说，尝试去年的Google IO这个演示 。 编译器具有整个应用程序的视图。
所以它可以优化这样的东西：
public class ShapeExample implements EntryPoint { private static final double SIDE_LEN_SMALL = 2; private final Shape shape = new SmallSquare(); public static abstract class Shape { public abstract double getArea(); } public static abstract class Square extends Shape { public double getArea() { return getSideLength() * getSideLength(); } public abstract double getSideLength(); } public static class SmallSquare extends Square { public double getSideLength() { return SIDE_LEN_SMALL; } } public void onModuleLoad() { Shape shape = getShape(); Window.alert("Area is " + shape.getArea()); } private Shape getShape() { return shape; } }
..对此：
public class ShapeExample implements EntryPoint { public void onModuleLoad() { Window.alert("Area is 4.0"); } }
然后混淆这一点，并尽量减less。 此外，这样做，使得生成的文件通过gzip更加可压缩。
- 你正在使用Java–无论你是否喜欢Java，不能否认它是一个非常好的面向对象的语言 ，它允许编写易于维护和可testing的代码（我认为JavaScript中不可能达到这样的程度）。 如果你遵循一些很好的指导方针 ，你将得到一个不仅对你而言可以理解的代码，对其他开发者也是如此。 另外值得一提的是，所有那些在“纯粹”的Java中工作的漂亮的devise模式等，也都在这里工作。
- 关于GWT的一个漂亮的事情是，几乎每个新版本的框架都可以免费获得性能提升和新function 。 由于Java是编译成JavaScript的，所以只需要重新编译就可以从新编译器中进行优化或者获得新的特性（如GWT 1.5中引入的可访问性支持 ）。
- debugging – 值得一提的是，您可以（也应该:)）使用您的IDEdebugging器来debugging您的GWT应用程序，就像任何其他Java应用程序一样。 而且，总的来说，我所见过的Javadebugging器比其他的JavaScript更先进。
- UiBinder – 虽然还不够“完美”，但UiBinder可以让您使用XML以简单直观的方式devise自己的Widget（与之前的2.0版本相比，它强制用Java来实现）。 混合HTML和GWT的Widget从未如此简单和有趣;）
- 使用CSS – GWT当然一直采用CSS，但是随着GWT 2.0（和UiBinder）的引入，它们将其推向了另一个层次。 让我们来看一个来自“普通”web应用程序的CSS文件 – 数百条（如果不是数千行），很难浏览，有些样式是多余的，但很难注意到，有些是完全没有使用的，添加到这个混合需要请IE6 / 7，你让自己一个噩梦。 使用GWT，您可以指示它执行与JS代码相似的任务 – 因此它将删除所有未使用的CSS样式，在合适的地方进行合并，最小化和混淆类名称， 以及更多 （包括条件，常量等你的CSS文件）。 我们鼓励您将自己的样式保留在各自的UiBinder的XML文件中 – 使组织和查找变得容易得多。 最后但并非最不重要的一点是，当拼写一个CSS样式的名字时会出现错误 – 而不是那么麻烦，然后试图通过Firebug或类似的工具来做同样的事情
- OOPHM – 进程托pipe模式，这样，他们修复了GWT最大的缺点之一 – 现在，您可以在您select的浏览器中使用托pipe模式（如果select的是Firefox，Safari，IE或Chrome，但在至less你可以使用任何你想要的版本）。 OOPHM的devise还允许你在虚拟机上运行Windows等酷炫的东西，并从那里的IE连接到在主机操作系统（Linux / MacOS）上运行的托pipe模式 – 无需黑客，每次编译后复制文件，等等
- 你会说/ɡwɪt/很多;）（这是来自Google IO 2009 ，IIRC上的一个演示报价）
- 还有更多..看一下Google IO 2009中的video，浏览GWT wiki来看看更多的东西，使得使用GWT创buildRIA更容易，更less出错。
在之间
根据你的经验和/或喜好，以下可能是一个优势（这是对我来说，但有时它是一个PITA;））或不是：
- 开箱即用的Widgets集合保持小而简单 。 现在，如果你来自一些成熟的GUI框架（无论是Web还是桌面），你可能会惊讶Widget GWT的数量相对较less。 但根据GWT的开发者，这是保持这样的目的 – 基本的小工具都是您需要build立自己的，根据您的需要小工具定制的所有工具/“块”。 另一种方法是提供各种各样的通用小部件，这些小部件必须支持许多用例…结果是一个有点迟钝的用户界面（至less恕我直言 – 检查自己的项目像SmartGWT或内置GWT ）。 也就是说，GWT Widget写得相当好 – 例如，
SuggestBox有很多地方可以用你自己的默认行为覆盖 – 你可以指定一个不同的方式来显示build议（SuggestBox.SuggestionDisplay），触发当用户select一个build议（SuggestBox.SuggestionCallback）或只是提供一个自定义SuggestOracleSuggestBox与Suggestions …
底线是 – 尝试GWT，你可能会喜欢它，永远不会再用纯JavaScript编写了）
从1.3版本开始，我们正在使用GWT定期向中（〜6K）企业系统构build小型（〜2K Java类）。 我知道在公共站点上每秒钟有一千次点击需要解决一些不同的问题，但是我会尽量告诉我们在GWT 1.x中的最大问题以及GWT 2.0如何接近这个问题。
浏览器内存泄漏与GWT的IE6泄漏是巨大的，IE7泄漏可以定期页面刷新补偿，IE8承诺在这方面的一些稳定，但尚未被广泛接受的企业。 是的，即使有效的GWT代码没有本地JS调用泄漏内存在某些情况下。 特别是当UI很复杂时，你正在做很多Panel.clear（）调用。 目前没有有用的工具来确定泄漏的真正原因。 除非你知道如何破解浏览器本身。
渲染性能你必须非常小心地编写你的UI代码，尤其是在构build常用的自定义小部件时。 深入的JavaScript，CSS和DOM知识仍然是必需的。 互联网上有很多关于这个话题的资料。 您需要知道如何以及何时从GWT窗口小部件级别指示DOM操作。
可下载内容的大小在2.0之前不可能将模块分割成不同的可下载片段而没有在应用中build立“硬”导航。 但是，这将清除JavaScript的上下文，并要求窗口重新加载。
UI开发人员思维转换有经验的UI开发人员只是不了解Java和OOP。 有经验的Java开发人员不知道CSS，JS，HTML，不喜欢构build用户界面。 UI粘合剂进入正确的方向。
我们已经完成了迁移1.3 – > 1.5 – > 1.7，并且它只是一个重新编译和一些CSS修复。 GWT 2.0删除了大量不推荐使用的代码和初始方法（项目结构，GWTShell），并且可能很难快速迁移。 但是，所有的function看起来都很有前途，而Google在某些时候已经放弃了遗留代码。 我不确定2.0的稳定性，因为我们还没有在实际项目中使用它。
希望这可以帮助。
我们有一个GWT应用程序与一堆selenium验收testing。 我想（像你一样）将GWT从1.7升级到2.0肯定是安全的。 而且 – 主要是。 该应用程序仍然为“人”用户一样，但seleniumtesting都打破了。 有一个更新版本的Selenium正在准备中（在Alpha版本中，有许多UnsupportedOperations），但是如果我们想要使用GWT 2，似乎我们不得不放弃一些可testing性。 所以要小心“面向未来”的假设。
在比较YUI和ZK之后，我们决定使用GWT。 我很高兴我们select了GWT。 GWT网站的支持水平和文档的总体质量似乎非常高。
GWT做模块拆分，并提供性能分析，这有助于反驳它不够轻量的参数。
