写点什么

为什么说 React 是 UI 的未来

  • 2018-07-22
  • 本文字数:3545 字

    阅读完需:约 12 分钟

我们曾经认为太阳围绕地球运行,把瘟疫看作神对人类的惩罚,而现在我们坚信 MVC 架构和双向数据绑定就是构建 Web UI 程序的最佳方式。

过去,人们没有更好的方式来探寻这个世界,由于认知的局限,人们对这些“误解”深信不疑。

最终,天文学家证明了日心说,医生发现疾病是由细菌引起的。类似的,React 引入了单向数据流的概念。

这些发现都没有立刻得到大众认可。伽利略的理论被认定为异端邪说。Semmelweis 博士发现疾病源于细菌,然而同事不接受他的这一研究成果,最后遗憾的在一庇护所中含恨而终。而如今,我们仍然误认为所有的 UI 架构都是平等的。

我坚信 React,或者类似的东西,将是用户界面开发的未来。此刻,希望你不要立刻跳到文章末尾表达赞同或者反对意见,请先耐心看完文章正文,我会告诉你我这么认为的理由。

React 的视野更为广阔

React 是一个由聪明人创造的聪明想法的集合。当 React 首次公布时,主要的卖点在于它的渲染方式:如果将应用程序结构与底层渲染 DOM 分开,我们可以实现声明式的视图渲染语法,同时仍然能够应用最优的 DOM 突变。

它的思想别具一格,比如,它认为通过将代码分离为 HTML、JavaScript 和 CSS 来跨越技术边界的方法并没有实质性的效果。React 认为,为了创建具有高内聚和低耦合的程序,我们最好将 UI 的呈现、行为和状态放在一个 JavaScript 文件里。这种方法为开发人员带来了阻碍,那就是在普通的 JavaScript 中难以创建 UI。鉴于此,React 附带了一个名为 JSX 的扩展语法。

很多开发者非常讨厌 JSX 扩展语法。如果你不是 Web 前端开发人员,也许很难理解开发者为什么会对扩展语法充满排斥情绪。



React 发布时激起了热烈的讨论

没有人愿意看到自己深信不疑的东西被否定,这是人的天性。因此,在高速发展的前端领域,React 的核心价值经常被忽略。

React 是一个组件平台

React 的核心在于它的组件。虚拟 DOM 是一项很酷的技术,但它只是一个实现细节,如果 React 不需要它也可创建,那它也就没有存在的必要。JSX 是一项不错的技术,但它只是语法糖。

如今,组件已经是一个非常成熟的概念了,它在 React 之前就已经存在。当 React 发布时,Web 组件规范早已标准化。就像伽利略并非第一个发现日心说的人一样,组件也不是 React 发明的,React 只是重新定义了它。

React 组件的优点主要在于它的可组合性和封装性。其次是它的函数组件和多用途。下面我将对其进行详细说明:

  • 可组合性使我们能够使用多个小的程序来组件一个大的程序,这些小程序使用的模板并不依赖其他组件,代码可以独立于系统中的其他代码进行自由修改、删除和替换,甚至可以在未来的代码存在之前编写。
  • 封装包含组件的整个表现、行为和状态。这意味着外部代码不能影响其行为,除非包装成了一个组件。
  • 函数式风格的编程接收 Props 进行渲染,这使得 React 组件更加健壮,它们的行为易于记录和理解,从而使得开发人员能够使用其他人开发的组件,而无需了解其工作原理。
  • 多用途意为组件既可以是负责数据和行为的容器组件(控制器),也可以是呈现组件的视图。这种分离的方式一直是 MV * 体系结构的关键,而优雅的 React 组件 API 可以在保留可组合性和封装性的同时,实现真正的分离。

这种小巧且集中的组件抽象方式提供了开发者需要的所有特性,比如:易于学习和记忆,更好的用户使用体验,并且能够生成便于维护和协作的程序。

还有一个我没提到的组件,事实上,这是最重要的组件。

组件是创新原语

虽然我是 React 的忠实支持者,但我不得不承认 React 并不完美;React 核心团队正在积极对其进行优化,一些新的想法在不断讨论、实施和丢弃。虽然目前 React 的生态系统很强大,包含了大量的库、模式和多种实践,但它依然有提升空间。我们甚至不能确定是否需要高阶组件、渲染 Props、函数式 Props、或者组件的组件

虽然丰富的选项有时会令人疲倦,但这正是React 组件模型的真正优势所在。有了通用的、小型的、可组合的、灵活可靠的构建模块,我们就可以在不丢弃现有工作的情况下讨论、测试和接受新的想法。

