十年过去了，UI 框架还停滞在原地……-外链论坛

qzmjef 发表于 2024-10-3 18:03:40

十年过去了，UI 框架还停滞在原地……

<div style="color: black; text-align: left; margin-bottom: 10px;">
 <div style="color: black; text-align: left; margin-bottom: 10px;">
 <img src="https://p3-sign.toutiaoimg.com/tos-cn-i-axegupay5k/53c16e3a2ef140bebce85b79ce939dba~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1728111566&x-signature=52%2BnsPFDVd5wGAVAqc4DMxHX3bk%3D" style="width: 50%; margin-bottom: 20px;">
 【CSDN 编者按】这篇文案是一位前端研发者揭示了主流 UI 框架的局限性，认为它们都在误导研发者，隐匿了 DOM 节点的真实繁杂性。作者指出 HTML 语法并不是描述 UI 的最佳抽象，而是 DOM 树的一种投影。HTML 没法有效地表达 DOM 节点的七类属性，而只能将它们混合在一块。作者认为开发者应该面对并理解 DOM 节点的自然繁杂性，而不是被框架所迷惑。作者亦说到了 Svelte 5 的 runes 特性，暗示对其有必定的期待。
 原文链接：https://moonthought.github.io/posts/all-your-mainstream-ui-frameworks-are-lying-to-you/
 未经准许，禁止转载！作者 | moonthought.github.io 译者 | 明明如月 责编 | 夏萌出品 | CSDN（ID：CSDNnews）
 <img src="https://p3-sign.toutiaoimg.com/tos-cn-i-tjoges91tu/d733415aa4200b5d75418b2d35bb4088~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1728111566&x-signature=%2BCb6RMBsDAoX0r6xia9CYZLb3YY%3D" style="width: 50%; margin-bottom: 20px;">
 <h2 style="color: black; text-align: left; margin-bottom: 10px;">Svelte 的全新篇章</h2>
 几天前，Svelte 5 的预览版本随着对 runes 的仔细介绍被公研发布。该信息令包含我在内众多人士激动不已。$props、$derived、$effects、$state、信号等概念，我并非第1次接触，我在 5-6 年前就见过这般的响应式处理机制。我认为 Svelte 正沿着正确的方向演进。虽然 Svelte 仍然运用了有些主流但不太适合处理繁杂 Web 问题的方法，我仍然期望她们能够克服这些困难。不外，这并非本文今天要探讨的核心议题。
 令我不解的是，人们在处理 UI 问题时仍采用一样的权宜之计。
 为何组件的响应性处理方法仍然需要编译周期？为么咱们还在运用非标准的 HTML 语法和一系列自定义指令？为么 UI 的描述仍然是以命令式的方式进行？为何技术界还在奋斗模仿 HTML？
 让咱们从最后一个问题起始探讨。
 <img src="https://p3-sign.toutiaoimg.com/tos-cn-i-tjoges91tu/9cc696d4316f1426631857c88ba7e709~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1728111566&x-signature=t1IhGqnjxCSjzIXH5pE%2FnUXGyA8%3D" style="width: 50%; margin-bottom: 20px;">
 <h2 style="color: black; text-align: left; margin-bottom: 10px;">HTML 到底是不是合适的抽象层？</h2>
 这个问题可能会诱发不少争议，但事实上，HTML 仅仅是 DOM（文档对象模型）树的一种表现形式，而这种表现形式并非必定是最优的。确切地说，浏览器处理的不是 HTML，而是 DOM 节点。一个完整的 DOM 节点应该包含以下七类属性：
 属性（Attributes）
 事件处理器（Event Handlers）
 样式（Styles）
 自定义数据属性（Data-* Attributes）
 可见性（Visibility）
 文本内容（Text Content）
 子节点（Children）
 遗憾的是，许多研发者要么无认识到这种繁杂性是不可避免的，要么便是不愿承认。几乎所有现有的 UI 处理方法都在运用一种过于简化的方式试图把这种繁杂性忽略掉，这是不可取的。
 这些处理方法都试图把 DOM 节点属性的多样性简化为一个扁平的属性列表，这种做法显然不切实质。即便将七大类 DOM 节点属性简化为一张扁平的属性列表，这些属性的多样性仍然会存在，只是变成为了一堆难以管理的碎片信息。
 复杂性重点有两类：人为引入的繁杂性和自然存在的繁杂性。人为引入的繁杂性一般来自库、框架、编程语言和设计范式等。而自然繁杂性则是平台本身固有的，用于处理特定行业的基本问题。优秀的工程师会奋斗减少人为引入的繁杂性，同期积极面对和处理自然繁杂性。咱们应当再也不回避这种自然存在的繁杂性，而是应更加尊重和理解咱们所运用的平台。
 Rich Harris 发布了一则精彩的视频，仔细解释了 getter 和 setter 的实质运作原理，并回复了公众对 Svelte 新响应机制的疑惑。然而，他无对“需要编写更加多代码”这一观点进行充分解释。最后目的不仅是编写更少的代码，而是用最少量的代码知道地表达应用的意图。倘若某项技术所强调或独一供给的便是“简单性”，那样你可能就忽略了有些关键的细节。这些问题迟早会从其他方向显现。
 实质上，选取 onClick={...}, on:click={...}和 @click="..." 并无多少差异。
 这种处理方法之因此存在，某种程度上是能够理解的：
 技术栈运用起来简单，但设计困难。
 初期应用一般较为简单，因此呢基本的模板就可满足 DOM API 的需要。
 这种代码的性能直到近几年（约 4-5 年）才真正达到了足够好的水平。
 重点原由实质上是：
 你需要投入海量时间进行实验，并愿意接受新的现实和当前办法的不足。
 令人遗憾的是，大都数人几乎无多余的时间来做这些事情。我不怪罪于她们，每一个人都有自己的局限性。但这种局面每年令我感到越发懊丧。难道你们不觉得针对 HOCs、render-props、持续变化的自定义语法以及其它有些火速就被咱们遗弃的技术，浪费的时间太可惜了？
 我越来越认为这其中有直接的联系：应用程序的研发和守护仍然是一项困难和成本昂贵的任务。而咱们却在消耗精力进行各样妥协，而非学习如何更有效地利用最少一个平台。
 <img src="https://p3-sign.toutiaoimg.com/tos-cn-i-tjoges91tu/b1a415f92533c6f44f68fd0415fcdb31~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1728111566&x-signature=7yKsm%2FjS6GuCJsbGqXB6h69w2tQ%3D" style="width: 50%; margin-bottom: 20px;">
 <h2 style="color: black; text-align: left; margin-bottom: 10px;">被“篡改”的语法</h2>
 人们常对 React 的 JSX 语法、Vue 的模板语法，或 Svelte 的组件方式有不少批评。这些批评并非无道理，但更重要的一点是：它们受到质疑并不是由于缺乏优良。而是由于这些方法本质上是不准确的编程抽象。各框架之间的差异远非表面上看起来那样简单。
 下面我将经过代码示例来阐明我的观点：
 Reactfunction Component() { return ( <div> <h1>Hey there</h1> </div> );}
 Vue<template> <div> <h1>Hey there</h1> </div></template>
 Svelte<div> <h1>Hey there</h1></div>
 实质上，它们看起来都不错。
 此刻，让咱们尝试添加有些要求渲染:
 Reactfunction ConditionalComponent({ showMessage }) { return ( <div> {showMessage ? ( <h1>Hey there</h1>) : }</div>);}...<ConditionalComponent showMessage={true} />
 Vue<template> <div> <h1 v-if="showMessage">Hey there</h1> </div></template><script> export default { name: ConditionalComponent, props: { showMessage: Boolean } }</script>...<ConditionalComponent :showMessage="true" />
 Svelte<div>{#if showMessage} <h1>Hey there</h1> {/if}</div>...<ConditionalComponent showMessage={true} />首要，让咱们聊聊视图树（View Tree）内部的 if语句。是不是能够用空值或某种插件组件做为回退呢？这是一种指令还是模板块？需要知道的是，这种设计在 DOM API 中是不存在的，只能叫作其为一种权宜之计。问题不仅在于命名，更在于全部概念的设立。例如，v-if 和 {#if ...} 便是这般的表现。Vue 无疑是这一现象的重要表率。你有两种选取：要么频繁地创建和销毁组件，要么简单地隐匿组件（经过 display: none等）。在 2023 年，这种实践已然过时，是对浏览器和 DOM API 的一种不尊重。当然，问题并非仅存在于 Vue。以 React 为例，其函数组件因为 hooks 机制的特性，内容经常充满副功效。这引起了即使无必要，亦会过度依赖重新渲染来重新计算副功效和更新数据。平常的观点是：“React 会引起额外的重新渲染，但其核心机制目的是优化性能并保持 UI 与应用数据的同步。”然而，实质操作中，大都数研发者都在奋斗减少重新渲染。像useMemo 这般的优化办法，并不可保准避免额外的渲染。显然，这些都是权宜之计和不必要的妥协。快速和优化的重新渲染并不可处理基本问题。真正的处理方法应在于消除重新渲染这一现象。这能够经过全部界面树的静态初始化来达到。简言之，每一个元素（或更准确地说，堆栈内元素的回调函数）应只计算和调用一次，以实现响应式值和节点的绑定。此后，只需按照 DOM 结构图来处理流程和事件。当然，其他技术一样存在不足，但这是另一个专题。那样，渲染列表呢？Reactfunction UserList() { return ( <div> <ul> {users.map(user => ( <li key={user.id}>{user.name}</li> ))}</ul> </div>);}Vue<template> <div> <ul> <li v-for="user in users" :key="user.id">{{ user.name }}</li> </ul> </div></template>Svelte<div> <ul> {#each users as user (user.id)} <li>{user.name}</li> {/each} </ul></div>各样自定义语法、模板和指令显现眼前。然而，谁能保证这些实此刻将来不会出现变化呢？事实上，这种状况在过去已然显现过，如 React 和 Vue。倘若这些技术一旦失去主流地位，又将怎样防止它们沦为难以守护的遗留系统？这诱发出一个新的问题：为何无论是研发者还是框架的创造者，都连续地采用与平台习惯相违背的技术？<img src="https://p3-sign.toutiaoimg.com/tos-cn-i-tjoges91tu/d3287d250906a77557ad9f9f21c6a32c~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1728111566&x-signature=%2FVeaxETM49v6wfiKkA9oIilrOPk%3D" style="width: 50%; margin-bottom: 20px;"><h2 style="color: black; text-align: left; margin-bottom: 10px;">深入探索 DOM API</h2>继续讨论现有问题的潜在处理方法，让咱们将目光转向 DOM API。这是一个历经数年精研且功能丰富的库。有些功能实质上是你不可仅经过属性（props）来规避的。当面对要求渲染的需要时，DOM API 供给了多个处理方法，如 node.append() 和 node.appendChild() 办法，还有 node.remove() 办法以及 node.isConnected 属性。这些 API 让咱们能够随时向 DOM 树添加或移除节点，并检测节点是不是与 DOM 树连接。React 便是基于这般的原理进行操作的。这儿需要指出的是，许多框架或库在组件设计时，无给予 DOM 节点状态管理足够的注重。实质上，组件自己应当负责管理与 DOM 树连接的节点以及这些节点的子节点的状态，而不该该由外边模块来进行。思虑以下代码示例：export function Component({ showMessage }) { h(div, () => { h(h1, { text: Hey there, visible: showMessage, }) })}这儿并无运用任何特殊的语法或扩展，亦无试图隐匿任何基本规律。它仅仅是一个用于方便 DOM 操作的普通 JavaScript 函数。在应用程序中，这般的组件依然能够像普通函数同样运用：using(body, () => { Component({ showMessage: true })})这种设计思路受到了 SwiftUI 和 Flutter 的影响。其中，第二个回调参数是 SwiftUI 的嵌套组件块的替代品，而visible 属性则与 Flutter 中的同名属性相对应。值得重视的是，这儿的 visible 并非 Vue 的“hack”，而是用于直接插进或移除 DOM 子树的属性。总而言之，咱们无需额外发明抽象语法来模拟咱们需要的行径。JavaScript 做为前端研发的“本土”语言，持有其独特的优良和功能。试图用替代方法来规避它，最后只会使问题变得更加繁杂。这一点在以往的研发实践中已然得到了充分的证明。在当然，visible 属性的应用规律相当直观。接着要解释怎样渲染一个组件列表。首要，让咱们看一下关联的代码实现：export const function User({ key, name, isRestricted }) { h(li, { attr: { id: key }, text: name, visible: isRestricted, classList: ["border-gray-200"] })}using(document.body, () => { h(ul, () => { list(users, ({ store: user, key: idx }), () => { User({ key: idx, name: user.name, isRestricted: user.isRestricted }) }) })})这种实现方式在某种程度上借鉴了 SwiftUI 的设计：List(users) { user in // 运用 user}更值得重视的是，代码中所有用到的变量或属性都支持响应式更新。这寓意着，当用户列表或其关联属性有所改变，这些改变会即时反映在最后的布局中。另外，这种 list办法实现并不像表面上看起来那样简单。系统会预生成用于该应用的模板（这儿的模板指的是 JS 模板，与 Vue 或其他框架的模板区别）。因此，每当响应式变量users 出现变化时，咱们只需利用已然预设好的模板生成一个新的实例，而不是在运行时重新计算所有元素。但不幸的是，许多现代处理方法利用虚拟 DOM 和调和（Reconciliation），引入了周期来双重检测从组件返回的结构的变化。这就引起了重绘和性能问题。以及有些人为的约束。不得不说，Svelte 做得很好。Svelte 不依赖于虚拟 DOM，而是运用编译器将组件转换为 JavaScript。这个 JS 代码会非常有效，然则，遗憾的是，其他问题亦显现了：不必要的构建过程，Svelte 特有的代码并无真正从最后的包中移除。况且咱们仍然有重渲染的问题。针对事件处理器和属性规范，该怎样优雅地管理呢？以下是一个实用的代码示例：using(document.body, () => { h(section, () => { spec({ style: {width: 15em} }); h(form, () => { spec({ handler: { config: { prevent: true }, on: { submit }, }, style: { display: flex, flexDirection: column, }, }); h(input, { attr: { placeholder: Username }, handler: { input: changeUsername }, }); h(input, { attr: { type: password, placeholder: Password }, classList: [w-full, py-2, px-4], handler: { input: changePassword }, }); h(button, { text: Submit, attr: { disabled: fields.map( fields => !(fields.username && fields.password), ), }, }); }); });});在这段代码中，changeUsername 和 changePassword 是用于响应用户输入并动态更新相应值的事件处理器。而 fields 是一个包括关联属性的响应式对象。实质上，这个 fields 对象便是一个数据存储，不论个人爱好怎样。咱们还采用了 map() 办法来创建一个派生属性，这在 Svelte 中对应 $derived。这个派生属性会在用户名或秘码出现变更时同步更新，从而改变提交按钮的状态。针对这段代码，你初次浏览可能会有以下几种看法：这种写法不太平常代码过于繁琐需要手动处理 DOM API 的各个细节然而，事实真的是这般吗？首要，代码中并无什么反常的内容，这些都是基本的 JavaScript 函数。详细来讲：attr - 用于定义节点属性的对象。style - 用于设置节点样式的对象。classList - 一个包括节点类名的数组，该名叫作与 DOM API 的官方命名一致。handler - 节点事件处理器的配置对象，如你所见 config: { prevent: true }。spec- 实质上是一个包装函数，用于描述节点属性类别。当组件的回调函数内有子元素时，你能够在组件的最外层（或回调函数中的任何地区，尽管这并不是重点）设定一组属性。确实，相比于 React、Vue、Svelte、Solid 等，这种方式更显繁琐。但这般的设计方式不会让你对前端的繁杂性有所误解，亦不会给你一个所说的“简单处理方法”。事实上，你应该面对这些现实，而不是逃避。这会让你更清晰地认识应用是怎样构建的。虽然这种办法比较繁琐，但它真的繁杂到让你难以理解吗？我相信你完全能够理解每一行代码的功效。其次，你并不需要直接操作 DOM API。你真正需要的是一个简洁的 JavaScript API 用于与 DOM 进行交互。我坚信，视图树的管理应该由原生工具来完成。哪些需要手动添加、删除、更新树结构的操作都能够由底层技术来完成。我要再次强调，我的目的不是推崇某个特定的新技术处理方法。相反，我期盼能指显现有方法中存在的问题，并讨论怎样用原生工具来处理这些问题，而无需重新发明轮子。最后，我想提醒大众，尊重你所运用的平台是很重要的。其他平台的研发人员都已然学会了怎样与她们的平台和谐共处。与此区别，前端研发人员有时会尝试用新的、还不足成熟的处理方法来处理问题。<img src="https://p3-sign.toutiaoimg.com/tos-cn-i-tjoges91tu/b9f6990fbedf87070fbcfd52383245b1~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1728111566&x-signature=NCZg7ar3c%2B0fxv3yj0mdtvqhD%2Fs%3D" style="width: 50%; margin-bottom: 20px;"><h2 style="color: black; text-align: left; margin-bottom: 10px;">事情并没那样简单</h2>用简单的例子来展示实质场景是有难度的，由于某些问题在简单的例子中可能不会显现。例如，在一个真实应用中，你可能会这般描述一个表单：export const Auth = ()=> { h("div", () => { spec({ classList: ["mt-10", "max-w-sm", "w-full"], }); h("form", () => { Input({ type: "email", label: "电子邮件",inputChanged: authForm.fields.email.changed, errorText: authForm.fields.email.$errorText, errorVisible: authForm.fields.email.$errors.map(Boolean), }); Input({ type: "password", label: "秘码",inputChanged: authForm.fields.password.changed, errorText: authForm.fields.password.$errorText, errorVisible: authForm.fields.password.$errors.map(Boolean),}); Button({ text: "创建", event: authForm.submit, size: "base", prevent: true, variant: "default", }); ErrorHint($authError, $authError.map(Boolean)); }); });};...exportconst Input = ({ value, type, label, required, inputChanged, errorVisible, errorText,}: { value?: Store<string>; type: string; label: string; required?: boolean;inputChanged: Event<any>; errorVisible?: Store<boolean>; errorText?: Store<string>;}) => { h("div", () => { spec({ classList: ["mb-6"], }); h("label", () => { spec({classList: ["block", "mb-2", "text-sm", "font-medium", "text-gray-900", "dark:text-white"], text: label, }); }); h("input", () => { constlocalInputChanged = createEvent<any>(); sample({ source: localInputChanged, fn: (event) => event.target.value, target: inputChanged, }); spec({ classList: [ "bg-gray-50", "border","border-gray-300", "text-gray-900", "text-sm", "rounded-lg", "focus:ring-blue-500", "focus:border-blue-500", "block", "w-full", "p-2.5", "dark:bg-gray-700","dark:border-gray-600", "dark:placeholder-gray-400", "dark:text-white", "dark:focus:ring-blue-500", "dark:focus:border-blue-500", ], attr: { type: type, required: Boolean(required), value: value || createStore("") }, handler: { on: { input: localInputChanged } }, }); }); ErrorHint(errorText, errorVisible); });};...export const ErrorHint = (text: Store<string> | string | undefined, visible: Store<boolean> | undefined) => { h("p", { classList: ["mt-2", "text-sm", "text-red-600", "dark:text-red-400"], visible: visible || createStore(false), text: text || createStore(""), });};运用带有标签、属性和动态内容的预定义卡片来描述有些日志列表怎么样？export const LogsList = () => {h("div", () => { spec({ classList: ["flex", "flex-col", "space-y-6", "mt-2"], }); list(logModel.$logsGroups, ({ store: group }) => { CardHeaded({ tags: group.map((g)=> g.tags), href: group.map((g) => `${g.schema_name}/${g.group_hash}`), content: () => { LogsTable(group.map((g) => g.logs)); }, withMore: true, }); }); });};无需深究这儿的 createStore 和 createEvent，Store 本质上是一个响应式数据结构，而 Event 则是用于修改这些数据或触发某种效果的信号，这些都能够从任何库中获取。这儿的关键点是怎样描述视图和视图规律。即使视图描述存在差异，亦不寓意着必定要寻求全新的处理方法。你是不是确信现有方法已然是最优的？倘若不是，你能知道指出原由吗？<img src="https://p3-sign.toutiaoimg.com/tos-cn-i-tjoges91tu/751d43f744ecde8529da76992b12614d~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1728111566&x-signature=toIEd%2FHMY6bG%2B%2Bi5cgpJiqxsZpY%3D" style="width: 50%; margin-bottom: 20px;"><h2 style="color: black; text-align: left; margin-bottom: 10px;">为何咱们需要改变思维方式</h2>你亦许会误以为我对现有的主流处理方法持批判态度，但事实并非如此。我相信这些技术在必定程度上都是必要的。或说，曾经是必要的，最少针对通常的前端研发而言。但我不爱好的是，咱们似乎陷入了过去十年的思维模式，无人在主流中试图提醒研发者重视这个问题。结果，咱们的应用程序仍然无可重现性，况且即使是简单的任务，亦需要很高的劳动强度。我并不意见咱们抛弃所有现有的处理方法，这般做是愚蠢的。我亦不意见每次都自己手动操作 DOM。这些工作应由库 / 框架 / 技术 / API / 或其他何种形式来完成。我只想说，亦许是时候停止实施存在严重设计缺陷的独特的“雪花”类型解决方法了？并起始利用咱们自己的平台供给给咱们的东西，发挥其功效。亦许不是以之前呈现的形式，但以某种其他形式。最少在我看来，存在潜在的可能性。然而，非常多人并无认识到当前做法的局限性，反而继续在有些独特的但有严重设计缺陷的处理方法中做选取。前端研发者应该尊重自己的平台，不要被过时的技术所捆绑，而要勇于面对现实和进行技术创新。你认为 UI 架构在过去十年停滞的原由是什么？你认为应该从那些方面进行创新性突破？欢迎在评论区留言讨论。参考链接runes 的仔细介绍：https://svelte.dev/blog/runesnode.append()：https://developer.mozilla.org/en-US/docs/Web/API/Element/appendnode.appendChild()：https://developer.mozilla.org/en-US/docs/Web/API/Node/appendChildnode.remove()：https://developer.mozilla.org/en-US/docs/Web/API/Element/removenode.isConnected：https://developer.mozilla.org/en-US/docs/Web/API/Node/isConnectedDOM API 的官方命名：https://developer.mozilla.org/en-US/docs/Web/API/Element/classList<img src="https://p26-sign.toutiaoimg.com/tos-cn-i-tjoges91tu/1ce8925ef6864e3868bd6acc301e472c~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1728111566&x-signature=0IZ0ppJHiSC7p3udgjirWL7OfTY%3D" style="width: 50%; margin-bottom: 20px;">欢迎参与 CSDN 重磅发起的《2023 AI 研发者生态调查问卷》，分享您真实的 AI 运用体验，更有精美好礼等你拿！<img src="https://p3-sign.toutiaoimg.com/tos-cn-i-tjoges91tu/7b9207424fcac0f7467fdd6a37f8d6f9~noop.image?_iz=58558&from=article.pc_detail&lk3s=953192f4&x-expires=1728111566&x-signature=a3rVt9I%2FPM8zPS8dLiYPrlGX4Z4%3D" style="width: 50%; margin-bottom: 20px;"></div></div>

b1gc8v 发表于 2024-10-8 03:56:20

回顾历史，我们不难发现：无数先辈用鲜血和生命铺就了中华民族复兴的康庄大道。

页: [1]

外链论坛's Archiver

十年过去了，UI 框架还停滞在原地……