为什么我应该使用 jQuery 而不是 GWT？

「课程马匹」

选择对这个项目最有意义的一个。有些事情需要考虑

• 时间跨度很紧，一个比另一个更熟悉
• 其他开发人员使用所选工具的速度和可维护性。这两者之间的流行也可能在这里产生影响
• 有任何可以在项目中使用的代码，例如插件，实用功能等。

如果不知道项目是关于什么的，你的经验是什么，以及客户对于使用不同的技术/框架有多开放，这里就不会有决定性的答案。

列出一个又一个引人注目的论点，就像我在这里开始的那样，然后与其他参与项目的人讨论得出结论。

我个人的观点是使用 jQuery，但那是因为我从不使用 Java，而且非常喜欢使用 jQuery 插件。

活跃用户组和最近的流行显然表明 jQuery 是赢家。

我建议那些不懂 JavaScript 但(可能)更熟悉 Java 的团队使用 GWT。使用 gWT，你可以节省几天甚至几个星期的相容性测试，并且可以避免很多初学这门语言的人撞上的 常见的 JavaScript 陷阱。GWT 还为 CSS 精灵、 嵌入式资料和 更多提供了很好的打包特性。

然而，如果你知道并理解 JavaScript，我会使用 JavaScript，无论您选择的库是什么。虽然我还没有机会仔细检查 GWT 生成的代码，但是我在 Google I/O 上看到了一些例子，虽然它看起来很棒，但是你可能会用老式的方法创建更优雅的 JavaScript 代码。

如果您的团队最熟悉 Java，并且计划执行大量的客户端功能，那么您至少应该评估 GWT。类型安全、 Eclipse 调试和服务器端/客户端之间的共享代码将使 Java 开发团队感到舒适。

但是，如果您的团队习惯于使用 jQuery 或其他 JavaScript 库进行 JavaScript 编程，那么坚持使用纯 JavaScript 技术可能会更容易。GWT 可以接管页面的大部分内容，这对于大多数 JavaScript 开发人员来说是不熟悉的。通过接管页面，我的意思是典型的 GWT 代码喜欢创建自己的 DOM 元素，而不是向页面上的现有元素添加功能。这就是为什么许多 GWT 应用程序在首次加载页面时会有一个“加载...”屏幕。这没有必要，但它是 GWT 开发中最常见的风格。

由 GWT 生成的代码对于大多数 GWT 开发人员来说并不那么重要。GWT 允许您将 Java 编译成与普通 Java * 等价的东西。类文件，但在 JavaScript 语法，网络浏览器理解如何解释。与模板驱动的代码生成器相比，GWT 更像是一个编译器。有时候您需要检查生成的代码，但是在大多数情况下，您的调试将通过 Java 调试器在 Java 中进行。

另一件需要考虑的事情是，无论您选择哪种客户端技术，您的开发团队都需要熟悉 HTML、 JavaScript、 CSS 和浏览器编程。GWT 允许您在一个熟悉的 Java 环境中编写客户端代码，但是它不会隐藏您在浏览器中工作的事实。

我同意 Russ Cam 的说法，这取决于你的团队熟悉什么。当我为我的个人商务应用程序工作时，我更喜欢 GWT。我发现 javascript，即使使用 jquery，也有恼人的面向对象语法。如果你有一个有10,000行 UI 代码的应用程序，jquery 给我的印象是，它会导致很难维护代码，而且重用性很差。

有人知道用 jquery 完成的大型项目吗？

我认为，如果你试图挤出每一个字节的结果文件大小，不要使用任何库和编写的 javascript 从头开始(即: 谷歌主页褪色效果)。

关于 javascript/jquery 和 gwt 的一些思考。如果使用常见的面向对象原则和设计模式，那么使用 gwt 可能会获得更好的代码性能。为什么？

让我们以多态性为例。如果您编写的应用程序在 javascript 中使用了大量的多态性，那么您将从可维护性和代码重用中获益。但是，您的代码也会因使用多态性而获得性能提升。

现在，如果您使用了 gwt，您还将获得可维护性的好处，并且代码重用它所提供的功能，但是 gwt 编译器将优化多态性，使之成为具体的类使用，从而提高性能。

我会选 JQuery。

我曾经维护过一个 GWT 项目，最终迫使我重写了两次。第一个是重构的 GWT 应用程序，第二个是 JQuery。

我已经很长时间没有认真地使用 Javascript 了。上一次是在2002年。我是一个 Java 开发人员，所以我对 GWT 的第一印象非常棒。但那只是我的印象。

我在 GWT 中发现的问题:

