单页应用程序与 PageAx [关闭]

Question

单页应用程序是众所周知的。但 PageAx 似乎鲜为人知。我在学习 MVC 时偶然发现了它，到目前为止它对我来说效果很好。

(注意：我知道这是一个可能被视为“无法回答”和“应该关闭”的话题，但我觉得这是一个尚未涵盖的重要话题。注意这是单页应用程序与 PageAx（不是 Ajax）。我正在寻找优点/缺点类型的讨论。我正在编造名称“PageAx”，因为我还没有找到更好的术语。）

SPA - 通过 Ajax 与控制器通信并返回 Json。

PageAx - 通过 Ajax 与控制器通信并返回部分视图来替换分割。

在我看来，PageAx 相对于 SPA 的优势如下：

1. 客户端上几乎没有 JavaScript。

2. 我发现在服务器端编写局部视图非常容易。

SPA 相对于 PageAx 的优势：

1. 我想不出来。

PageAx 优于 SPA 的缺点：

1. 负载稍大（但我怀疑最终用户是否能够辨别。）

2. 我想不出别的了。

SPA 相对于 PageAx 的缺点：

1. 似乎 JavaScript 和所需库的数量呈现出相当大的学习曲线（即，比 MVC 更多。）

所以要重申这个问题，SPA 与 PageAx 相比有什么优势吗？这个问题的基本原因是我正在开始另一个网络项目，需要决定采用哪种方式。

Answer 1

这取决于您的应用程序的复杂性。

返回 JSON 是有益的，因为这意味着您拥有一个成熟的 API，可以在移动应用程序或桌面客户端中重复使用。即使您后来决定完全重做您的前端，您也已经有了一个可立即使用的后端来编写代码。

另外，如果您的 web 应用程序是高度动态和交互式的，那么替换部分视图可能还不够。您可能希望更好地控制过渡（例如，为它们设置动画）。例如，请参阅Medium-Style Page Transitions：您不能对部分 AJAX 视图执行此类操作。

另一方面，如果这种灵活性对您没有任何好处，那么在服务器上渲染部分视图可能对您很有效。这是David from 37signals blogging about it。他将这种方法称为 SJR（服务器生成的 JavaScript 响应）：

这并不意味着没有地方可以在服务器上生成 JSON 和在客户端上生成视图。我们针对 UI 保真度非常高且维护大量视图状态的少数情况（例如我们的日历）这样做。当需要这条路线时，我们会使用 Sam 出色的 Eco 模板系统（想想 CoffeeScript 的 ERB）。

如果您的 Web 应用程序都是高保真 UI，那么一路走这条路是完全合法的。你付出了高昂的代价给自己买了一些花哨的东西。没有汗水。但是，如果您的应用程序更像 Basecamp 或 Github 或网络上大多数以其基于文档的根源而自豪的应用程序，那么您真的应该张开双臂拥抱 SJR。