客户端的 JavaScript 框架 [关闭]答案

【问题标题】：JavaScript framework for client [closed]客户端的 JavaScript 框架 [关闭]
【发布时间】：2012-08-05 06:06:57
【问题描述】：

我的团队由更多的 Java 人员和有限的 JavaScript 经验组成。我知道这个问题已经被问过好几次了，但为了让我的事实正确，我需要澄清一些事情，因为我在客户端技术方面的经验非常有限。我们决定使用 GWT 而不是纯 JavaScript 框架来构建我们的解决方案（鉴于有更多的 Java 经验）。

这些是支持我决定的事实。

100% 用 java 编写
需要基本的 Java 技能（Java SE 而不是 Java EE）
OOPHM – 进程外托管模式 – 定义您的浏览器和版本。浏览器兼容性不再是我们的问题
调试 - 使用 IDE 的调试器调试您的 GWT 应用程序，就像任何其他 Java 应用程序一样
优化的 JavaScript - GWT 编写的 JavaScript 比您更快、更紧凑

但是我的一些应用功能需要使用外部的js库。例如假设我需要使用一些特定的 js 库在特定页面上绘制一些东西。（其实就是dojos里写的那个js文件）。

GWT 能否满足上述要求？
您认为选择 GWT 的决定是明智的还是有其他建议？
我们发现 sencha gxt 拥有最好的小部件库（我知道它的商业用途，至少我找到了我们需要的所有小部件）。你认为在核心 GWT 上使用包装库是一个明智的主意吗？

提前致谢。

【问题讨论】：

CasperOne，你能推荐这个人（或任何人）在哪里可以问这种类型的问题吗？在一般编程领域，这是一个有效且有用的问题。这是否意味着 SO 没有空间为需要此类帮助的人提供服务？或许，问题应该转移到程序员那里？
大家好 - 这个问题已经结束（仍然认为这是一个有效的问题），所以我在评论我们的产品效果如何。
我们对 DOJO 非常满意，我们在 UI（视图）上进行了大量更改，而不会影响其背后的逻辑。所以我建议任何在 js 和 gwt 之类的框架之间折腾的人，尝试一下学习 JS 毕竟看起来还不错:)
我们尝试过基于 gwt 的框架 (Vaadin)，但最终由于可维护性差而在原型阶段失败。我们也对表演不满意。我们开始研究一个纯 JS 框架（Dojo 1.8），一年多来我们完全没有问题。我们花了一些时间才开始，但在你学习了基础知识之后并不难。我们已经在 UI（视图）上进行了大量更改，而不会影响其背后的逻辑。所以我建议任何在 js 和 gwt 等框架之间折腾的人，只要尝试学习 JS :)

标签： javascript gwt dojo vaadin gxt

【解决方案1】：

GWT 可以满足以上要求吗？

是的（请参阅@Andrey Kapelchik 的回答）。

您认为选择 GWT 的决定是明智的还是有其他建议？

鉴于您的背景和您提到的几点，我认为这是一个非常好的决定。我已经使用 JavaScript、jQuery 等构建了应用程序，但是对于超过 1000 行代码的任何内容，我不想再次“手动”构建 JavaScript 应用程序。对我来说具有决定性意义的几点：

使用 GWT，我可以在服务器端和客户端重复使用部分代码。例如，我可以在客户端进行验证以提供即时反馈，然后使用相同的代码在服务器上再次验证以确保安全。
我发现在大型 GWT 项目中我的方式要容易得多。虽然以清晰的方式排列甚至大型 JavaScript 代码当然是可能的，但它总是倾向于变得笨拙。
我一直在大量使用 IDE 功能（重构、查找对字段的写访问权限等），而 IDE 对 JavaScript 的支持对我来说太有限了。

你仍然需要一点点 JavaScript 知识。您的团队绝对应该学习 CSS，我建议您彻底学习它 - 无论您选择哪种客户端框架。

我们发现 sencha gxt 拥有最好的小部件库（我知道它的商业用途，至少我找到了我们需要的所有小部件）。您认为在核心 GWT 之上使用包装库是一个明智的主意吗？

在我正在进行的几个项目中，我们使用了 GXT，因为这个决定是在几年前做出的。以下是我的看法：如果您需要构建看起来非常像桌面应用程序的东西，GXT 可能是完美的，否则我不建议基于 GXT 应用程序。

使用纯 GWT 可以获得最佳性能，如果您了解 CSS，它会更加灵活。 GXT 有一些不错的功能，但要解决它的局限性、重大的性能问题（有时还有它的错误）可能非常耗时。如果您确实需要一个特殊的 GXT 小部件，您仍然可以构建一个纯 GWT 应用程序，然后只添加一个 GXT/SmartGWT 小部件。

【讨论】：

【解决方案2】：

在许多错误的开始之后，我的团队确实在这个问题上苦苦挣扎，我们确定 JavaScript 无法真正避免，掌握它并没有我担心的那么糟糕。升级 GWT 所需的时间与升级客户端 JS MVC 框架所需的时间大致相同。

我们确实考虑过 GWT，但放弃了它，因为从长远来看，由于以下原因，它会更难维护。

如果 GWT 的开发人员对维护它失去兴趣怎么办，维护像 GWT 这样的东西需要非常复杂的技能。
我们可能需要的小部件可能可用于其他 GWT，并且移植到 GWT 可能比我们想要做的工作要多。
现代 JavaScript MVC 框架变得非常成熟，具有许多非常酷的功能，可以轻松开发复杂的单页应用程序。
浏览器会变得更好，JS框架会变得更好，前端开发者会更容易......等等。

我们还对 dojo 进行了评估并放弃了它，因为我们觉得定制它对我们的团队来说太难了。这就是我们最终的结果。

用于 CSS / 小部件框架的 Twitter Bootstarp
一堆不同的jquery插件从网上各个地方争吵起来
用于客户端 MVC 框架的 JQuery、Backbone、Handlebars。

如果我今天重新开始这个项目，我会选择 Google 的 AngularJS，它确实是构建客户端 Web 应用程序的绝佳方法。尤其是因为在 JavaScript 中巧妙地使用了依赖注入以及双向绑定和一堆其他东西。我在 Throne of JS 会议上，谷歌 AngularJS 的人说他们将 17,000 行 GWT 应用程序移植到 2500 行 angularJS 应用程序。

【讨论】：

【解决方案3】：

我认为 GWT 非常适合您所描述项目的要求和目标。 GWT 有 JavaScript Native Interface 使用原生 JavaScript。 JSNI 允许将 GWT 与现有 JavaScript 或与外部 JS 库集成。它通过允许您将 JavaScript 直接集成到应用程序的 Java 源代码中来解决这些问题。

【讨论】：