遍布世界各地的个人开发者构建了像 Redux Apollo 样式化组件这样革命性的库,应用开发者可以将这些新工具与现有工具一起使用,而无需修改现有的代码,并且可以不影响其他模块的情况下单独替换某些特定的模块,这都令我难以置信。

这些库各自都在React 领域之外实现了复杂的功能,但他们却没有相互限制,因为这些工具都可以利用组件组合模型。因此,React 组件模型不仅仅是一个UI 原语,它是一个创新原语。

与渐进式JavaScript 的不同之处在于,React 采用新工具时不必重构大量的代码。与Ember 或者Angular 这样的整体型框架不同,React 具有足够的灵活性来应对不可避免的变化。

变化不可避免

平台应当能够适应变化,这一点非常重要,因为变革总是不可避免并且代价高昂。

聪明人不会突然停止对问题的观察,并为其提出解决方案。人们不会停止对存在的限制感到沮丧,并且不会停止对自由的追求。作为开发者,发现更好的工具时,我们也不会强忍着不去使用。无论你多想保持现状,历史的车轮总是滚滚向前。

当改变发生时,一个系统最理想的状态是它能够适应变化,如果完全替换代价将非常巨大。

在过去十年的框架战之后,我们现在生活在前所未有的繁荣与和平时期。React 等工具使我们能够构建和维护杰出的产品。

如果我们的工具阻碍了进步,我们必须保持前进而不得不放弃它们。革命的代价是毁灭现有:我们将不得不更换所有的库,重新认识新方法,重新培训我们的团队,重复我们的错误,改写或重构大量的代码,而不是专注于我们正在创造的产品。

革命无法抗拒

创新的阶段分为两部分:

- 快速改革的爆发期

- 缓慢增长的长尾期

革命期增长迅速,细化阶段增速平缓。

React 是一场革命。它推翻了当前的最佳实践,几乎在一夜之间对开发人员体验方面进行了重大改进。目前我们正在快速进行迭代,我们对这种快速的创新已经习以为常,但是不久之后,创新的速度将会趋于平缓。

但曲线并不会真正决定创新的速率。只要我们保持创造活力和创新精神,同时开发者积极做决策,我们的生态系统依然能够快速变化。

让我们编写软件积极应对变化

无论我们是在 React 生态系统内部使用其他框架,构建无框架的渐进式 Web 应用程序,还是根本不构建与 Web 平台相关的软件,我们都可以从 React 及其生态系统中学习这些经验教训,能够灵活应对变化而不需要颠覆现有的代码。

  • 用小模块来构建大系统:使用多个小巧的特定功能单元来构建软件,尽量避免使用整体性的架构。设计 API 和接口时要仔细考虑,方便他人使用。
  • 让代码易于复制和删除,而不容易更改 :相比于继承和混入最好使用组合。把行为进行封装。把一件事做好。
  • 优先为人而不是机器编写代码:让代码变得更好理解。编写代码时尽量意图简单明了,不要过于学术。做到命名准确,书写必要的文档,保证代码规范,方便他人使用。
  • 密切使用编程语言:React 能够利用新的 JavaScript 语言功能和生态系统工具,因为它只使用 JavaScript 而已,虽然它有一套 JSX 语法。避免使用基于字符串的 DSL 和非惯用接口,因为这会降低兼容性。
  • 除非逼不得已,否则不要打破现有状态 :稳定性本身就是一种价值,因为改变会导致额外的工作和浪费产生,或者在最糟糕的情况下,甚至会发生诸如废弃 AngularJS 这样的结局。要么最初就更换技术方案,否则最好不要在中途进行替换,使用代码模块或类似的工具来适应变化。在你自己的代码中,不要仅仅为了它而采用新的库,请充分衡量成本与收益。
  • 保持开放的态度:如果遵循了前面的规则,那么最后这一条也是必然的。有时候,新的想法也许让人恐惧,变化可能会带来不便,但革命总是偶尔会发生。不要太过一成不变,保持开放的态度,听取人们的意见。

React 是开发者的福音

UI 领域技术更迭非常之快,简直变幻莫测,我相信 React 会是 UI 的终极选择。

