美文网首页
现在 React 快死了——这里有一些(更好的)替代品

现在 React 快死了——这里有一些(更好的)替代品

作者: 技术的游戏 | 来源:发表于2022-11-12 16:49 被阅读0次

React 不再是唯一的选择——不要落后——尽快学习这些很棒的(但被低估的)JS 框架。

image.png

今天在框架世界中发生了很多了不起的事情(你可能不知道)。

如果你喜欢——该死!我们需要另一个 JavaScript 框架吗?

不,我在这里不是要告诉您尝试另一个新框架。你到底为什么要这样做?不要为了使用而使用它?

我在这里分享 Web 框架中的一些(惊人的)创新,因为我们值得拥有更好的东西——不是吗?

这些框架已经存在了一段时间(未被充分认识),值得我们关注。

现在是我们研究它们的时候了,因为所有这些框架都在向前迈出重要的一步。

至少不知道他们的一些事情是很遗憾的。

您不能在薄弱的地基上建造一座伟大的建筑——您需要一个坚实的基础。

作为程序员,我们应该总是问,“我们今天所知道的一切,我们怎样才能做得更好?”

由于被要求做它从未打算做的事情,React 变得一团糟。

Solid本质上是对 React 的重新启动。

它解决了两个主要问题:

  • 第一个是虚拟 DOM(组件不断重新渲染是一个性能问题)。
  • 二是状态管理。

Solid.js 拥有我们今天遇到的所有反应式状态管理,但做得更好,就好像我们从头开始了解我们现在所知道的一样。

它既实用又非常高效。

它与 React 组件有很多相似之处,例如返回 JSX(用于 UI)的 JavaScript 函数,但与 React 不同的是,它没有虚拟 DOM。

image.png

我们得到了一种 Svelte 类型的编译器,可以将您的代码转换为原生 JavaScript,使您尽可能接近 DOM。

1_B_RrAATpwmY4omo2Ll25Ig.gif

该框架本身只有 7KB 的大小,并且在您的代码中不需要任何额外的魔法或怪异的 hack 的情况下完全压倒了运行时性能基准,最重要的是——它是真正的反应式

因为函数组件只被调用一次,所以你可以做一些前所未闻的事情,比如setInterval(可预测地)使用发生变化的顶层数据。

1_IuN2HxjPZhjCTW_SZ5PcAg.gif

框架不会重新渲染整个组件,而是会监控这些数据,并在它发生变化时通过手术更新其在 DOM 中的确切位置。

状态createSignal由返回gettersetter的原语管理。

1_II0rD152uJ1qjrjYqBnfDg.gif

信号是包含签名列表的事件发射器。只要他们的价值发生变化,他们就会通知他们的订阅者。Solid 使用自动依赖跟踪。更新会随着数据的变化而自动发生。

昂贵的计算?不用担心——我们有一个函数可以记住返回值。

1_voncydOLpZiGmCJEmImW6g.gif

想要在您的数据发生变化时运行代码(副作用?) -createEffect()让它更容易。

1_hyFVz01ZTfq5t6FWrZhX7A.gif

函数主体中引用的任何信号都将自动订阅以重新运行副作用。

每当值发生变化时,solid 还提供onmountoncleanup功能,以利用组件生命周期的开始和结束。

Solid 的编译器足够智能,可以优化处理决策——三元a ? b : c表达式 () 和布尔表达式 ( a && b)

1_F8lbXdeWcZzeYlUYLONHig.gif

当涉及到集合时,它还提供了一个createStore可以轻松处理嵌套反应性的功能。

它支持带有use关键字的自定义指令,这是一种将自定义行为附加到不同元素的高效方法。

1_26DHbcZDHzFALtakVldvPg.gif

延迟 加载上下文SSR 支持,应有尽有******——****它拥有您在现代框架中所期望的一切。

不要着急。快点(但不要着急)。

Qwik带来了一些全新的东西。

它与您以前从未使用过的完全不同。

它引入了可恢复性的概念。

0__bpK6eyAS2cdDI-1.gif

应用程序在服务器上启动。它使自己进入特定状态。我们对状态进行快照,我们以 HTML 的形式将状态发送给客户端,然后在客户端上,我们从中断的地方继续。

它完全放弃了 Hydration 的过程,使您的应用程序从一开始就准备就绪。

这意味着更少的下载和更少的执行。

无论使用何种设备或网络,您的用户都可以享受顶级性能。

0_76A89K2nBQOEGtdT.gif 0_MYFA_vVis5Ald_Pk.gif

JS 的“洒落”很快就会变成瀑布。随着洒水量的增加,您的加载时间不会增加。

Qwik 让您可以随心所欲地编写 JavaScript,而不会受到包大小或性能下降的负担。还可以通过后台的服务工作者预取代码,这样就没有等待时间了。

如果生活是一张画布,那么你就是画家——留下你的印记

如果我们可以扩展 HTML 语言并以声明方式构建 Web 应用程序会怎样?

Marko是一种 HTML,被重新设想为一种用于构建动态和反应式用户界面的语言。

几乎任何有效的 HTML 都是有效的 Marko。它扩展了 HTML 语言,允许以声明方式构建现代应用程序。

