通过Javascript进行客户端UI渲染是一个好主意吗？

Question

Web开发的"经典"方法有一段时间以来一直是瘦客户端和厚服务器:服务器生成HTML并将其吐出以供浏览器仅呈现.但是对于当前的浏览器(以及由于良好的库和框​​架的可用性),Javascript现在可以工作了.Web开发人员现在几乎可以假设他们的Javascript代码可以工作并且不再烦恼.

这无疑为网络开发开辟了新的可能性.应用程序现在可以主要由从服务器返回并由浏览器呈现的HTML内容组成,其中一些UI操作在客户端完成.客户端甚至可以向服务器查询用于更新UI部分的新数据.但是我们可以继续下去吗？一个应用程序当然可以设计为一个服务器,只将最简约的JSON粘合到一个厚厚的Javascript客户端,负责构建和控制整个用户界面.是的,这种方法可以严重破坏URL到人们不能再发送指针的程度,但是当然可以设计你的方式(对于某些应用程序,如电子邮件和提要阅读器,这甚至都没有物).

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

Answer 1

我正在构建这种应用程序的尾声.它是一个基于Zend Framework JSON-RPC Web服务的ExtJS GUI,实现了类似iGoogle的小工具门户.

好处:

• ExtJS响应非常灵敏,为您提供出色的用户体验.
• 非常可预测的客户端 - 服务器通信.一切都是json(易于调试).API中固有的标准化错误处理(至少我是如何设计的).
• 前端是可更换的.我可以在同一台服务器后端编写一个C++应用程序.跨客户端 - 服务器线分离前端和后端意味着它们更容易独立测试.
• 你可以生活和呼吸javascript,如果你喜欢的话,这很棒.

缺点:

• 你必须生活和呼吸javascript,如果你讨厌它会很糟糕.在我们的例子中,这意味着开发人员团队的重新培训,因为我们是PHP重的.
• 所有东西都存在于一个长寿命的DOM中,所以你必须保持内存管理并确保正确清理内容.此外,加载过多的UI会让IE变得"流淌,因为你伤害了我的大脑".
• 在生成UI的过程中,没有运行快速查询来获取选项.生活在客户端的程序设计限制起初是令人生畏的.你已经习惯了,但这有点障碍.
• 加载所有javascript意味着您的用户需要快速连接和现代浏览器.

我们这样做的驱动原因是提供更好的用户体验.用户希望获得类似桌面的体验,并且无法通过服务器往返提供这种体验.我们现在可以实现这一目标,但无可否认,这样的方法存在巨大挑战.总的来说,我很满意.

更新(2013年9月):

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

因为@rwoo问,我们还有一些挑战:

• 按需加载js代码比预见的更棘手.在您的架构中正确使用这一部分非常重要.
• 我们不得不在subversion中的预提交钩子中集成自动jshint验证,因为js过于容忍语法错误,并且在产品到达客户之前通常不会注意到这一点.
• 由于数据库位于Web服务请求的另一端,因此您必须仔细设计Web服务API,否则由于等待太多XHR请求而最终会导致糟糕的性能.这是可以解决的,但具有挑战性,随着时间的推移它并不容易.
• 虽然使用正确的框架,跨浏览器的问题最小化,但它们并没有完全消失,这意味着您需要在所有浏览器中测试所有版本.这是太多的工作,你必须使用像selenium这样的东西自动化它,并且事实证明这对于客户端呈现的UI比服务器端呈现的UI更难.

Answer 2

你的断言,网络开发人员现在"几乎可以假设他们的Javascript代码正常工作"是一个很难同意的人.根据我的经验,Javascript几乎总是一个黑洞,一直吸吮你能提供它的能量.像Prototype和Script.aculo.us这样的框架使事情变得更好,但它们还没有像你的问题所假设的那样强硬.

两个主要问题是一个,浏览器支持和两个是开发时间.您依靠的是无法控制的应用程序来处理应用程序的大部分工作量.即使对浏览器进行最小的更新,这也可以解决这个问题.生成HTML服务器端可以在很大程度上缓解这种风险.开发丰富的Javascript前端非常耗时,难以调试,同样难以在各种可用浏览器中进行测试.

虽然这些问题是真实的,但您可以通过客户端Javascript实现一些出色的用户体验这一事实不容忽视.我之前提到的框架暴露了一两年前甚至没有梦想的功能,因此在某些情况下使前期开发价格在很大程度上是值得的(当框架有效实施时有时会大大缩短).

我认为有一个基于Javascript的UI的应用程序,只要决定走这条路线是经过深思熟虑的.我们不会讨论这个问题,因为不是因为使用这种策略的UI潜力很棒.使用基于Web的数据的基于Web的应用程序是完美的候选者(RSS,REST服务).重复使用关系数据库或复杂Web服务的应用程序必然会与服务器端保持更紧密的耦合.

我的2美分.