通过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美分。

Answer 3

Google GWT等工具按照您的描述进行操作 - 在javascript中渲染大部分客户端。一些粗粒度布局仍然使用HTML来降低，但有趣的位是在客户端动态完成的。

但是GWT使用生成的javascript，而不是手写的。用手做这件事很痛苦。

Answer 4

ExtJS，YUI，dojo ...基本上提供实施应用程序的框架，例如您正在描述的应用程序

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

如果它没有被滥用并仅仅是为了使用它或碰到冷却因子 - 它是一个很棒的工具。

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

Answer 5

我手工完成了。这有点痛苦，但有一些好处。这仅适用于富有的互联网应用程序，其中回退毫无意义。我想我们会看到越来越多需要JavaScript的应用，特别是在Cappuccino Atlas之类的框架到来之后。

Answer 6

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

Answer 7

如果我理解你的问题，我认为你指的是像ExtJS这样的开发。使用Ext，您不再真正编写任何HTML，而是使用与桌面上的开发GUI应用程序类似的技术，在大多数JavaScript中设计整个应用程序。

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

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

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

Answer 8

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

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

让服务器执行初始数据加载并填充所有UI元素要好得多。

Answer 9

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

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

当你说Javascript现在因框架而起作用时，情况并非如此。 IE 6仍然广泛使用，旧的Safari也是如此。甚至FF 2.x和1.x在某种程度上也占有相当大的消费市场份额。

除此之外，并非每个人都拥有高速互联网，这对很多这些框架来说都是必需的。此外，虽然大多数图书馆都使用IE 7，但它对于大多数操作来说都是一只狗。

关于库大小的问题，我们有许多.net控件，它们喜欢向客户端注入多达1MB的javascript。试着把它寄给奶奶。

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

Answer 10

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

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

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