问题描述
让我们看一下最受欢迎的SPA网站之一，GMail。
服务器端呈现的难度不像使用简单技术（例如在URL中保留#hash或最近在HTML5中pushState保留）那样困难。通过这种方法，Web应用程序的确切状态将嵌入到页面URL中。与每次打开邮件一样，在GMail中，特殊的哈希标签会添加到URL。如果复制并粘贴到其他浏览器窗口，则可以打开完全相同的邮件（前提是它们可以进行身份验证）。这种方法直接映射到更传统的查询字符串，不同之处仅在于执行。使用HTML5pushState（），您可以消除#hash和使用完全经典的URL，它们可以在第一个请求上在服务器上解析，然后在后续请求上通过ajax加载。
用户访问我的网站时下载的页面数？当他/她打开他/她的邮件帐户时，实际上阅读了多少邮件。我一口气读了> 50。现在邮件的结构几乎相同。如果您将使用服务器端渲染方案，则服务器将在每个请求（典型情况）下对其进行渲染。-安全问题-您应该/不应为完全取决于您网站结构的管理员/登录页面保留单独的页面，以paytm.com为例，例如，制作网站SPA并不意味着您为所有网站打开了所有端点。用户，我的意思是我在我的spa网站上使用表单身份验证。-在可能最常用的SPA框架Angular JS中，开发人员可以从网站上加载整个html模板，从而可以根据用户身份验证级别来完成。为所有身份验证类型预加载html是“
- 这些天，您可以放心地假设客户端将具有启用了JavaScript的浏览器。
- 网站的一个入口。正如我之前提到的，状态维护是可能的，您可以根据需要拥有任意数量的入口点，但是应该确定有一个。
- 即使在SPA用户中，也只能看到他具有适当的权限。您不必一次注入所有东西。加载差异html模板和javascript异步也是SPA的有效部分。
- 现在，每个访问您网站的用户都在执行HTML渲染，因此显然需要一些资源。现在，不仅渲染主要逻辑都在客户端而不是服务器端完成。
- 日期时间问题-我只是给客户端提供UTC时间是一种预设格式，甚至不关心我让JavaScript处理的时区。这对于我不得不根据用户IP派生的位置猜测时区是一个很大的优势。
- 对我来说，状态可以更好地保存在SPA中，因为一旦设置了变量，便知道该变量将在那里。这给人一种开发应用而不是网页的感觉。这通常对制作类似foodpanda，flipkart，亚马逊之类的网站有很大帮助。因为如果您不使用客户端状态，那么您将使用昂贵的会话。
- 网站肯定是非常敏感的-我将举一个极端的例子，尝试在非SPA网站（我知道它很奇怪）中制作计算器。
评论更新
似乎没有人提到套接字和长轮询。如果您从另一个客户端（例如移动应用程序）注销，则您的浏览器也应该注销。如果不使用SPA，则每次重定向时都必须重新创建套接字连接。这也应与通知，个人资料更新等数据中的任何更新一起使用
另一种观点：除了您的网站之外，您的项目是否还会涉及本机移动应用程序？如果是，那么您很可能将从服务器（即JSON）向该本地应用程序馈送原始数据，并进行客户端处理以呈现它，对吗？因此，有了这个断言，您已经在做一个客户端渲染模型。现在的问题是，为什么您的项目的网站版本不使用相同的模型？毫无疑问。然后，问题就变成了是否只为了SEO的好处和可共享/可标记URL的便利性而呈现服务器端页面
解决方法
我已经读过SPA及其优势。我发现其中大多数令人信服。有3个优点引起了我的怀疑。
问题： 您可以担任SPA的拥护者，并证明我对前三个陈述有误吗？
=== ADVANTAGES ===
1. SPA对于响应速度快的网站非常有用：
对于所有中间状态，很难实现服务器端呈现-小视图状态无法很好地映射到URL。
单页应用程序的特点是能够重绘UI的任何部分，而无需服务器往返来检索HTML。这是通过具有处理数据的模型层和从模型读取的视图层将数据与数据表示分离开来的。
为非SPA保留模型层有什么问题？ SPA是否是客户端上唯一与MVC兼容的体系结构？
2.使用SPA，我们不需要对服务器使用额外的查询来下载页面。
嗯，在访问您的网站期间用户可以下载多少页？ 二三？而是出现了另一个安全问题，您需要将登录页面，管理页面等分成单独的页面。反过来，它与SPA架构冲突。
3.可能还有其他优势吗？ 什么都没听到
=== DISADVANTAGES ===
- 客户端必须启用javascript。
- 该站点只有一个入口点。
- 安全。
PS
我曾经从事过SPA和非SPA项目。我问这些问题是因为我需要加深理解。无意伤害SPA支持者。不要让我多读一些有关SPA的文章。我只想听听您对此的考虑。