通过 Javascript 渲染客户端 UI 是个好主意吗？答案

【问题标题】：Is client-side UI rendering via Javascript a good idea?通过 Javascript 渲染客户端 UI 是个好主意吗？
【发布时间】：2009-06-29 18:45:50
【问题描述】：

一段时间以来，Web 开发的“经典”方法一直是瘦客户端和胖服务器：服务器生成 HTML 并将其输出以供浏览器仅呈现。但是对于当前的浏览器（也由于良好的库和框架的可用性），Javascript 现在可以工作了。 Web 开发人员现在几乎可以假设他们的 Javascript 代码可以工作并且不再麻烦了。

这无疑为 Web 开发开辟了新的可能性。应用程序现在可以主要由从服务器返回并由浏览器呈现的 HTML 内容组成，其中一些 UI 操作在客户端完成。客户端甚至可以向服务器查询新数据以更新部分 UI。但是我们可以一直走下去吗？一个应用程序当然可以设计为一个服务器，它只将最简约的 JSON 粘在一起，连接到一个负责构建和控制整个用户界面的厚 Javascript 客户端。是的，这种方法会严重破坏 URL，以至于人们无法再发送指针，但当然可以设计自己的方式来解决这个问题（对于某些应用程序，如电子邮件和提要阅读器，这甚至不问题）。

你怎么看？你有没有尝试过这种方法？事情变得太慢了吗？现代浏览器是否能够处理这么多的 Javascript 代码？即使使用最新的库，浏览器实现之间是否存在任何显着差异，仍然会咬住不知情的开发人员？您认为这种方法适用于哪些类型的应用程序？它真的适合任何东西吗？

【问题讨论】：

对于那些仍然找到这个页面的人：看看Web Components，似乎这将是未来。

标签： javascript

【解决方案1】：

我正处于构建此类应用程序的最后阶段。它是 Zend Framework JSON-RPC Web 服务之上的 ExtJS GUI，实现了类似 iGoogle 的小工具门户。

优点：

响应迅速的 UI，ExtJS 为您提供出色的用户体验。
非常可预测的客户端-服务器通信。一切都是 json（易于调试）。 API 中固有的标准化错误处理（至少我是这样设计的）。
前端是可更换的。我可以在同一个服务器后端上编写一个 C++ 应用程序。跨客户端-服务器线分离前端和后端意味着它们更容易独立测试。
您可以生活和呼吸 javascript，如果您喜欢它，那就太好了。

缺点：

你必须生活和呼吸 javascript，如果你讨厌它，那就太糟糕了。在我们的案例中，这意味着对开发团队进行重大的再培训，因为我们使用 PHP。
一切都存在于一个长期存在的 DOM 中，因此您必须时刻注意内存管理并确保正确清理内容。此外，加载过多的 UI 会使 IE 发出“哇，哇，你伤了我的大脑”。
在生成 UI 的过程中没有运行快速查询来获取选项。居住在客户端的程序设计限制起初是令人生畏的。你习惯了，但这有点障碍。
加载所有 javascript 意味着您的用户需要快速连接和现代浏览器。

我们这样做的主要原因是为了提供更好的用户体验。用户期望获得类似桌面的体验，而您无法通过服务器往返提供这种体验。我们现在就可以实现这一点，但不可否认的是，这种方法存在巨大挑战。不过总的来说我很满意。

更新（2013 年 9 月）：

如果您正在构建真正的 Web 应用程序（而不仅仅是具有一些动态功能的网页），那么仍然使用这种架构并且仍然认为它是正确的架构。我们的团队和产品现在要大得多（接近 500.000 行代码），但架构已经扩展而没有问题。现在有许多非常好的可扩展 javascript 框架（angular、ember、...），因此采用这种工作方式比以往任何时候都容易。

因为@rwoo 的要求，我们仍然面临一些挑战：

js 代码的按需加载是一个比预期更棘手的问题。在您的架构中正确使用这部分非常重要。
我们不得不将自动 jshint 验证集成到 subversion 的预提交挂钩中，因为 js 对语法错误的容忍度太高，而且您通常在产品到达客户手中时才注意到这一点。
由于数据库位于 Web 服务请求的另一端，因此您必须仔细设计 Web 服务 API，否则会因等待太多 XHR 请求而导致性能不佳。这是可以解决的，但具有挑战性，而且随着时间的推移不会变得更容易。
虽然使用正确的框架可以最大限度地减少跨浏览器问题，但它们并没有完全消失，这意味着您需要在所有浏览器、所有版本中进行测试。这是太多的工作，你必须使用 selenium 之类的东西来自动化它，事实证明，用客户端渲染的 UI 比服务器端渲染的 UI 更难做到这一点。

