您可能并不需要单页应用程序

前端框架的迅速崛起，如React、Angel、Vue.js、Elm等，使得单页面应用程序（Single Page Application）在网络上无处不在。对于许多开发人员来说，这些已经成为他们“默认”工具集的一部分。当他们开始一个新项目时，他们会使用他们已经知道的工具：后端的REST API和Reaction/Angel/Vue/Elm前端。
这些工具有什么问题吗？绝对不是。事实上，我喜欢使用这些工具。然而，只有当实际需求将我推向那个方向时，我才会选择这个架构。如果没有特定的理由构建单页面应用程序，我每天都会使用传统的服务器呈现的体系结构。
它更简单，让您可以更快地操作：

• 无状态请求
  传统的web服务器是无状态的。这意味着每个端点都可以独立地进行推理和测试。相比之下，单页面应用程序必须明确定义整个会话期间前端如何加载、刷新和丢弃所有状态。这引入了新的缓存/同步问题，这些问题在服务器渲染的世界中是不存在的。

• 浏览器知道如何处理传统架构
  如果你选择单页面应用程序路线，你总是需要额外的代码来模拟简单的浏览器功能。我花了很多时间来确保正确管理浏览器历史记录，加载动画看起来平滑，当用户浏览历史记录时恢复滚动位置等。真是一团糟。

• 更少、更成熟的工具
  Rails、Phoenix、Lavarel等框架已经存在一段时间了，它们非常稳定。我大约在5年前学习了Rails，我的知识现在仍然很有用。与此同时，我还学习了Gulp、CoffeeScript、BackboneJS和SASS，这些都已经被新的工具取代了。避免Javascript疲劳不要过度依赖Javascript！

• 免费搜索引擎优化
  单页面应用程序必须添加额外的基础设施和代码，以确保它们可以被爬虫程序索引。如果您的动态页面上需要SEO，则使用服务器呈现的体系结构更容易实现。

所有这些都意味着单页应用程序给开发人员带来了更多的复杂性和认知负担。以我作为开发人员的经验来看，复杂性和认知负荷是导致软件bug和开发速度减慢的最大因素。

何时使用单页应用程序？

正如我所说，大多数情况下的默认选择应该是传统的服务器渲染的应用程序。然而，有些需求可能会强制你选择单页应用架构:

• 核心功能是实时的(例如Slack)
• 丰富的UI交互是产品的核心(例如Trello)
• 屏幕之间共享的大量状态(例如Spotify)

这些产品必须使用单页架构才能正常工作。这就是为什么它是这些公司的正确选择。然而，许多基于Web的产品没有这些要求，这种复杂性是可以避免的。

混合解决方案

即使你的应用程序需要一些实时功能或丰富的交互，你也不需要在整个应用程序中使用SPA范式。一个很好的方法是将小型前端应用程序嵌入到传统架构中。

Github使用这种混合方法。他们网站的主干是一个传统的Rails应用程序，但有些地方，如projects选项卡，是作为嵌入式前端应用程序构建的。这是一个完美的解决方案，结合了两者的优点。最棒的是，你可以从简单的开始使用这种方法，然后逐渐添加更复杂的UI交互。

我还决定在我当前的项目貌似有理的分析中使用混合方法。它是我一直在研究的谷歌分析的一个以隐私为重点的替代方案。大部分应用程序都是在服务器端渲染的。但是，我希望主仪表板(demo)具有非常丰富的UI，具有动画和刷新数据，而无需重新加载整个页面。当你打开页面时，前端路由会接管一切，所有内容都在React中渲染。

这一切归根结底是权衡

与编程中的所有事情一样，SPA与传统架构之间的困境没有唯一的答案。有些情况下使用SPA是有意义的，因为你需要一个时髦的实时UI。然而，我们应该认识到，这是以牺牲开发速度为代价的。如果单页应用不是必需的，我们可以通过传统的方法来避免额外的复杂性并更快地迁移。

为工作选择正确的架构会对生产力和最终的成功产生巨大的影响。我们的目标应该是在我们的工具箱中有两种架构，这样我们就可以在每种情况下使用最优解决方案。