Ajax 单页应用与PageAx

单页应用程序是众所周知的。但PageAx似乎不太为人所知。我在学习MVC的过程中偶然发现了它，到目前为止，它对我来说非常有效

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

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

PageAx-通过Ajax与控制器通信，并返回替换分区的部分视图

在我看来，PageAx比SPA的优势如下：

客户端上几乎没有JavaScript

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

SPA相对于PageAx的优势：

我想不出有什么

PageAx优于SPA的缺点：

稍微大一点的有效载荷（但我怀疑最终用户是否能识别）

我想不出别的了

SPA优于PageAx的缺点：

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

---

再次重申这个问题，SPA比PageAx有什么优势吗？这个问题的基本原因是我正在启动另一个web项目，需要决定采用哪种方式。这取决于应用程序的复杂性

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

此外，如果您的webapp具有高度动态性和交互性，则仅替换部分视图可能不够。您可能希望对过渡进行更好的控制（例如设置过渡动画）。例如，请参见：对于部分AJAX视图，您无法执行类似的操作

另一方面，如果这种灵活性不能为您带来任何好处，那么在服务器上呈现部分视图可能会非常适合您。给你。他将这种方法称为SJR（服务器生成的JavaScript响应）：

这并不意味着没有地方在服务器上生成JSON，在客户机上生成视图。我们这样做是为了少数情况下，用户界面保真度非常高，许多视图状态被维护，如我们的日历。当需要这条路线时，我们使用Sam优秀的生态模板系统（想想咖啡脚本的ERB）

如果您的web应用程序都是高保真的UI，那么一直走这条路是完全合法的。你为自己买些花哨的东西付出了高昂的代价。举手之劳但是，如果您的应用程序更像Basecamp或Github，或者web上的大多数应用程序都以基于文档的根为傲，那么您真的应该张开双臂拥抱SJR

---

在StackOverflow上，关于推荐工具或框架或比较工具或框架的问题是离题的。您的问题现在将结束。@Darin：这不是关于工具和框架，而是关于比较方法。请重新阅读问题。谢谢，这非常有帮助。我的应用程序非常像Basecamp——更多的是关于数据，而不是关于高UI保真度。因此，部分Ajax视图似乎是一个不错的选择。