1. 它强制您遵循其客户机/服务器结构。最后，我想要的只是 AJAX 和那些好的小部件。GWT 的小部件本身看起来并没有那么好看。从美学上讲，我更喜欢 Adobe Flex！但是为了更好地进行比较，JQuery 的 UI 看起来比 GWT 更好。此外，还有来自 JQuery 的精彩的 Theme Roller 支持。

2. 我试过 DWR，它很棒。在 Java 代码中使用 DWR 启用 AJAX 要比使用 GWT 容易得多。

3. 如果您正在使用 GWT，最终您将被迫学习 JavaScript。SpringSource 的 Arjen 曾经谈到 XML 和 SOAP (虽然不是确切的引用) : “你怎么能开发 WebServices 而不了解 XML 呢？SOAP 是 XML。你无法避免”。GWT 也是一样。归根结底还是 Javascript。

4. 实际上，学习 Javascript 和 Java 相比并不难。知道 Javascript 的人比知道 Java 的人多。连网页设计师都知道。你是个程序员，你害怕 Javascript？

5. 回到我重写的项目。当我重写我们的 GWT 应用程序时，我花了将近两个月的时间来重写它。使用 JQuery 花了我两个星期的时间，而我对 JavaScript 已经生疏了。

6. 使用 JQuery 时，你不需要真正地编写硬码 JavaScript。这就是为什么首先要使用 JQuery 的原因。用 GWT 维护代码非常可怕。您希望看到在代码中所做的最新更改... ... 去编译... ... 等待 GWT... ... 5分钟... ... 清洗... ... 然后重复并希望它不会抛出错误。如果出现这种情况，您将再次进行重新编译，并再等待5分钟。冲洗，重复。使用 JQuery 更改一行，刷新您的浏览器。成交。

我知道我在这里不是很客观，但我只是在分享我的经验:)教训是不要害怕 Javascript。Google 还是使用 Javascript

我认为 GWT 太抽象了。Javascript 实际上是一种强大的语言。您可以编写面向对象的代码并使用命名空间。使用像 jQuery 这样的库，您不必担心大部分工作中的浏览器兼容性问题。现在所有主流浏览器中都有很棒的浏览器开发工具(比如 Firebug) ，使用 javascript 非常容易。当一个 javascript 错误发生时，我可以很容易地指出它在我的代码中发生的地方。我可以观察变量并详细了解所有正在发生的事情，因为我正在处理我编写的代码(与 GWT 不同)。

我发现 GWT 与本地 Javascript 解决方案(jQuery 或其他)的主要问题是:

• 还有一个额外的过程将您与您的最终产品区分开来。您用 Java 开发应用程序并调试 Java 代码，但是您发布了该代码的机器翻译版本。对于一个大小适中的应用程序，我无法想象你不需要调试浏览器上运行的实际代码，这将是一个令人头疼的问题，因为它不是你的代码。

• 因为您使用 Java 编写代码，所以只能使用 Java 库。如果您找到了一些您喜欢的 JS 库，那么将它添加到 GWT 项目中将会非常困难，您可能需要为它编写一个 Java 包装器。如果您正在开发本地 JS，您可以将它添加到您的项目中。

• JS 本身就是一种令人敬畏的语言，它有着与 Java 不同的坚实的对象模型。我用本地 JS 为 HP webOS 开发了一些应用程序，惊讶地发现我对这门语言的许多先入之见并不正确。你可以尽可能多地使用 Java 编写简洁、高效和可维护的 JS 代码，如果你花时间去理解 JS 对象模型，你甚至不需要使用支持库来模拟更典型的类/对象模型，比如 Java 和 C + + 在 JS 上的模型。Javascript 的原型很酷。

• 如果你曾经考虑过在移动平台上发布你的应用程序，那么一个原生的 JS 应用程序可以很容易地被包装在手机间隙中，并且可以访问多个移动平台，而不需要额外的努力。还有一个用于 phonegap 的 GWT 包装器，但是回到我的第一个项目，如果您可以选择使用真实的东西，那么为什么要选择需要翻译/仿真的解决方案呢？

祝你好运。

JQuery = 低级理解

除了普通的 javascript 和 java 解释之外，Jquery 与 javascript 之间的映射更接近于一对一，而 GWT 则更抽象。因此，如果您希望更深入地了解代码在底层(javascript)发生了什么，那么 jquery 是正确的方法。

GWT = 抽象理解 = 功能保证

GWT 提供了编译器生成代码的优势，所以它可以提供更多的保证，您的网站将正常运行。然而，像任何大规模的 API 一样，您需要花时间来理解这个类做什么，这个类做什么，以及它是否与这个 API 兼容或不兼容。

