为啥选择 GWT？使用此 RIA 框架的优势和权衡 [关闭]

Posted 2023-02-26

【中文标题】为啥选择 GWT？使用此 RIA 框架的优势和权衡 [关闭]

【英文标题】：Why GWT? Advantages and Trade-Offs of Using This RIA Framework [closed]为什么选择 GWT？使用此 RIA 框架的优势和权衡 [关闭]

【发布时间】：2011-01-07 01:33:44

【问题描述】：

我一直在阅读 GWT 的一堆“投票率最高”的问题。其中几个问题是关于 GWT 的陷阱或问题。

在文章：Which javascript framework (jQuery vs Dojo vs … )? 和Biggest GWT Pitfalls? 中，一些发帖者似乎暗示 GWT 不够轻量级或者有更好的替代方案可以使用。

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

在某种程度上，GWT 不应该在某种程度上是面向未来的（因为您不必担心它在不同版本之间发生巨大变化，而且它得到了 Google 的支持）？

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

【问题讨论】：

我将添加***.com/questions/523728/…、reddit.com/r/programming/comments/aqsxq/… 和cforcoding.com/2009/10/lost-in-translation-or-why-gwt-isnt.html

【参考方案1】：

权衡

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

你正在使用 Java

- 这意味着你的 webdevs 对 javascript 的熟练程度不会派上用场（如果你涉足 JSNI 会很有帮助）

搜索引擎索引问题

- 恕我直言，这应该是 使用 GWT 的最大缺点，或者 一般的纯 JS Web 应用程序。 由于内容，布局，一切 是用 JS “即时”创建的， 搜索引擎只会看到一个非常 简短的 HTML 页面，就是这样 - 你 必须以某种方式解决这个问题 你自己（例如，使用 cloaking)。谷歌终于 started to work on a solution for this，但似乎没有 对我很有吸引力。

更新：

Google 有 finally addressed 这个问题。但是，我将把它作为一种权衡，因为与其他框架相比，使应用程序可抓取仍然需要更多的努力。至少现在我们有一个“标准”可以遵循，并且不必使用一些可疑的技术（如cloaking）。 很容易（尤其是对于 GWT 的初学者，尤其是当那个人来自 HTML/JS 背景 - 没有太多面向对象的经验）去“哇，这些'对象'事情太酷了，让我把我所有的<div>s 变成单独的对象，这将使代码变得漂亮整洁”。当然，我夸大其词了，但你明白了——很容易想象一个没有经验的程序员可以在FlexTable 的每个单元格中放置一个成熟的Widget 和大量Handlers。 . 然后（s）他会浪费很多时间想知道为什么应用程序感觉迟钝;）

tl;dr：GWT 的初学者很容易通过编写看起来符合文档/样本/常识 ;) 建议

这就是我能想到的权衡取舍——如果有人想添加一些东西，请添加 cmets。

优势

现在来说说优势。我将跳过像internationalization、cross-browser compatibility 这样免费的、与其他 Google 库的轻松集成等，因为它们有点明显且易于掌握。我将尝试专注于不太强调但仍然非常重要的功能：

编译器

- 现在，与我讨论过 GWT 的大多数人都没有 意识到这部分是多么神奇 GWT 是 - 对于初学者，请尝试 this presentation from last year's 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

- 无论您是否喜欢 Java，都不可否认 这是一个非常好的面向对象 语言，允许编写易于维护和可测试的代码 （我认为不可能的事情 JavaScript 达到这种程度）。如果 你关注一些good guidelines， 你会得到一个代码 不仅你可以理解，而且 也适用于其他开发人员。其他 值得一提的是，所有 那些漂亮的设计模式等 使用“纯”Java 工作，也可以在这里工作。 GWT 的一个妙处是你 获得

性能提升和新的 几乎所有的免费功能

框架的新版本。自从 它是 Java 编译成 JavaScript，它 只需重新编译即可受益 从在 新编译器或获得新功能（如 GWT 1.5 中引入的 accessibility support）。

调试

- 值得一提的是，您可以（并且应该 :)）使用 IDE 的调试器调试 GWT 应用程序，就像任何其他 Java 应用程序一样。而且，总的来说，我见过的 Java 调试器比 JavaScript 对应的调试器更先进。

UiBinder

- 虽然它仍然不是“完美”的，UiBinder 让您使用 XML 以一种简单直观的方式设计您的小部件（而不是强制您在 Java 中执行此操作的 2.0 之前的方式） ）。混合 HTML 和 GWT 的小部件从未如此简单和有趣；）

使用 CSS

- 当然，GWT 一直都支持 CSS，但随着 GWT 2.0（和 UiBinder）的引入，他们将其提升到了另一个层次。让我们看一下来自“普通”Web 应用程序的 CSS 文件 - 数百行，甚至数千行，难以导航，有些样式是多余的，但很难注意到，有些根本没有使用，添加到这个混合需要取悦 IE6/7，你会让自己做噩梦。使用 GWT，您可以指示它执行它为 CSS 的 JS 代码执行的类似任务 - 因此它将修剪所有未使用的 CSS 样式，在适当的地方合并，最小化和混淆类名，and many more（包括条件、常量等在您的 CSS 文件中）。我们鼓励您将样式保存在它们各自的 UiBinder 的 XML 文件中 - 使组织和查找它们变得更加容易。最后但并非最不重要的一点是，当您拼错 CSS 样式名称时会出现错误 - 比尝试通过 Firebug 或类似工具执行相同操作更轻松

