开发人员使用复杂JavaScript UI的方法

我试图了解围绕复杂的客户端JavaScript开发的不同方法和最佳实践的前景。

我不确定用什么来标记此类应用程序，也许是沉重的AJAX或RIA（但不能像Flash / Silverlight这样的插件）。我指的是具有以下特征的Web应用程序：

• 在JavaScript中模拟丰富/本地桌面UX
• 使用服务器作为数据API（JSON / Html-Templates），包含客户端JS中的大多数/所有行为。

这与使用Web服务器进行UI呈现相反，后者以页面刷新模型生成所有HTML。

一些例子是：

• Google文件/ Gmail
• 迈德迈斯特
• 关键跟踪器

随着我们逐步进入HTML5，我可以看到这种带有大量JavaScript的RIA开发风格变得越来越普遍和竞争所必需。

问题：那么，围绕这些大量的JS开发进行管理的通用方法是什么？

随着应用功能的增加，客户端代码非常复杂。使用原始JS在多个团队之间扩展开发工作时遇到了问题（或者，我听到了，并且完全可以相信）。

Google通过构建可从高级语言（Java）编译为JS的GWT来解决此问题，它依靠高级语言具有的现有开发基础结构（Eclipse，强类型，重构工具）以及抽象的浏览器兼容性和开发人员无法解决的其他问题。

还有其他工具，例如用于C＃的Script＃，其功能也类似。所有这些使JS更加具有IL（中间语言）的作用。即。“您再也不会真正用这种'低级语言'来写作了。”

但是，这种“编译为JS”并不是唯一的方法。尚不清楚GWT是占主导地位的方法...或确实会成为它。

人们在使用富客户端JavaScript做什么？一些定向问题：

• 大多数商店都在手工制作JS（在jQuery等类似的库上面）吗？
• 还是有许多不同的方法，没有明确的最佳实践？
• 大多数商店是否都在避免RIA规模开发，而转向更简单的开发人员服务器端/页面重绘模型？如果是这样，这会持续吗？
• 编译为JS可能是一种新兴的未来趋势吗？还是这是错误的方向？
• 他们如何管理客户端JS的复杂性和重构？
• 跨团队模块化和分配工作？
• 客户端模式（例如MVC / MVP等）的应用，实施和测试。

那么，在我们这个庞大的JavaScript和HTML5未来中，新兴趋势是什么？

谢谢！

我看到的大多数Web应用程序（以及与我交谈过的Web开发人员）都朝着这个方向发展，它们都以jQuery为基础。

GWT（和类似的多层次语言）背后的全部原因是JavaScript对于“真正的程序员”来说过于脆弱/太脆弱/太易变。但是，如果您有一个框架可以为您处理flakey /脆弱/可更改位，那么就没有理由增加这一额外的复杂性。

只是我的观点…

我会说GWT有风险。一旦决定使用它，就会被它所困扰。基本上，这意味着您将标记，DOM和CSS的某些方面视为执行环境。随着客户端代码变得越来越复杂，将手动编写的JavaScript与GWT混合变得越来越困难。GWT有本机方法，但在适用性方面受到很大限制。这是一个很大的折衷，也是一个很大的赌注。

Google试图将GWT出售为具有良好服务器端集成的非常快速的X平台执行环境。但是，正如其他人已经指出的那样，情况已不再是-JQuery和YUI甚至快得多。而且，在手动组装页面时，对页面进行概要分析和优化要容易得多，因此您可以完全控制CSS，标记和JavaScript。

GWT试图向您隐藏基础平台，这实际上可能是做事的错误方法。许多所谓的组件网络框架都做同样的事情。您应该编写带有EL和自定义标记的含糊的XML派生代码。输出将是一堆格式不正确的HTML，并散布着一小段of脚的JavaScript。页面运行缓慢，有故障且完全无法维护。

在我们当前的项目中，我们使用Stripes（基于操作的低级框架）和客户端上的JQuery。一旦清楚地看到了所有难题，就很容易做Ajax：这是对数据进行操作的服务器端代码。这是您的客户端代码-用于数据检索和使事情发生在页面上。这是您的CSS，这是您的标记，这是您的模板-一切都是干净的和分离的。易于扩展，可破解，可调整和可调试。我喜欢它。

我喜欢JQuery，它对速度和简单性的态度。我喜欢YUI3的模块化和全面的小部件。我喜欢YUI CSS，因为它可以使我在浏览器之间保持一致。我喜欢JavaScript for Good Parts。我喜欢Java让我完成工作。

只是吻，你会没事的！

我听说过这些叫做“单页应用程序”的文件。

这是一个新环境，规则尚未完全编写。去年（2010年），我开发了一个相对主要的单页应用程序，这些是我们使用的工具。

后端是Java，使用servlet提供JSON服务，该页面最终用来提交准备好的订单。该服务还用于某些验证步骤和定价。

前端代码是javascript。我们使用jQuery来处理页面元素，使用Pure进行模板处理，并使用RequireJs将代码分成模块。（RequireJs的构建工具用于提供更多最佳下载。）

我们使用qUnit编写了测试，并进行了一个jUnit测试，该测试使用htmlunit运行每个qUnit测试，然后抓取输出以获取结果，并根据qUnit通过/失败状态通过或失败。这些被添加到后端的jUnit测试中，并使用Hudson / Jenkins纳入了我们的ci 。

我正在开发基于Ext JS的此类应用程序。该应用程序是模块化组织的。不同的模块被实现为自包含组件，当它们从Ext组件层次结构中删除时，它们会自行清理。按需加载程序会在需要时立即加载其他组件（一个js文件=一个组件）。

我发现这种方法并不难扩展。我遇到的唯一实际限制与IE中同时在树中包含太多DOM元素有关。那里的解决方案是从策略上卸载应用程序的隐藏部分。因为所有DOM操作都是通过Ext组件层次结构进行的，所以DOM几乎被完全抽象掉了，并且开发仍然很简单。

我个人认为，jQuery之类的框架不仅对于处理不同浏览器之间的差异至关重要，而且对于消除这些差异也很重要，这样它们才不会给代码增加噪音。GWT，Websharper和其他工具之类的工具走得更远，而且肯定占有一席之地，但是我想知道在大多数情况下，这是否只是间接的额外一层。

我很惊讶没有人提到的是单元测试。现在已经普遍接受，复杂的服务器端应用程序应该具有自动化的单元测试，并且我认为RIA应用程序中的JS已经足够复杂，需要进行单元测试了，同时还有使之成为可能的体系结构/代码已经到了。

但是，与复杂的服务器端应用程序不同，根据我所看到和听到的经验，我的直觉是绝大多数复杂的客户端应用程序绝对没有单元测试（我这里不是在谈论硒测试，而是真正的单元测试）。

我认为下一个新兴趋势将是引入单元测试（以及可单元测试的代码）。刚完成了一个包含少量未经单元测试的JavaScript的项目，我希望它将是最后一个。