低层次的理解可能更有用

就个人而言，我从自己编写的低级代码中获得了更多的满足感。我已经用纯 javascript 构建了一些工作中的 Web 应用程序，它们的功能完美无缺。曾经编写了 javascript 代码，从数据库中获取数据并生成完整的微软文字研究报告。这个项目的复杂性要求对 javascript 的低级掌握。我不确定用基于 Java 的解决方案是否可以轻松实现这一点。

GWT 让管理者放心，但代价高昂

但是，Java 和 asp.net 往往更受大公司的青睐。 b/c 有更多的技术支持(比如甲骨文和微软) ，紧张的边缘管理人员往往在晚上睡得更好，因为他们知道他们可以通过支付 x 美元的支持来解决问题 A。因此，在采用了这个系统之后，他们很快就开始意识到技术支持成本太高，而且花更多的钱请更好的开发人员会更便宜。所以才有了爪哇咖啡。网络职业通常会让人有饭吃。

可维护性

而且像 GWT 这样的 API 更容易维护。我只能想象，如果有人不得不调试我的 javascript 代码，他们会经历怎样的恐惧。但那是在我成为一个更好更干净的程序员之前，因为我知道代码的每一个方面，没有什么可以调试 b/c，从来没有问题。

低级别的编码可以让你几乎100% 的理解正在发生的事情，但是使用 API，你可以花时间在谷歌上玩漏洞侦探游戏，并在 StackOverflow 这样的网站上发布问题。但是，经理们最不了解的就是这个银行不是程序员。

首先，将 GWT 与 jQuery 进行比较没有多大意义。构建 jQuery 是为了让跨浏览器使用 DOM 更加容易，而构建 GWT 是为了创建大型 Web 应用程序。

因此，如果您有一些带有独立小部件(如日历、滑块等)的静态侧，那么 jQuery 就足够了。如果您想要构建单页面应用程序，可能需要一个大型团队，GWT 是更好的方法。GWT 具有良好的设计架构，尤其是 MVP 模式、 UI-Binder 模板系统、 i18n 支持等。

因此，作为一个在大型 GWT 应用程序上工作了多年的 JavaScript 开发人员，我建议永远不要只使用 jquery 来构建单页面应用程序，因为它不是为此而构建的。如果你想使用 JavaScript，可以看看主干，脊柱，击倒或道场。

顺便说一句，GWT 架构构建得很好，但是会有很多 JAVA 开销。因此，如果您的项目正在增长，编译您的 css 和 i18n 属性的时间将是恼人的。

所有伟大的提示，没有人谈论 JSNI！GWT 中允许您使用 javascript 的一个特性，如果您愿意的话。

Https://developers.google.com/web-toolkit/doc/latest/devguidecodingbasicsjsni

答案并不容易，答案是“视情况而定”:

GWT:

• 如果你知道并且喜欢 Java 的话
• 如果您的服务器代码也是用 Java 编写的，那么用 Java 编写客户机代码可以在客户机和服务器上使用相同的代码
• 如果您喜欢强类型语言提供的东西: 编译时类型检查、自动重构、自动代码生成(Eclipse 中的 Ctrl + 1)、代码完成(Ctrl + Space)
• 如果你喜欢面向组件的编程(例如 MenuBar 创建一个菜单)
• 如果 GWT (与 jQuery 相比)的复杂性对您来说不是问题的话
• 如果大的生成代码对您来说不是问题的话

JQuery:

• 如果你知道并且喜欢 JavaScript
• 您不需要在客户端和服务器上使用相同的代码(例如，client-JS、 server-Java 或 PHP)
• 如果不需要编译时类型检查、自动重构等
• 如果您不需要面向组件的编程(要在 jQuery 中创建一个复杂的组件，您需要创建一系列 div，并调用 $(“ those div”)。Make XXXXControl ()
• 如果您喜欢简单性(jQuery 比 GWT 简单)
• 如果你需要非常小的代码(如使网站加载更快)

就个人而言，我建议大多数项目使用 GWT，但是 jQuery 也有优点，有些人可能更喜欢 jQuery。

GWT 是一个编译器(Java 到 JavaScript) ，jQuery 是一个框架。你不必选择其中一个。你可以用其中一个，两个都用，或者都不用。

例如，你可以用 Java 编写代码，如果你想的话，或者有现有的源代码，然后使用 jQuery 做其他事情。有可用的包装器，但是 GWT 可以调用 JavaScript (反之亦然) ，请参见 http://svenbuschbeck.net/wordpress/2012/06/how-to-use-jquery-in-gwt/