一篇《如果前端不使用SPA又能怎样？》引发讨论，这篇文章探讨除了React.js以外其他框架：Remix，RedwoodJS和Blitz.js。
以Remix为例，它将数据加载与路由重新联系起来，然后给出了一个惊人的承诺，即默认情况下不会提取任何客户端数据。这些框架还考虑了状态码和缓存策略。RedwoodJS使用GraphQL和Prisma自动创建类似于ORM的接口。
值得一提的是Turbolinks。Turbolinks 5的目标是：在没有应用程序任何合作的情况下，获得SPA体验所需要做的最低限度是什么？
这是一个很小的JavaScript库，它位于现有的服务器呈现的应用程序之上，并用类似SPA的部分页面加载代替了完整的页面加载。无需从头开始加载页面，而是使用AJAX加载页面，替换页面内容，并且客户端导航更新您的URL。基本上，它防止了实际页面转换的“闪烁”，并节省了完全加载新页面的所有其他成本。Turbolinks是从Ruby on Rails项目衍生而来的，可与Rails很好地配合，但不需要它。
就改善用户体验的权重而言，Turbolinks是一个杰出的产品：它为复杂的用户体验带来了极少的复杂性和很小的尺寸影响。
该文还提到了服务器端的状态框架：主要竞争者是Laravel Livewire（PHP），Stimulus Reflex（在Ruby on Rails中使用）和Phoenix LiveView（在Phoenix中的Elixir中使用）。这些框架令人兴奋，并且也极度叛逆，因为它们与“前端+不可知API层”模式截然相反，而且它们还全心全意地接受了每个人都想避免的事情：服务器上的可变状态。
各种观点：
从我第一次接触Angular以来，我就一直感觉到这个问题。除非您想制作一个真正的交互式异步应用程序（例如Google Docs或Facebook Chat），否则它会变得更加复杂和脆弱，而实际上没有任何好处。
当SPA成为规范，甚至需要使用React构建静态网页时，开发效率也越来越低。我看到整个团队都在努力构建简单的应用程序，并浪费了数月的时间，而这些团队过去通常只用一两个开发人员在几周内就在经过验证的服务器端框架上进行开发。但是，这不再符合最佳实践和行业标准。一切都需要是SPA，微服务，分布式数据库，Kubernetes等。这些组件和层需要通过反复试验将其粘合在一起。
我很高兴常识开始流行，越来越多的开发人员开始意识到集成的端到端框架对于许多现实应用程序开发场景非常有用。
有趣的是，我发现事实恰恰相反。我从事前端代码的开发已有十多年了，但是我从来没有比现在做得更快，编写的错误代码也更少。那是因为我已经成为一名更好的开发人员了吗？当然可以。但总的来说，我不认为这最终是原因。我认为这是技术的成熟。我作为一名程序员的发展几乎不是线性的，过去的5年与我在前5个中取得的增长不匹配。前端工具从来没有比现在更好。
我相信，构建Web应用程序的门槛已经降低，并且程序员比以往任何时候都更多。您可能不是在前端开发和javascript方面试图构建复杂的UI和应用程序的专家。因此，您选择了一个没有必要经验的人，并使用真正简单易上手的框架，将他们投入到很多深度（前端）范式中进行工作，但是会因滥用这些复杂问题而使它们陷入困境。
另一个因素是，由于SPA是有状态的，因此复杂性会激增。一页不是在每隔几秒钟刷新一次无状态页面，而是导致错误在会话持续时间内抬起头。这些经验不足的人负责设计不会扩展且不会成为意大利面条的代码库。但是，如果设计合理，这些问题将大为消除。
我并不是在主张SPA是解决所有问题的方法。我认为整个行业都严重滥用SPA，但这并不是对SPA本身的抱怨。而是因为选择错误的技术来解决当前问题的人。
根本的问题不是SPA模式不好，而是要花费大量的技巧和精力来制作适当的SPA。显然，技能和时间是稀缺资源，其结果是大多数SPA都是废话。
与jQuery时代相比，所有这些基于组件的OTOH框架无疑为我们带来了一种更好的方式来产生交互式体验。这根本与SPA不相关。您可以在多页应用程序中使用React / Vue / etc。问题在于，要混合（交互）服务器渲染的HTML，您现在需要在服务器语言和前端框架之间复制标记。解决方案是在后端和前端使用相同的框架，并只编写一次组件。
我现在正在使用TALL堆栈（Tailwind，Alpine.js，Laravel和Livewire）构建一个应用程序，并且我的生产力令人难以置信。所需的构建步骤非常少（根据.blade.php文件中使用的类，编译Tailwind以减小大小）。我非常喜欢CRUD，图片上传等操作。一开始我很怀疑，但现在我喜欢这种构建Web应用程序的方式。不知道它的扩展性如何，但是对于一个简单的MVP，我一直没有要求更好的堆栈。
我在工作中专业地编写了完整的SPA。我们使用React，Apollo，GraphQL，Webpack等。TALL堆栈充满了新鲜空气。我当时甚至无法开始解释我的喜悦。只是高兴。
现在，我不得不写那些无限的JS代码，相冲突的依赖项，缓慢的构建时间，React钩子状态管理等时间。
当我与我的同事谈论技术时，他们似乎都喜欢JS开发人员的纠结，并愿意使用发布的任何新框架。我一直在努力争取良好的旧可靠SSR。尽管经常被称为“怪异”，但是却偏爱老式技术。
我想我更喜欢更好的开发人员体验和更短的生产/上市时间，而不是花几天时间尝试建立一个项目并找出奇怪的怪癖和问题，例如“无服务器的现代Web应用程序”这样复杂的混乱。
我使用Turbolinks + Stimulus方法取得了巨大的成功。有两种常见的模式，例如，延迟加载内容（基本上是具有URL属性的<div>，您可以通过AJAX进行激励加载），并确实倾向于Rails的远程链接/服务器javascript响应模态和小页面更新。
与大多数React / SPA代码库（您可能在一整天中将一整天的时间发送出去）相比，仍然具有很高的生产力，能够在几个小时内完成一个应用的几页真是太好了。
大约2年前，我第一次在新的Rails应用程序上使用了Turbolinks，但由于受到影响而感到震惊-就没有页面加载和整体速度而言，它就像是SPA。
我坚信这是针对大多数用例的解决方案，结合了对React组件或Stimulus之类的选择性使用的组合，在这些情况下您需要更复杂的UI组件。