首页 >>  正文

react翻译

来源:baiyundou.net   日期:2024-09-21

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

","force_purephv":"0","gnid":"99456207639e77543","img_data":[{"flag":2,"img":[{"desc":"","height":"80","s_url":"https://p0.ssl.img.360kuai.com/t0186957a1ca5352752_1.gif","title":"","url":"https://p0.ssl.img.360kuai.com/t0186957a1ca5352752.gif","width":"640"}]}],"original":0,"pat":"art_src_1,fts0,sts0","powerby":"cache","pub_time":1661221869000,"pure":"","rawurl":"http://zm.news.so.com/b6315cfcdc455af07cba87524c4f8e88","redirect":0,"rptid":"2e084c883a410e5c","s":"t","src":"CSDN","tag":[{"clk":"ktechnology_1:java","k":"java","u":""}],"title":"是时候抛弃 Svelte、React 和 VUE 了吗?

马马苛5234英汉互译: 化学反应
钱肺泉18557598930 ______ react

马马苛5234英语翻译very often we wish to work out the mass of one reactantthat reacts exactly with a certain masses of reactants react - or how muchproduct is formed when ... -
钱肺泉18557598930 ______[答案] Very often we wish to work out the * of one * that * exactly with a certain * of * *-我们往往(常常)都想求出,一大组***的****中,其中一种***(具体有)多少参加了该**. or how much * is formed w...

马马苛5234react是单文件应用吗
钱肺泉18557598930 ______ react不是单文件应用,因为它本身不限制应用程序的文件结构.React的组件通常可以以单个文件的形式编写,但在实际项目中,可以将组件拆分为多个文件,根据项目规模和组织需求进行合理的文件结构设计.另外,在开发过程中,通常会使用构建工具将React的多个文件打包成一个或多个输出文件,以便在浏览器中加载.这些输出文件可以包含React组件以及应用所需的其他资源和依赖项.

马马苛5234英语翻译1、我没有奢求过什么 只是想 和你在一起的时间 能多一点 再多一点 2、你的名字 我的姓氏 3、这是一个不能说的秘密 4、德拉科 你知道吗 每次看到... -
钱肺泉18557598930 ______[答案] 1、我没有奢求过什么 只是想 和你在一起的时间 能多一点 再多一点 I never extravagantly wish something,I just wanna be ... 7、沉默的人最聪明,不做无聊的回应 Silent people are intellegent,as they don't react to dull words.8、我为你高兴 为自己伤心 ...

马马苛5234try and try怎么翻译
钱肺泉18557598930 ______ try and try 意思是 不停地尝试 也可翻译为:努力,再努力 例句:We try and try 我们勇于尝试 I try and try, but I'll never get it! 我试了又试,可总是不成! Try and try, until you discover your difference. 不停地尝试,直到你发现真正属于自己的. Try and try again. You'll get more than you'd hoped! 不断的尝试,你会得到比你所希望的更多!

马马苛5234英语翻译英语翻译:亲爱的杰克:你的信我已经收到了,我最近认识了一个朋友,他人非常好,那天我去图书馆借书,碰巧遇见了他,结果发现,他与我要... -
钱肺泉18557598930 ______[答案] Dear Jack, How are you getting?I have received your letter and I have a new friend recently,he is nice guy. One day,when I ... and he also would like to get the same book which I needed but he was so kind to let me have it otherwise,I wouldn't how to react ...

马马苛5234Because a mole of fossil carbon dioxide from limestone is remobilized by the reaction of a mole of a求高手翻译,软件翻译的就一边去了Because a mole of ... -
钱肺泉18557598930 ______[答案] 因为一摩尔石灰岩二氧化碳化石和一摩尔的大气中二氧化碳发生反应,也有大气和海洋之间循环的二氧化碳净增加.

马马苛5234为什么React.js这么火 -
钱肺泉18557598930 ______ Angular和React不属于同一类的东西,Angular是一个框架,而React更多是负责UI视图部分,大家普遍认为React是MVC中的V.那么到底为什么React.js一下子就火起来了呢?个人觉得可能主要是因为以下几个因素所导致的:单向数据绑定 就在...

马马苛5234谁帮忙翻译下
钱肺泉18557598930 ______ Life is like rape.Since you fail to fight back to it,just enjoy it.或者是 Life is like rape. Since you couldn't resist it,you can just lie down and enjoy it. 纯手写,请采纳

马马苛5234js的框架react和react native的区别 -
钱肺泉18557598930 ______ 简单的说一下:1,React Js的目的是为了使前端的V层更具组件化,能更好的复用,它能够使用简单的html标签创建更多的自定义组件标签,内部绑定事件,同时可以让你从操作dom中解脱出来,只需要操作数据就会改变相应的dom.2,React Native的目的是希望我们能够使用前端的技术栈就可以创建出能够在不同平台运行的一个框架.可以创建出在移动端运行的app,但是性能可能比原声app差一点.

(编辑:自媒体)
关于我们 | 客户服务 | 服务条款 | 联系我们 | 免责声明 | 网站地图 @ 白云都 2024