全文：对于后端合作开发者来说，经常迟疑的难题是如何选择后端构架，透过采用JS库，能大大提高合作开发效率，但责任编辑翻译者认为，在某些情景下，JS库并未增添四两拨千斤效果，反而放任不管！
书名镜像：https://codepilotsf.medium.com/is-it-time-to-ditch-svelte-react-and-vue-731d9dc9e25b
声明：责任编辑为 CSDN 翻译，需经授权，禁止转载。
翻译者 | Sean Schertell翻译者 | 弯月公司出品 | CSDN（ID：CSDNnews）如今，几乎大部份现代Web插件的构筑都要采用后端的某个JavaScript大型库，用JS图形的虚拟DOM代替整座应用程序视口，并透过REST API消费JSON，那些REST API须要单独构筑，但与后端密切谐振。
假如你在构筑像Figma 或 Trello 这样的白眉林插件（Single Page Application，即SPA），所以利用其中两个工具能节约很多时间和成本。但是，假如你在构筑两个半网页插件（Multi Page Application，即MPA），例如常见的电商网站，甚至是邮件之类的插件，所以我明确告诉你，采用SPA构架增添的复杂程度远超其本身的价值。
SPA 构架的难题仅把伺服器当做初始化API的渠道，则意味著他们无法再倚赖它来维护插件的状况。因而，我们将大部份状况管理工作转移到应用程序，并由此而发明了Redux 和 MobX 等全新的构架。由于他们无法再采用软件商基本上的路由器，因而创建了React Router 和 Page.js等程序库演示从前能完全免费赢得的路由器机能。
从前，在服务端会话同时实现加密极难。然而，在 SPA 构架中，通常他们须要采用JSON Web Tokens，此种同时实现的难度大幅增加（而且很容易出难题）。即使是最基本上的配置文件递交也无法再倚赖应用程序标准的HTML同时实现，根据其名称特性递交配置文件字段。那时他们须要将那些值存取到 JS 第一类，并“全自动”管理工作和递交该第一类。
换言之，那些机能从前他们能完全免费赢得，而那时却要付出大量努力，值得吗？
为何会有如今的局面？过去，Web合作开发很简单。应用程序推送两个 HTTP 请求，服务端两个新文件格式，然后由应用程序将其图形到视口，并代替掉之前的大部份内容。不过，此种方法有点僵硬。这意味著，即使你只想更新网页的少部分，也必须重新图形整座网页。
后来，JQuery 出现了，能利用AJAX仅更新网页的一部分，而无需刷新整座网页。如此构筑的Web插件更具交互性和响应性，更像“插件”。但JQuery涉及大量的命令式 JavaScript，而且维护难度很高。假如你想构筑一些复杂的机能，用不了多久，代码库就会变得盘根错节，无法维护。
后来，Angular出现了，还有紧随其后的React，那些构架采用了一种全新的方法，导致他们不得不重新思考“后端”的概念：后端不仅仅是透过JavaScript图形的DOM，而是两个 JavaScript 插件，它最终会图形出两个DOM。假如你想构筑两个白眉林应用程序，则此种方式很有效。虽然你无法采用HTML基本上的应用程序/伺服器构架，但能自由地构筑类似于插件的后端体验。此种新方法令人兴奋，不久之后，每个新建项目似乎都开始采用SPA。
在过去的5～10年中，用户对现代响应式网站的期望也急剧增加。因而，人们不再满足于构筑须要重新加载整座网页的“Web 1.0”风格的插件。
没有 SPA 的现代 UI所以，假如不采用 SPA 后端/REST 后端构架、不编写大量僵硬的 JQuery、不必每次点击鼠标都刷新整座网页，他们如何才能构筑两个现代 MPA 网站呢？
有一批库致力于提供现代交互性，同时仍然能够采用HTML和HTTP的基本上机能，这两个词都以“HT”开头，意思是超文本（Hypertext）。关键就在于此。Web的设计理念是在网络上来回传输超文本，而不是JSON。Hotwire、HTMX 和 Unpoly 等库允许你透过向标记添加 HTML 特性或标签以声明性方式代替DOM块，同时无需自己编写任何 JavaScript。例如，按钮“添加到购物车”能向服务端两个请求，该请求会在服务端会话中修改购物车货物的服务端状况，然后推送回两个DOM 块，代替网页上的cart-sidebar和#cart-icon-badge。此种同时实现能非常优雅，而且还能采用漂亮的 CSS 动画。
假如他们按照Tim Berners-Lee（万维网的发明者）最初的设计思路送HTML，结果就会收到大量没用的数据。应用程序状况管理工作的DOM本就是应用程序的状况。应用程序路由器器？这不是开玩笑吗？JSON Web Tokens？伺服器会话是经过验证的，而且更容易同时实现。他们的数据库查询也更加容易，因为大部份的路由器都在服务端编写，因而能安全、直接地访问数据库。
我编写了两个简单的基于 ExpressJS 的构架来同时实现此种构架风格，你能试试看：https://www.sanejs.dev。
Ruby on Rails将在2022年大放异彩？像大多数现代 Web 合作开发人员一样，长期以来我一直在避免采用Ruby on Rails，因为这个构架的设计思路是构筑庞大的单体Web应用程序，此种方式早已过时。但难题在于，假如后端采用Hotwire 或 HTMX之类的构架，后端就能采用任何构架。由于他们处理的是HTML元素，因而在理想情况下，后端能选择最适合创建伺服器图形模板的构架。但他们没有所以多机能齐全、方便易用的构架。如今这类的主流构架有Rails、Django 和 Laravel。还有一些即将出现的构架，例如基于 Elixer 的 Phoenix 和基于 Go 的 Buffalo。但是 Rails 有两个庞大的社区，非常成熟，老实说，这为他们提供了很多帮助。
但重点在于，去年 12 月最新发布的 Rails 7.0包括后端交互库Hotwire。Hotwire 能与 Rails 一起采用，也能单独采用，但其设计初衷是与 Rails 合作开发完美结合，而且是默认自带的。不论是你是否相信，时至2022年，Rails仍然是完美的全栈构架，可用于构筑具有现代交互性的后 Jamstack 时代的MPA Web 插件，它能控制基本上的HTML元素，他们不须要借助JS构架，构筑两个后端应用再加两个后端API。
总结假如他们的最终目标是以快速、有条理和可维护的方式构筑现代 MPA 网站，所以就应该认真考虑 SPA/Jamstack 构架是否真的适合这项工作。随着现代 DOM交互库（如 Hotwire、HTMX 和 Unpoly）的出现，他们终于有了两个真正的SPA 替代方案，它允许他们创建现代、优雅的界面，允许他们控制基本上的HTML元素，无需重新发明插件状况管理工作和配置文件递交等基本上的轮子。因而，假如他们想重新采用伺服器图形的模板，所以也许是时候再看看 Web 构架的卫冕冠军：Ruby on Rails。尤其是全新的 7.0 版本内置了 Hotwire，Rails 可能是 2022 年构筑现代多网页插件的最佳解决方案。