OOPHM

- 进程外托管模式，通过这个，他们修复了 GWT 的最大缺点之一 - 现在，您可以在您选择的浏览器中使用托管模式（如果该选择是 Firefox、Safari , IE 或 Chrome，但至少你可以使用任何你想要的版本）。 OOPHM 的设计还允许您做一些很酷的事情，例如在 VM 中运行 Windows，并从那里的 IE 连接到在主机操作系统（Linux/MacOS）上运行的托管模式 - 无需破解，每次编译后复制文件，等等 你经常说 /ˈɡwɪt/ ;)（这是引用自 Google IO 2009, IIRC 上的演讲之一） 还有更多.. 观看来自 Google IO 2009 的视频并浏览 GWT wiki 以查看更多内容，这些内容使使用 GWT 创建 RIA 变得更容易，更不容易出错 :)

介于两者之间

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

开箱即用的collection of Widgets 保持小而简单

。现在，如果您来自一些成熟的 GUI 框架（无论是 Web 还是桌面），您可能会对 GWT 的 Widgets 数量相对较少感到惊讶。但是根据 GWT 的开发人员的说法，它是故意保持这样的 - 基本的小部件是您构建自己的所需的所有工具/“块”，根据您的需要定制小部件。另一种方法是提供各种必须支持许多用例的通用小部件......结果是一个有点迟钝的用户界面（至少恕我直言 - 自己检查像SmartGWT或Ext GWT这样的项目）。也就是说，GWT Widget 写得非常好 - 例如 SuggestBox 有很多地方可以用自己的方式覆盖默认行为 - 你可以指定不同的方式来显示建议 (SuggestBox.SuggestionDisplay)，当用户选择建议 (SuggestBox.SuggestionCallback) 时触发自定义操作，或者仅提供自定义 SuggestOracle 以使用 Suggestions 提供 SuggestBox...

---

底线是 - 试试 GWT，你很可能会喜欢它，并且再也不想用纯 JavaScript 编写了；)

【讨论】：

更多关于使 AJAX 应用程序可抓取的信息：code.google.com/web/ajaxcrawling/docs/faq.html

谢谢，马特，提醒我这一点 - 我已经更新了帖子:)

我不确定索引应用程序的屏幕是否相关。

@Christopher：取决于您的应用程序是/做什么 - 如果它是电子书阅读器，例如 Google 图书，那么是的，这非常重要。如果它是电子邮件阅读器，那么绝对不是 ;)

【参考方案2】：

自 1.3 版发布以来，我们正在定期使用 GWT 构建小型（约 2K Java 类）到中型（约 6K）企业系统。我知道在每秒点击数以千计的公共网站中需要解决一系列不同的问题，但我将尝试讲述 GWT 1.x 中我们最大的问题以及 GWT 2.0 如何解决这些问题。

浏览器内存泄漏 带有 GWT 的 IE6 泄漏是巨大的，IE7 泄漏可以通过定期页面刷新来弥补，IE8 承诺在这方面具有一定的稳定性，但尚未在企业中被广泛接受。是的，在某些情况下，即使没有原生 JS 调用的有效 GWT 代码也会泄漏内存。尤其是当 UI 很复杂并且您正在执行大量 Panel.clear() 调用时。目前没有有用的工具来确定泄漏的真正原因。除非你知道如何侵入浏览器本身。

渲染性能您必须非常仔细地编写您的 UI 代码，尤其是在构建常用的自定义小部件时。仍然需要深入的 JavaScript、CSS 和 DOM 知识。互联网上有很多关于这个主题的材料。您需要知道如何以及何时从 GWT 小部件级别降至直接 DOM 操作。

可下载内容的大小 在 2.0 之前，如果没有在应用程序中内置“硬”导航，就不可能将模块拆分为不同的可下载部分。但这会清除 JavaScript 上下文并需要重新加载窗口。

UI 开发人员思维转变 经验丰富的 UI 开发人员只是不了解 Java 和 OOP。经验丰富的 Java 开发人员不懂 CSS、JS、HTML，也不喜欢构建 UI。 UI Binder 朝着正确的方向发展。

我们已经完成了 1.3 -> 1.5 -> 1.7 的迁移，它始终只是重新编译和一些 CSS 修复。 GWT 2.0 删除了许多不推荐使用的代码和初始方法（项目结构、GWTShell），并且可能难以快速迁移。但是所有功能看起来都很有前途，而且谷歌在某个时候放弃了遗留代码也很好。不过我不确定 2.0 的稳定性，因为我们还没有在实际项目中使用它。

希望这会有所帮助。

【参考方案3】：

我们有一个带有大量 Selenium 验收测试的 GWT 应用程序。我认为（像你一样）将 GWT 从 1.7 升级到 2.0 肯定是安全的。它是 - 主要是。该应用程序对“人类”用户仍然有效，但硒测试全部失败。有一个更新版本的 Selenium 正在准备中（在 alpha 版本中，有许多 UnsupportedOperations），但如果我们想继续使用 GWT 2，似乎我们必须放弃一些可测试性。所以要小心“面向未来”的假设。

在比较了 YUI 和 ZK 之后，几个月前我们决定使用 GWT。我仍然很高兴我们选择了 GWT。 GWT 网站上的支持水平和文档的总体质量似乎非常高。

GWT 进行模块拆分并提供性能分析，这有助于反驳认为它不够轻量级的论点。