是时候抛弃 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

余下全文(1/3)
分享这篇文章:

请关注我们:

发表评论

邮箱地址不会被公开。 必填项已用*标注