- 我们应该有非常合理和重要的理由去超越现有偏好的舒适区
- React 并非是前端的现代标准,其概念已经落后于竞争对手
- React 对 Web 组件支持不足,虽然对 Web 组件的支持一直在其 Roadmap 上,但React 的竞品都已在生产中支持了该功能
- React 确定了现代 Web 框架的标准,但也带来了敏捷性和适应性方面的严重缺陷,多年来 React 所做的每个决策都是在处理技术债务,反而其新的竞品不受限制
- 浏览器在过去十年中在JavaScript和CSS的新功能采用方面取得了巨大的增长。技术和用户期望已经发展,当前的工具生态系统在超越React方面做了比你想象的更多的迭代和适应,这是传统软件所无法做到的。
- 没有其他现代前端框架像 React 一样与平台坚决不兼容
- Hooks 的出现在前端领域产生了巨大的变革,功劳在于它差地改变了我们在应用程序中组织逻辑和状态的方式,它非常出色,几乎每个框架都围绕着类似 Hooks 的模型来管理状态,并且它们做的比 React 更好,使用更简单,样板代码更少
Preact
的Signals
Svelte
的Store
Solid
的Signals
- 甚至
Vue3
的组合 API
- 在使用
React
开发的过程中,混乱和模糊仿佛是一件正常的事情,例如不确定是什么时候应该使用useMemo
或者useCallback
,以及它们之间的区别到底是什么 - 如何判断一个框架的可扩展性?即使我的应用程序呈指数增长,它是否任仍然保持合理可维护性
- React 并不是前端可扩展性的最佳、唯一或者甚至是第一个解决方案,它只是统一范式的众多可能版本之一,但它也恰恰是最古老的之一
- 关于服务端渲染,很久以前,React 是少数几个具有在服务器上渲染客户端视图框架组件概念的框架之一。但现在,服务器渲染已经成为基本邀请。许多较新的框架不仅具有在服务器上渲染的选项,而且默认情况下就会这么做
SvelteKit
-Svelte
的元框架Fresh
-Deno
的前端框架Astro
- 可以渲染任何类型的组件,在某些情况下甚至被认为是 Next 的重大性能升级SolidStart
-Solid
的元框架
- React 一直没有官方的样式选项,导致 React 中的样式方案多种多样
css
、cssModule
、style-components
tainwind
- 在其他几个前端框架中,样式问题都得到了比较好的解决,特别是 Vue 和 Svelte 都有自己的样式处理方式,都具有组件级别的作用域,Vue 是选择性的,Svelte 是默认的,而且它们还都兼容其他的CSS方案:
CSSModule
、Tailwind
、Sass
或者其他的
- 在其他几个前端框架中,样式问题都得到了比较好的解决,特别是 Vue 和 Svelte 都有自己的样式处理方式,都具有组件级别的作用域,Vue 是选择性的,Svelte 是默认的,而且它们还都兼容其他的CSS方案:
- 同样的问题还出现在 React 的状态管理上,新的前端框架基本都有自己内置的
store
管理方案,例如Svelte
,而React
中也是多种多样
关于这些言论:
那些愚蠢的JavaScript开发者,总是追逐那些闪亮的新东西!他们不关心长期维护自己的项目。明天这个炙手可热的新框架就会被遗忘,他们的代码甚至无法运行!
作者的回复:
有一点真实的迹象。确实,JavaScript开发者(我敢说前端开发者普遍如此)似乎以一种其他编程专家不太敢兴趣的方式被新事物所吸引。但实际上,这有多真实呢?我们确定全世界的JS开发者在新技术出现时都会急于重写他们的整个技术栈吗?还是这只是一种被无尽的在线炒作循环所滋养的感觉?
我认为实际情况比看起来的要真实得多,因为任何一项技术的早期采用者往往是受到关注的人;他们是撰写所有博客文章和制作所有视频的人,这些内容又会被分享和讨论,从而使得这种行为似乎比实际上更为普遍。(毕竟,如果这种说法只有一半是真的,React的市场份额将只是目前的一小部分。)
大多数我遇到的前端开发人员都坚持自己所熟悉的,就像其他类型的开发人员一样。我认为对我们来说尝试新事物的成本稍微低一些,所以我们会去尝试。
文章原文地址:Things you forgot (or never knew) because of React - Josh Collinsworth blog