为什么选择GWT？使用此RIA框架的优点和取舍

如何解决为什么选择GWT？使用此RIA框架的优点和取舍

权衡取舍

让我们从我能想到的所有权衡开始：

Java-这意味着您的webdev熟练使用javascript不会派上用场（如果您精通JSNI，将很有帮助）
-恕我直言，这应该是使用GWT或一般纯JS Web应用程序的最大缺点。由于内容，布局和所有内容都是使用JS“即时”创建的，因此搜索引擎将仅看到一个非常短的HTML页面，就是这样-您必须自己来解决这一问题（例如，使用 Cloaking）。Google终于开始致力于解决此问题的方法，但是它对我来说似乎并不有吸引力。 Google终于解决了这个问题。但是，我将权衡取舍，因为与其他框架相比，使应用程序可爬网仍然需要更多的精力。至少现在我们有一个“标准”可以遵循，而不必使用一些可疑的技术（例如伪装）。
很容易（特别是对于GWT的初学者， 尤其是 当这个人来自HTML / JS背景-没有太多的面向对象的经验时）很容易“哇，这些“对象”的东西太酷了，让我把我所有的东西<div>放入单独的对象中，这将使代码变得更加简洁。” 当然，我过分夸大了，但是您明白了—很容易想象，一个没有经验的程序员可以在一个单元的每个单元中放置一个成熟的程序Widget，然后……浪费了大量的时间想知道为什么应用程序感觉呆滞;） *

这就是我能想到的所有折衷方案-如果有人想添加某些内容，请添加注释。

优点

现在获取优势。我将跳过一些类似的国际化，免费的跨浏览器兼容性，易于与其他Google库集成的操作等，因为它们显而易见且易于掌握。我将尝试着重于强调较少但仍然非常重要的功能：

-现在，我与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");
  }
}

然后对此进行混淆并最小化。另外，这样做是通过gzip使生成的文件更具可压缩性。

无论您是否喜欢Java，都不能否认它是一种非常好的面向对象的语言，它允许编写易于维护和可测试的代码（我认为JavaScript无法达到这种程度）。如果遵循一些良好的指导原则，那么您将获得不仅对您自己，而且对其他开发人员也都可以理解的代码。值得一提的另一件事是，所有在“纯” Java中工作的漂亮设计模式等也都在这里工作。
GWT的一个令人着迷的事情是，几乎每个新版本的框架都提供。由于它是Java编译为JavaScript，因此只需重新编译即可受益于新编译器中进行的优化或获得新功能（例如GWT 1.5中引入的可访问性支持）。
-值得一提的是，您可以（并且应该：）使用IDE的调试器像其他Java应用程序一样调试GWT应用程序。而且，总的来说，我见过的Java调试器比JavaScript调试器更高级。
虽然还不是“完美”，但UiBinder让您使用XML（而不是2.0版之前迫使您在Java中执行此操作的方式）以一种简单直观的方式设计Widget。混合HTML和GWT的小部件从未如此简单和有趣；）
-GWT一直都支持CSS，但是随着GWT 2.0（和UiBinder）的引入，他们将CSS提升到了一个新的高度。让我们看一下来自“普通” Web应用程序的CSS文件-几百甚至几千行很难浏览，有些样式是多余的，但是很难注意到，有些根本没有使用，添加了这种混合方式需要取悦IE6 / 7，您将陷入噩梦。使用GWT，您可以指示它执行与CSS JS代码相似的任务-因此它将修剪所有未使用的CSS样式，在适当的位置合并，最小化和混淆类名，等等（包括CSS文件中的条件，常量等）。鼓励您将样式保存在各自的UiBinder的XML文件中-使组织和查找样式变得更加容易。最后但并非最不重要的一点是，当您拼写错误的CSS样式名称时会遇到错误-麻烦更少，然后尝试通过Firebug或类似工具进行相同操作
进程脱离托管模式，由此，他们修复了GWT的最大缺点之一-现在，您可以在所选的浏览器中使用托管模式（如果该选择是Firefox，Safari，IE或Chrome，至少您可以使用所需的任何版本）。OOPHM的设计还使您可以做一些很酷的事情，例如在VM中运行Windows，然后从那里的IE连接到在主机OS（Linux / MacOS）上运行的托管模式-无需黑客，每次编译后都可以复制文件，等等
您经常说/ ˈɡwɪt /;）（这是Google IO 2009（IIRC）的一个演讲引述）
还有更多..观看Google IO 2009中的视频，并浏览GWT Wiki，以查看更多东西，这些东西使使用GWT进行RIA的创建更加容易且更不易出错:)

在两者之间

根据您的经验和/或偏好，以下内容可能是一个优势（对我来说，但这有时是PITA;））或不是：

。现在，如果您来自成熟的GUI框架（无论是Web还是台式机），您可能会对GWT的控件数量相对较少感到惊讶。但是据GWT的开发人员说，它是故意保留的-基本的Widgets是您需要构建自己的，根据需要定制的所有工具/“块”的Widgets。替代方案是提供各种通用小部件，这些小部件必须支持许多用例…结果是有点呆滞的UI（至少是IMHO-请自己检查一下SmartGWT或Ext GWT之类的项目）。也就是说，GWT窗口小部件编写得非常好-例如SuggestBox有很多地方，你可以用自己的覆盖默认行为-你可以指定一个不同的方式来显示的建议（SuggestBox.SuggestionDisplay），触发一个自定义操作，当用户选择一个建议（SuggestBox.SuggestionCallback），或者只是提供自定义 SuggestOracle用于供给SuggestBox与Suggestion小号…

最重要的是-尝试使用GWT，您很可能会喜欢它，并且再也不想用纯JavaScript编写了；）

解决方法

我一直在阅读有关GWT的一系列“最高投票”问题。这些问题中有几个是关于GWT的陷阱或问题。

你们中的大多数人是否认为GWT存在一些GWT 2.0尚未解决的问题-这会使您倾向于建议对新项目使用更简单的框架？

在某种程度上，GWT难道不应该面向未来吗（因为您不必担心GWT在各个发行版之间都会发生急剧变化，并且由于它得到了Google的支持）？

我意识到这个问题的答案在很大程度上取决于您想做什么或想做什么。我从启动一个最终将被数百万用户使用的新Web应用程序的角度来看待这个问题。