我读过SPA和它的优点。我发现他们中的大多数都没有说服力。有3个优点引起了我的怀疑。
问:你能作为SPA的倡导者，证明我的前三个陈述是错误的吗?
=== ADVANTAGES ===
1. SPA非常适合响应性非常强的网站:
服务器端呈现很难为所有的中间体实现
状态——小视图状态不能很好地映射到url。
单页应用程序的特点是它们能够重绘任何部分
的UI，而不需要服务器往返检索HTML。这
是通过将数据与数据的表示分开来实现的
拥有处理数据的模型层和读取数据的视图层
从模型中。
为非spa保留模型层有什么问题?SPA是唯一在客户端与MVC兼容的架构吗?
2. 使用SPA，我们不需要对服务器使用额外的查询来下载页面。
哈，用户在访问你的网站时可以下载多少页面?2、3 ?相反，出现了另一个安全问题，你需要把你的登录页面，管理页面等分开到单独的页面。反过来，它又与SPA体系结构冲突。
3.还有其他的优势吗?别再听别人说了。
=== DISADVANTAGES ===
客户端必须启用javascript。
只有一个入口。
安全。
附注:我做过SPA项目和非SPA项目。我问这些问题是因为我需要加深我的理解。没有伤害七党联盟支持者的意思。不要让我读更多关于SPA的东西。我只是想听听你对此的看法。
SPA - SEO的一个主要缺点。直到最近谷歌和Bing才开始通过在爬行过程中执行JavaScript来索引基于ajax的页面，但在许多情况下，页面仍然被错误地索引。
在开发SPA时，您将被迫处理SEO问题，可能是通过后渲染所有站点和创建静态html快照供爬虫使用。这将需要对适当的基础设施进行坚实的投资。
更新19.06.16:
自从前段时间写了这个答案，我在单页应用(即AngularJS 1.x)方面获得了更多的经验——所以我有更多的信息可以分享。
In my opinion, the main disadvantage of SPA applications is SEO, making them limited to kind of "dashboard" apps only. In addition, you are going to have a much harder times with caching, compared to classic solutions. For example, in ASP.NET caching is extreamly easy - just turn on OutputCaching and you are good: the whole HTML page will be cached according to URL (or any other parameters). However, in SPA you will need to handle caching yourself (by using some solutions like second level cache, template caching, etc..).
缺点:
从技术上讲，SPA的设计和初始开发是复杂的，可以避免。不使用这种SPA的其他原因可能是:
a) Security: Single Page Application is less secure as compared to traditional pages due to cross site scripting(XSS).
b) Memory Leak: Memory leak in JavaScript can even cause powerful Computer to slow down. As traditional websites encourage to navigate among pages, thus any memory leak caused by previous page is almost cleansed leaving less residue behind.
c) Client must enable JavaScript to run SPA, but in multi-page application JavaScript can be completely avoided.
d) SPA grows to optimal size, cause long waiting time. Eg: Working on Gmail with slower connection.
除此之外，其他架构的限制是导航数据丢失，浏览器中没有导航历史记录，以及使用selenium难以进行自动化功能测试。
这个链接解释了单页应用程序的优点和缺点。
对于谷歌、亚马逊等公司来说，他们的服务器在24/7模式下以最大容量运行，减少流量意味着真正的金钱——更少的硬件、更少的能源、更少的维护。将cpu使用从服务器转移到客户端是有回报的，spa大放异彩。到目前为止，利大于弊。
所以，SPA与否很大程度上取决于用例。
只是为了提到另一个可能不那么明显(对于web开发人员)的spa用例:
我目前正在寻找一种在嵌入式系统中实现gui的方法，基于浏览器的架构似乎对我很有吸引力。传统上，嵌入式系统中的ui没有太多的可能性——Java、Qt、wx等或适当的商业框架。几年前，Adobe试图通过flash进入市场，但似乎并不成功。
如今，由于“嵌入式系统”与几年前的大型机一样强大，基于浏览器的UI通过REST连接到控制单元是一种可能的解决方案。这样做的好处是，为用户界面提供了大量的工具，而且是免费的。(例如Qt需要20-30美元/销售单位的特许权使用费加上3000-4000美元/开发者)
对于这样的架构，SPA提供了许多优势——例如，桌面应用程序开发人员更熟悉的开发方法，减少服务器访问(通常在汽车行业，UI和系统混乱是分开的硬件，其中系统部分有一个RT操作系统)。
由于唯一的客户端是内置的浏览器，上面提到的js可用性、服务器端日志记录、安全性等缺点都不再重要。
SPA - SEO的一个主要缺点。直到最近谷歌和Bing才开始通过在爬行过程中执行JavaScript来索引基于ajax的页面，但在许多情况下，页面仍然被错误地索引。
在开发SPA时，您将被迫处理SEO问题，可能是通过后渲染所有站点和创建静态html快照供爬虫使用。这将需要对适当的基础设施进行坚实的投资。
更新19.06.16:
自从前段时间写了这个答案，我在单页应用(即AngularJS 1.x)方面获得了更多的经验——所以我有更多的信息可以分享。
In my opinion, the main disadvantage of SPA applications is SEO, making them limited to kind of "dashboard" apps only. In addition, you are going to have a much harder times with caching, compared to classic solutions. For example, in ASP.NET caching is extreamly easy - just turn on OutputCaching and you are good: the whole HTML page will be cached according to URL (or any other parameters). However, in SPA you will need to handle caching yourself (by using some solutions like second level cache, template caching, etc..).
我想说明的是，SPA最适合数据驱动应用程序。gmail当然是关于数据的，因此是SPA的一个很好的候选。
但是，如果您的页面主要用于显示，例如，服务条款页面，那么SPA就完全多余了。
我认为最好的地方是拥有一个混合了SPA和静态/MVC样式页面的站点，这取决于特定的页面。
例如，在我正在构建的一个站点上，用户访问了一个标准的MVC索引页。但当它们进入实际应用程序时，它会调用SPA。这样做的另一个好处是，SPA的加载时间不在主页上，而是在应用程序页面上。首页的加载时间可能会让第一次访问网站的用户分心。
这个场景有点像使用Flash。经过几年的经验，由于加载因素，只使用Flash的网站数量几乎为零。但作为页面组件，它仍在使用中。