【讨论】：

如果您的目标是提供类似桌面的用户体验，那么也许您应该构建一个桌面应用程序。只是说'.. ;)
实际上，我正在构建这些网络应用程序来替换我们已经构建的桌面软件。我们的客户希望在开放的互联网上托管应用程序，并拥有快速变化的用户群（例如外部承包商），因此他们明确要求我们提供 Web 应用程序，而不是我们已经拥有的桌面应用程序。我对这种新架构的目标是让我们能够在构建原生桌面应用的同时构建类似桌面的网络应用。
我即将启动一个伟大的 Web 端口，但我一直认为 HTML/CSS/JavaScript 应用程序很难调试。你怎么看？
@Dimitri：过去几年调试体验有了很大改善。 Firebug、chrome 检查器、IE 8 的开发者工具，它们都已经“足够好”了。我也在 delphi 工作，但我发现调试起来并不容易。如果您在 CSS 中对布局进行手工编码，您仍然会有很糟糕的调试体验，但是使用适当的框架可以避免这种情况。
这听起来很有希望！我正在尽最大努力相信这一点；-) 感谢您分享您的意见。

【解决方案2】：

您关于 Web 开发人员现在可以“几乎假设他们的 Javascript 代码正在运行”的断言很难同意。以我的经验，Javascript 几乎总是一个黑洞，你可以提供它所有的时间和精力。 Prototype 和 Script.aculo.us 之类的框架让事情变得更好了，但它们还没有像您的问题所假设的那样硬化。

两个主要问题一是浏览器支持，二是开发时间。您依赖一个您无法控制的应用程序来处理应用程序的大部分工作负载。即使对浏览器进行最细微的更新也可以打破这一事实，这让我很担心。在服务器端生成 HTML 可以在很大程度上减轻这种风险。开发丰富的 Javascript 前端非常耗时，难以调试，并且同样难以在各种可用浏览器中进行测试。

虽然这些担忧是真实存在的，但您可以通过客户端 Javascript 实现一些出色的用户体验这一事实不容忽视。我之前提到的框架暴露了一两年前甚至没有想到的功能，因此，在某些情况下，前期开发成本在很大程度上是值得的（当框架得到有效实施时，有时会显着缩短）。

我认为有适用于 Javascript 驱动的 UI 的应用程序，只要经过深思熟虑的决定走这条路。如果不是因为使用这种策略的 UI 潜力很棒，我们不会在 SO 上讨论这个。使用基于 Web 的数据的基于 Web 的应用程序是完美的候选者（RSS、REST 服务）。反复访问关系数据库或复杂 Web 服务的应用程序必然会与服务器端保持更紧密的耦合。

我的 2 美分。

【讨论】：

【解决方案3】：

诸如Google GWT 之类的工具可以按照您的描述进行 - 在 javascript 中渲染大部分客户端。一些粗粒度的布局仍然使用 HTML，但有趣的部分是在客户端动态完成的。

但 GWT 使用生成的 javascript，而不是手写。手动操作很痛苦。

【讨论】：

【解决方案4】：

我是手工完成的。这有点痛苦，但有一些好处。这仅适用于后备没有意义的富 Internet 应用程序。我想我们会看到越来越多的应用需要 JavaScript，尤其是在 Cappuccino Atlas 这样的框架出现之后。

【讨论】：

【解决方案5】：

我认为这很可怕。很难发展。很难调试。很难得到你想要的功能。我更喜欢让 Web 应用程序尽可能简单，并在需要更复杂的东西时使用普通的 GUI 应用程序。

【讨论】：

我认为桌面上的 GUI 应用程序将会消失。或者至少越来越多的它们将使用网络技术制作。不过，只是我的看法。我已经在 AIR 中做了一些内部工具，我期待在 Appcelerator Titanium 中做一些 Python/JS。
好像是这样，会伤害到用户。
这是普遍听到的意见。但我认为问题在于，它通常是由大部分时间花在互联网上的人提供的。互联网永远不会成为软件行业的主要媒介。
如果您不使用框架，Web 开发会很痛苦，但在正确的框架上与桌面开发的差异很小。

【解决方案6】：

ExtJS、YUI、dojo... 框架基本上可以帮助您实现您所描述的应用程序

