是时候抛弃 Svelte、React 和 VUE 了吗？

摘要：对于前端开发者来说，时常犹豫不决的难题是如何选择前端框架，通过使用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 年构建现代多页面应用程序的最佳解决方案。

本文文字及图片出自 CSDN