1_nYqnKR5zl1CpawlHggHawA.gif

一旦内容准备就绪,Marko 就会将内容流式传输给您的用户。无需等待客户端 JavaScript 包或数据请求即可开始呈现。

0_yPLJvotycnPmKxuE.gif

HTML、资产和图像会尽快加载,并在完成时加载异步数据。

它消除了反应图级别的代码。没有虚拟 DOM——没有组件。

编译器会自动检测哪些特定组件需要在服务器上呈现。

它生成适合其运行位置的代码。代码非常小而且非常快(Todomvc 和 HackerNews 演示是 2kb 或更少)。

编写一次代码,它就针对服务器和浏览器进行了优化。

Marko 比其他流行的解决方案快几倍。

1_c7ILA7l-Xzhz_26FsfaStg.png

Qwik一样,Marko 也可以恢复(目前尚未发布)。

热永远不会伤害

如果我告诉你还有另一种(巧妙的)方法来构建现代 Web 应用程序会怎样。

你可以拥有快速的首次加载页面和超高效的开发体验——同时使用你最喜欢的语言(我已经将它与 Ruby、Python、Elixir 甚至 JS 一起使用——结果令人兴奋)——而不牺牲任何您在传统单页应用程序中获得的速度响应能力

您可以在短时间内完成很多工作(创建功能),而无需编写大量代码(或 JavaScript)。

您的代码将与适用于 iOS 和 Android 的本机混合应用程序完美配合。

叹息……听起来像童话故事?

认识热线

Hotwire 这个名字有点误导,因为它不是一回事,实际上是两个TurboStimulus)。

其中之一(Turbo)实际上是三样东西(Drive、Frames 和 Streams)。总的来说,它们是构建快速且响应迅速的 Web 应用程序的强大方式。

Hotwire 的核心是 Turbo。一套用于加速页面更改和表单提交、将复杂页面划分为组件以及通过 WebSocket流式传输部分****页面更新的补充技术。**

1_OhLIrQsHgyfylaLp6tlvjQ.gif

我看到 JS 社区的人们回避 WebSocket 并将其视为一些深奥的话题(事实并非如此)。

使用现有的模板系统向页面添加动态行为非常快速和容易。

它的无状态特性有助于避免错误。

对于那些您需要一点 JavaScript 的情况,Stimulus可以让您更轻松。

1_2OhpZe2G6y817p-LGyNxMQ.gif

与 Turbo 和 Stimulus 一起,我们很快将拥有Strada,它将允许将任何现有的网络应用程序转换为本机应用程序。

Hotwire 的简单性是神奇的。除非你尝试一下,否则你不会知道。

受够了 React 的习惯——是时候克服它了

0_rnBLYctWL5drvP6X.gif

Som — 你鄙视 React — 是吗?

并不真地。

在你的生活中,你有没有遇到过一个人,你为之付出了所有,却发现这个人不值得?

React 让我想起了那个人(前任——如果你曾经有过?)

你鄙视他们吗?

没有权利?

曾经有一段时间他们的存在给你带来快乐,但有时他们在你的生活中只会给你带来痛苦。

我从未见过一个框架需要这么多额外的库来解决像状态这样简单的事情 ——Recoil、Redux、Jotai 等等。这条过道表明底层技术存在严重的设计缺陷。

我不介意,但它弊大于利,尤其是对新手而言。他们开始专注于将库粘合在一起,而不是构建应用程序。

更糟糕的是——它被宣传为创建 Web 应用程序的唯一(也是最终)方式,这是一个彻头彻尾的谎言。

Facebook 创建 React 是为了解决他们遇到的问题(不是为了你)。如果没有 Facebook 肆无忌惮的营销,我不明白像 React 这样臃肿的东西怎么能持续这么久。

作为一名程序员,你必须克服羊心态,审视你的问题并找到具体的解决方案,而不是鹦鹉学舌

您不必仅仅因为某些花哨的公司正在使用(和推广)它而使用某些东西,很多时候流行的解决方案并不是最适合您的解决方案。

选择让你快乐(和富有成效)的东西,而不是别人强加给你的东西。

如果您不喜欢任何东西,请自己构建——这就是我们获得精美工具的方式。

问问自己——如果其他人或该死的就业市场没有推动你,你还会学习(和使用)它吗?

结论

做你自己。

其他人都已经被带走了。

回到我最初的观点:作为程序员,我们应该总是问,“我们今天所知道的一切,我们怎样才能做得更好?”

事实上,React 从未打算成为一个完全充实的框架——它在设计时只考虑了一个单一的目的(处理视图),但它逐渐变得一团糟。

我希望您能看到并理解为什么Solid、Qwik、Marko 和****Hotwire不仅存在,而且如果我们希望 Web 开发生态系统进一步发展,也需要存在。**

他们都在帮助我们前进,让我们的生活更轻松一些。

感谢信

我想借此最后的机会说声谢谢。

非常感谢您的到来!如果没有像你这样的人跟随并坚定地阅读我的帖子,我将无法做我所做的事情。

下次见。再见!

相关文章

网友评论

      本文标题:现在 React 快死了——这里有一些(更好的)替代品

      本文链接:https://www.haomeiwen.com/subject/mqvfxdtx.html