我们（在我的工作场所）成功地为许多大型和小型应用程序使用了这种方法...一般来说，我们的大多数应用程序基于 ExtJS+jQuery，在某些情况下基于 dojo(Zend Framework(如果你关心PHP 世界）提供与 dojo 元素的便捷集成）

如果它没有被滥用并且只是为了使用它或增加凉爽因素 - 它是一个很棒的工具。

通过适当的设计，它本身既不重也不慢。

【讨论】：

【解决方案7】：

我喜欢实施混合方法。当第一次请求一个页面时，它应该填充尽可能多的信息，你可以从 URL/Querystring/Post 推断出。然后可以使用 Ajax 查询和更新任何后续状态更改。

很多人倾向于采取简单加载页面的方法，然后让 javascript/ajax 完成加载工作。这会导致客户端等待页面加载，然后客户端等待数据加载。

让服务器完成初始数据加载并填充所有 UI 元素会更好。

【讨论】：

【解决方案8】：

如果我正确理解您的问题，我认为您指的是使用 ExtJS 之类的开发。使用 Ext，您不再需要真正编写任何 HTML，而是主要使用 JavaScript 设计整个应用程序，使用类似于在桌面上开发 GUI 应用程序的技术。

在大多数情况下，现代工具包几乎消除了大多数浏览器怪癖。尽管您当然仍然偶尔会遇到跨浏览器渲染问题，但这并不像您尝试自己编写所有 JS 那样大。即使在 IE6 中速度也应该是可以接受的，尽管您通常会在最近版本的 Safari、Chrome 或 Firefox 中获得更好的性能。（我对 IE7 或 8 了解不多，无法评论）。

您提出了一个关于 URL 及其共享能力的有效观点。即使在共享数据的用例之外，这对于在应用程序中为位置添加书签也很重要。有一些技术可用于存储应用程序状态并能够重建它，但据我所知，这仍然不容易做到。因此，在不需要的情况下避免使用富 Web 应用程序是有意义的。更简单的 Web 应用程序可以更简单地调试、测试和维护。

也就是说，在某些情况下，富 Web 应用程序很有意义。例如，许多内部企业桌面应用程序可以重写为富 Web 应用程序。它们可以提供与桌面应用程序相似的外观和感觉、小部件和交互模式，从而更容易过渡到 Web 应用程序。涉及操作数据的面向外部的应用程序（如电子邮件/新闻阅读器、会计应用程序等）也非常适合。

【讨论】：

【解决方案9】：

对于可以控制桌面的内部使用的业务线应用程序，javascript 是有意义的。

对于您不知道您的消费者使用什么浏览器的外部/公众应用程序，请保持简单并尽可能少使用。

当您说 Javascript 现在由于框架而可以工作时，这并不完全正确。 IE 6 仍在广泛使用，旧版 Safari 也是如此。即使是 FF 2.x 和某种程度上的 1.x，在消费市场上也占有相当大的份额。

除此之外，并不是每个人都拥有高速互联网，这几乎是许多此类框架的要求。此外，尽管大多数库都使用 IE 7，但它对于大多数操作来说都是一条狗。

关于库大小，我们有许多 .net 控件，它们喜欢向客户端注入最多 1MB 的 javascript。正在尝试将其发送给奶奶。

最后，手机将用户作为主要的互联网访问设备。不幸的是，它们的缓存很小，而且在大多数情况下，那些很酷的 javascript 东西不能很好地工作。

【讨论】：

一些反驳：jQuery（以及其他）在 IE6 上工作得很好。高速不是框架的要求，只是因为第一次下载可能需要更长的时间，除非您的服务器配置错误，否则后续请求可能会被缓存。我同意 IE 执行脚本的速度很慢，但 IMO 这通常很好，用户应该使用那些糟糕的浏览器获得较差的体验以让他们升级。 .NET 控件注入 1MB 的 javascript，这是您使用它们的选择，不是必需的。对于手机、iPhone 或 Opera 手机，nuff 说。
访问者访问缓慢站点的不幸副作用是访问者倾向于不返回。如果加载您的网站需要 5 秒钟，除非有真正令人信服的理由，否则大多数人不会回来。例如，如果他们通过您的网站支付水费。

【解决方案10】：

YUI 剧院有一段我认为与您的问题高度相关的视频 - 我强烈建议您观看它

High-performance JavaScript: Why Everything You've Been Taught Is Wrong

标题有点误导，但他实际上谈到了你所面临的问题。

【讨论】：