虽然我个人并未重视虚拟 DOM,但它已被证明是 React 最具前景的功能之一。由于虚拟表现层和 UI 实现层的分离,React 非常适合服务器端渲染和通用 Web 应用程序。原生移动平台是用户界面开发中难以忽略的一部分; React Native 正好可以在该领域为我们提供大力帮助, recoil 让 React 在 Kotlin 和 Swift 中都大有可为。 ReasonML ReasonReact 可以帮助我们将 React 范例扩展到 JavaScript 之外的平台。随着未来增强和虚拟现实技术的蓬勃发展,我希望 React VR 和其他类似的实验可以帮助我们预测风暴。

最终,React 将被其他东西取代。我们还不知道强制函数会是什么,也许是 WebAssembly,我们不知道接下来会发生什么。不管怎样,我都会怀以激动的心情期待它。

就目前而言,由于 React 的强大存在,我相信短时间内 UI 领域会保持专一、稳定并欣欣向荣。

原文链接: https://medium.com/@jevakallio/the-present-future-of-user-interface-development-ebd371255175

感谢覃云对本文的审校。

2018-07-22 12:492789

评论

发布
暂无评论
发现更多内容

向日葵资深产品总监技术分享:如何在AD域环境下应用

贝锐

安全 AD域 远程控制 向日葵

web前端开发培训课程如何学习

小谷哥

向日葵远程控制为何采用BGP服务器?自动最优路线、跨运营商高速传输

贝锐

远程控制 向日葵

什么是RPC?RPC框架dubbo的核心流程

程序员啊叶

Java 编程 程序员 架构 java面试

一百五十个终极Java 经典面试题(你会多少题?)

程序员啊叶

Java 编程 程序员 架构 java面试

海外APP推送(下篇):海外厂商通道集成指南

极光GPTBots-极光推送

sdk 厂商通道

开放原子开源基金会OpenHarmony工作委员会主席侯培新寄语OpenAtom OpenHarmony分论坛

OpenHarmony开发者

OpenHarmony

Redis为什么这么快?Redis的线程模型与Redis多线程

程序员啊叶

Java 编程 程序员 架构 Java 面试

面试京东T5,被按在地上摩擦,鬼知道我经历了什么?

程序员啊叶

Java 编程 程序员 架构 java面试

最新战报:十项认证,五项最佳实践

天翼云开发者社区

云计算 分布式云

大数据培训机构有哪些值得推荐?

小谷哥

技术分享:国民远控向日葵如何通过BBR算法提升远控体验?

贝锐

技术分享 远程控制 TCP拥塞控制 向日葵 BBR

公司刚来的阿里p8,看完我构建的springboot框架,甩给我一份文档

程序员啊叶

Java 编程 程序员 架构 java面试

「中高级试题」:MVCC实现原理是什么?

程序员啊叶

Java 编程 程序员 架构 java面试

万字长文,浅谈企业数字化建模蓝图

产品老高

数字化 中台架构

浅谈低代码技术在物流运输平台中的搭建与管理

王平

在北京选择前端培训班学习大数据

小谷哥

深度学习3D人体姿态估计国内外研究现状及痛点

阿炜小菜鸡

深度学习 人体姿态估计

目标检测网络R-CNN 系列

阿炜小菜鸡

深度学习 目标检测 7月月更

敲黑板画重点:七种常见“分布式事务”详解

程序员啊叶

Java 编程 程序员 架构 java面试

行业案例|指标中台如何助力银行业普惠金融可持续发展

Kyligence

大数据 普惠金融 指标中台

数据泄漏、删除事件频发,企业应如何构建安全防线?

京东科技开发者

公司管理 网络安全 安全 删库 程序员‘

天翼云Web应用防火墙(边缘云版)支持检测和拦截Apache Spark shell命令注入漏洞

天翼云开发者社区

Shell 防火墙

参加前端培训班学web前端技术靠谱吗

小谷哥

干货|语义网、Web3.0、Web3、元宇宙这些概念还傻傻分不清楚?(中)

Orillusion

开源 WebGL 元宇宙 Metaverse webgpu

尤雨溪向初学者推荐Vite 【为什么使用Vite】

flow

签约计划第三季

银行业客户体验管理现状与优化策略分析

易观分析

银行

Python爬虫,JS逆向之 webpack 打包站点原理与实战

梦想橡皮擦

Python 爬虫 7月月更

百问百答第48期:极客有约——可观测体系的建设路径

博睿数据

可观测性 智能运维 博睿数据 性能监测 极客有约

iOS单元测试的那些事儿

珲少

TDSQL-C Serverless:助力初创企业实现降本增效

石云升

全球架构师峰会 ArchSummit

为什么说React是UI的未来_语言 & 开发_Jani Eväkallio_InfoQ精选文章