整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
译 ｜ 核子可乐、Tina
技术和软件开发领域存在一种有趣的现象，就是同样的模式迭起兴衰、周而复始。
过去Web非常简单。URL 指向服务器，服务器将数据混合成 html，然后在浏览器上呈现该响应。围绕这种简单范式，诞生了各种Javascript框架，以前可能需要数月时间完成的一个应用程序基本功能，现在借助这些框架创建相对复杂的项目却只需要数小时，我们节省了很多时间，从而可以将更多精力花在业务逻辑和应用程序设计上。
但随着 Web 不断地发展，Javascript 失控了。不知何故，我们决定向用户抛出大量 App，并在使用时发出不断增加的网络请求；不知何故，为了生成 html，我们必须使用 JSON，发出数十个网络请求，丢弃我们在这些请求中获得的大部分数据，用一个越来越不透明的 JavaScript 框架黑匣子将 JSON 转换为 html，然后将新的 html 修补到 DOM 中......
难道大家快忘记了我们可以在服务器上渲染 html 吗？更快、更一致、更接近应用程序的实际状态，并且不会向用户设备发送任何不必要的数据？但是如果没有 Javascript，我们必须在每次操作时重新加载页面。
现在，有一个新的库出现了，摒弃了定制化的方法，这就是 htmx。作为 Web 开发未来理念的一种实现，它的原理很简单：
htmx 出现在 2020 年，创建者 Carson Gross 说 htmx 来源自他于 2013 年研究的一个项目 intercooler.js。2020 年，他重写了不依赖 jQuery 的 intercooler.js，并将其重命名为 htmx。然后他惊讶的发现 Django 社区迅速并戏剧性地接受了它！
图片来源：https://lp.jetbrains.com/django-developer-survey-2021-486/
Carson Gross 认为 htmx 设法抓住了开发者对现有 Javascript 框架不满的浪潮，“这些框架非常复杂，并且经常将 Django 变成一个愚蠢的 JSON 生产者”，而 htmx 与开箱即用的 Django 配合得更好，因为它通过 html 与服务器交互，而 Django 非常擅长生成 html。
对于 htmx 的迅速走红，Carson Gross 发出了一声感叹：这真是“十年窗下无人问，一举成名天下知（this is another example of a decade-long overnight success）”。
可以肯定的一点是 htmx 绝对能用，单从理论上讲，这个方法确实值得称道。但软件问题终究要归结于实践效果：效果好吗，能不能给前端开发带来改善？
在 DjangoCon 2022 上，Contexte 的 David Guillot 演示了他们在真实 SaaS 产品上实现了从 React 到 htmx 的迁移，而且效果非常好，堪称“一切 htmx 演示之母”（视频地址：https://www.youtube.com/watch?v=3GObi93tjZI）。
Contexte 的项目开始于 2017 年，其后端相当复杂，前端 UI 也非常丰富，但团队非常小。所以他们在一开始的时候跟随潮流选择了 React 来“构建 API 绑定 SPA、实现客户端状态管理、前后端状态分离”等。但实际应用中，因为 API 设计不当，DOM 树太深，又需要加载很多信息，导致 UI“非常非常缓慢”。在敏捷开发的要求下，团队里唯一的 Javascript 专家对项目的复杂性表现得一无所措，因此他们决定试试 htmx。
于是我们决定大胆尝试，花几个月时间用简单的 Django 模板和 htmx 替换掉了 SaaS 产品中已经使用两年的 React UI。这里我们分享了一些相关经验，公布各项具体指标，希望能帮同样关注 htmx 的朋友们找到说服 CTO 的理由！
6. 将 Web 构建时间缩短了 88%（由 40 秒缩短至 5 秒）
7. 首次加载交互时间缩短了 50% 至 60%（由 2 到 6 秒，缩短至 1 到 2 秒）
8. 使用 htmx 时可以配合更大的数据集，超越 React 的处理极限
9. Web 应用程序的内存使用量减少了 46%（由 75 MB 降低至 40 MB）
这些数字令人颇为意外，也反映出 Contexte 应用程序高度契合超媒体的这一客观结果：这是一款以内容为中心的应用程序，用于显示大量文本和图像。很明显，其他 Web 应用程序在迁移之后恐怕很难有同样夸张的提升幅度。
但一些开发者仍然相信，大部分应用程序在采用超媒体 /htmx 方法之后，肯定也迎来显著的改善，至少在部分系统中大受裨益。
可能很多朋友没有注意，移植本身对团队结构也有直接影响。在 Contexte 使用 React 的时候，后端与前端之间存在硬性割裂，其中两位开发者全职管理后端，一位开发者单纯管理前端，另有一名开发者负责“全栈”。（这里的「全栈」，代表这位开发者能够轻松接手前端和后端工作，因此能够在整个「栈」上独立开发功能。）
而在移植至 htmx 之后，整个团队全都成了“全栈”开发人员。于是每位团队成员都更高效，能够贡献出更多价值。这也让开发变得更有乐趣，因为开发人员自己就能掌握完整功能。最后，转向 htmx 也让软件优化度上了一个台阶，现在开发人员可以在栈内的任意位置进行优化，无需与其他开发者提前协调。
如今，单页应用（SPA）可谓风靡一时：配合 React、Redux 或 Angular 等库的 JS 或 TS 密集型前端，已经成为创建 Web 应用程序的主流方式。以一个需要转译成 JS 的 SPA 应用为例：
但 htmx 风潮已经袭来，人们开始强调一种“傻瓜客户端”方法，即由服务器生成 html 本体并发送至客户端，意味着 UI 事件会被发送至服务器进行处理。
用这个例子进行前后对比，我们就会看到前者涉及的活动部件更多。从客户端角度出发，后者其实回避了定制化客户端技术，采取更简单的方法将原本只作为数据引擎的服务器变成了视图引擎。
后一种方法被称为 AJAX（异步 JavaScript 与 XML）。这种简单思路能够让 Web 应用程序获得更高的响应性体验，同时消除了糟糕的“回发”（postback，即网页完全刷新），由此回避了极其低效的“viewstate”等.NET 技术。
htmx 在很多方面都体现出对 AJAX 思路的回归，最大的区别就是它仅仅作为新的声明性 html 属性出现，负责指示触发条件是什么、要发布到哪个端点等。
另一个得到简化的元素是物理应用程序的结构与构建管道。因为不再涉及手工编写 JS，而且整个应用程序都基于服务器，因此不再对 JS 压缩器、捆绑器和转译器做（即时）要求。就连客户端项目也能解放出来，一切都由 Web 服务器项目负责完成，所有应用程序代码都在.NET 之上运行。从这个角度来看，这与高度依赖服务器的 Blazor Server 编程模型倒是颇有异曲同工之妙。
技术和软件开发领域存在一种有趣的现象，就是同样的模式迭起兴衰、周而复始。随着 SPA 的兴起，人们一度以为 AJAX 已经过气了，但其基本思路如今正卷土重来。这其中当然会有不同的权衡，例如更高的服务器负载和网络流量（毕竟现在我们发送的是数据视图，而不只是数据），但能让开发者多个选择肯定不是坏事。
虽然不敢确定这种趋势是否适用于包含丰富用户体验的高复杂度应用程序，但毫无疑问，相当一部分 Web 应用程序并不需要完整的 SPA 结构。对于这类用例，简单的 htmx 应用程序可能就是最好的解决方案。
参考链接：
https://news.ycombinator.com/item?id=33218439
https://www.reddit.com/r/django/comments/rxjlc6/htmx_gaining_popularity_rapidly/
https://mekhami.github.io/2021/03/26/htmx-the-future-of-web/
https://www.compositional-it.com/news-blog/more-on-htmx-back-to-the-future/
声明：本文为InfoQ编译，未经许可禁止转载。
多数设备的刷新频率是60Hz，也就说是浏览器对每一帧画面的渲染工作要在16ms内完成,超出这个时间，页面的渲染就会出现卡顿现象，影响用户体验。前端的用户体验给了前端直观的印象，因此对B/S架构的开发人员来说，熟悉浏览器的内部执行原理显得尤为重要。
浏览器大体上由以下几个组件组成，各个浏览器可能有一点不同。
注意：chrome浏览器与其他浏览器不同，chrome使用多个渲染引擎实例，每个Tab页一个，即每个Tab都是一个独立进程。
Chrome浏览器使用多个进程来隔离不同的网页，在Chrome中打开一个网页相当于起了一个进程，每个tab网页都有由其独立的渲染引擎实例。因为如果非多进程的话，如果浏览器中的一个tab网页崩溃，将会导致其他被打开的网页应用。另外相对于线程，进程之间是不共享资源和地址空间的，所以不会存在太多的安全问题，而由于多个线程共享着相同的地址空间和资源，所以会存在线程之间有可能会恶意修改或者获取非授权数据等复杂的安全问题。
在内核控制下各线程相互配合以保持同步，一个浏览器通常由以下常驻线程组成：
GUI渲染线程负责渲染浏览器界面HTML元素,当界面需要重绘(Repaint)或由于某种操作引发回流(reflow)时，该线程就会执行。在Javascript引擎运行脚本期间,GUI渲染线程都是处于挂起状态的，也就是说被冻结了.
JS为处理页面中用户的交互，以及操作DOM树、CSS样式树来给用户呈现一份动态而丰富的交互体验和服务器逻辑的交互处理。如果JS是多线程的方式来操作这些UI DOM，则可能出现UI操作的冲突；如果JS是多线程的话，在多线程的交互下，处于UI中的DOM节点就可能成为一个临界资源，假设存在两个线程同时操作一个DOM，一个负责修改一个负责删除，那么这个时候就需要浏览器来裁决如何生效哪个线程的执行结果，当然我们可以通过锁来解决上面的问题。但为了避免因为引入了锁而带来更大的复杂性，JS在最初就选择了单线程执行。
GUI渲染线程与JS引擎线程互斥的，是由于JavaScript是可操纵DOM的，如果在修改这些元素属性同时渲染界面（即JavaScript线程和UI线程同时运行），那么渲染线程前后获得的元素数据就可能不一致。当JavaScript引擎执行时GUI线程会被挂起，GUI更新会被保存在一个队列中等到引擎线程空闲时立即被执行。由于GUI渲染线程与JS执行线程是互斥的关系，当浏览器在执行JS程序的时候，GUI渲染线程会被保存在一个队列中，直到JS程序执行完成，才会接着执行。因此如果JS执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞的感觉。
浏览器定时计数器并不是由JS引擎计数的, 因为JS引擎是单线程的, 如果处于阻塞线程状态就会影响记计时的准确, 因此通过单独线程来计时并触发定时是更为合理的方案。
当一个事件被触发时该线程会把事件添加到待处理队列的队尾，等待JS引擎的处理。这些事件可以是当前执行的代码块如定时任务、也可来自浏览器内核的其他线程如鼠标点击、AJAX异步请求等，但由于JS的单线程关系所有这些事件都得排队等待JS引擎处理。
在XMLHttpRequest在连接后是通过浏览器新开一个线程请求，将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件放到JS引擎的处理队列中等待处理。
用户请求的HTML文本(text/html)通过浏览器的网络层到达渲染引擎后，渲染工作开始。每次通常渲染不会超过8K的数据块，其中基础的渲染流程图：
webkit引擎渲染的详细流程，其他引擎渲染流程稍有不同：
渲染流程有四个主要步骤：
以上步骤是一个渐进的过程，为了提高用户体验，渲染引擎试图尽可能快的把结果显示给最终用户。它不会等到所有HTML都被解析完才创建并布局渲染树。它会在从网络层获取文档内容的同时把已经接收到的局部内容先展示出来。
DOM树的构建过程是一个深度遍历过程：当前节点的所有子节点都构建好后才会去构建当前节点的下一个兄弟节点。DOM树的根节点就是document对象。
DOM树的生成过程中可能会被CSS和JS的加载执行阻塞，具体可以参见下一章。当HTML文档解析过程完毕后，浏览器继续进行标记为deferred模式的脚本加载，然后就是整个解析过程的实际结束触发DOMContentLoaded事件，并在async文档文档执行完之后触发load事件。
生成DOM树的同时会生成样式结构体CSSOM（CSS Object Model）Tree，再根据CSSOM和DOM树构造渲染树Render Tree，渲染树包含带有颜色，尺寸等显示属性的矩形，这些矩形的顺序与显示顺序基本一致。从MVC的角度来说，可以将Render树看成是V，DOM树与CSSOM树看成是M，C则是具体的调度者，比HTMLDocumentParser等。
可以这么说，没有DOM树就没有Render树，但是它们之间不是简单的一对一的关系。Render树是用于显示，那不可见的元素当然不会在这棵树中出现了，譬如 <head>。除此之外，display等于none的也不会被显示在这棵树里头，但是visibility等于hidden的元素是会显示在这棵树里头的。
DOM对象类型很丰富，什么head、title、div，而Render树相对来说就比较单一了，毕竟它的职责就是为了以后的显示渲染用嘛。Render树的每一个节点我们叫它渲染器renderer。
一棵Render树大概是酱紫，左边是DOM树，右边是Render树：
从上图我们可以看出，renderer与DOM元素是相对应的，但并不是一一对应，有些DOM元素没有对应的renderer，而有些DOM元素却对应了好几个renderer，对应多个renderer的情况是普遍存在的，就是为了解决一个renderer描述不清楚如何显示出来的问题，譬如有下拉列表的select元素，我们就需要三个renderer：一个用于显示区域，一个用于下拉列表框，还有一个用于按钮。
另外，renderer与DOM元素的位置也可能是不一样的。那些添加了 float或者 position:absolute的元素，因为它们脱离了正常的文档流，构造Render树的时候会针对它们实际的位置进行构造。
上面确定了renderer的样式规则后，然后就是重要的显示元素布局了。当renderer构造出来并添加到Render树上之后，它并没有位置跟大小信息，为它确定这些信息的过程，接下来是布局(layout)。
浏览器进行页面布局基本过程是以浏览器可见区域为画布，左上角为 (0,0)基础坐标，从左到右，从上到下从DOM的根节点开始画，首先确定显示元素的大小跟位置，此过程是通过浏览器计算出来的，用户CSS中定义的量未必就是浏览器实际采用的量。如果显示元素有子元素得先去确定子元素的显示信息。
布局阶段输出的结果称为box盒模型（width,height,margin,padding,border,left,top,…），盒模型精确表示了每一个元素的位置和大小，并且所有相对度量单位此时都转化为了绝对单位。
在绘制(painting)阶段，渲染引擎会遍历Render树，并调用renderer的 paint() 方法，将renderer的内容显示在屏幕上。绘制工作是使用UI后端组件完成的。
回流(reflow)：当浏览器发现某个部分发生了点变化影响了布局，需要倒回去重新渲染。reflow 会从 <html>这个 root frame 开始递归往下，依次计算所有的结点几何尺寸和位置。reflow 几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。通常我们都无法预估浏览器到底会 reflow 哪一部分的代码，它们都彼此相互影响着。
重绘(repaint)：改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性时，屏幕的一部分要重画，但是元素的几何尺寸没有变。
每次Reflow，Repaint后浏览器还需要合并渲染层并输出到屏幕上。所有的这些都会是动画卡顿的原因。Reflow 的成本比 Repaint 的成本高得多的多。一个结点的 Reflow 很有可能导致子结点，甚至父点以及同级结点的 Reflow 。在一些高性能的电脑上也许还没什么，但是如果 Reflow 发生在手机上，那么这个过程是延慢加载和耗电的。可以在csstrigger上查找某个css属性会触发什么事件。
reflow与repaint的时机：
在浏览器拿到HTML、CSS、JS等外部资源到渲染出页面的过程，有一个重要的概念关键渲染路径（Critical Rendering Path）。例如为了保障首屏内容的最快速显示，通常会提到一个渐进式页面渲染，但是为了渐进式页面渲染，就需要做资源的拆分，那么以什么粒度拆分、要不要拆分，不同页面、不同场景策略不同。具体方案的确定既要考虑体验问题，也要考虑工程问题。了解原理可以让我们更好的优化关键渲染路径，从而获得更好的用户体验。
现代浏览器总是并行加载资源，例如，当 HTML 解析器（HTML Parser）被脚本阻塞时，解析器虽然会停止构建 DOM，但仍会识别该脚本后面的资源，并进行预加载。
同时，由于下面两点：
存在阻塞的 CSS 资源时，浏览器会延迟 JavaScript 的执行和 DOM 构建。另外：
所以，script 标签的位置很重要。实际使用时，可以遵循下面两个原则：
下面来看看 CSS 与 JavaScript 是具体如何阻塞资源的。
<style>
p { color: red; }
</style>
<link rel="stylesheet" href="index.css">这样的 link 标签（无论是否 inline）会被视为阻塞渲染的资源，浏览器会优先处理这些 CSS 资源，直至 CSSOM 构建完毕。
渲染树（Render-Tree）的关键渲染路径中，要求同时具有 DOM 和 CSSOM，之后才会构建渲染树。即，HTML 和 CSS 都是阻塞渲染的资源。HTML 显然是必需的，因为包括我们希望显示的文本在内的内容，都在 DOM 中存放，那么可以从 CSS 上想办法。
最容易想到的当然是精简 CSS 并尽快提供它。除此之外，还可以用媒体类型（media type）和媒体查询（media query）来解除对渲染的阻塞。
<link href="index.css" rel="stylesheet">
<link href="print.css" rel="stylesheet" media="print">
<link href="other.css" rel="stylesheet" media="(min-width: 30em) and (orientation: landscape)">第一个资源会加载并阻塞。第二个资源设置了媒体类型，会加载但不会阻塞，print 声明只在打印网页时使用。第三个资源提供了媒体查询，会在符合条件时阻塞渲染。
关于CSS加载的阻塞情况：
没有js的理想情况下，html与css会并行解析，分别生成DOM与CSSOM，然后合并成Render Tree，进入Rendering Pipeline；但如果有js，css加载会阻塞后面js语句的执行，而（同步）js脚本执行会阻塞其后的DOM解析（所以通常会把css放在头部，js放在body尾）
JavaScript 的情况比 CSS 要更复杂一些。如果没有 defer 或 async，浏览器会立即加载并执行指定的脚本，“立即”指的是在渲染该 script 标签之下的HTML元素之前，也就是说不等待后续载入的HTML元素，读到就加载并执行。观察下面的代码：
<p>Do not go gentle into that good night,</p>
<script>console.log("inline1")</script>
<p>Old age should burn and rave at close of day;</p>
<script src="app.js"></script>
<p>Rage, rage against the dying of the light.</p>
<script src="app.js"></script>
<p>Old age should burn and rave at close of day;</p>
<script>console.log("inline2")</script>
<p>Rage, rage against the dying of the light.</p>这里的 script 标签会阻塞 HTML 解析，无论是不是 inline-script。上面的 P 标签会从上到下解析，这个过程会被两段 JavaScript 分别打断一次（加载、执行）。
解析过程中无论遇到的JavaScript是内联还是外链，只要浏览器遇到 script 标记，唤醒 JavaScript解析器，就会进行暂停 (blocked )浏览器解析HTML，并等到 CSSOM 构建完毕，才去执行js脚本。因为脚本中可能会操作DOM元素，而如果在加载执行脚本的时候DOM元素并没有被解析，脚本就会因为DOM元素没有生成取不到响应元素，所以实际工程中，我们常常将资源放到文档底部。
defer 与 async 可以改变之前的那些阻塞情形，这两个属性都会使 script 异步加载，然而执行的时机是不一样的。注意 async 与 defer 属性对于 inline-script 都是无效的，所以下面这个示例中三个 script 标签的代码会从上到下依次执行。
<script async>
console.log("1")
</script>
<script defer>
console.log("2")
</script>
<script>
console.log("3")
</script>上面脚本会按需输出 1 2 3，故，下面两节讨论的内容都是针对设置了 src 属性的 script 标签。
先放个熟悉的图~
蓝色线代表网络读取，红色线代表执行时间，这俩都是针对脚本的；绿色线代表 HTML 解析。
<script src="app1.js" defer></script>
<script src="app2.js" defer></script>
<script src="app3.js" defer></script>defer 属性表示延迟执行引入 JavaScript，即 JavaScript 加载时 HTML 并未停止解析，这两个过程是并行的。整个 document 解析完毕且 defer-script 也加载完成之后（这两件事情的顺序无关），会执行所有由 defer-script 加载的 JavaScript 代码，再触发 DOMContentLoaded(初始的 HTML 文档被完全加载和解析完成之后触发，无需等待样式表图像和子框架的完成加载) 事件 。
defer 不会改变 script 中代码的执行顺序，示例代码会按照 1、2、3 的顺序执行。所以，defer 与相比普通 script，有两点区别：载入 JavaScript 文件时不阻塞 HTML 的解析，执行阶段被放到 HTML 标签解析完成之后。
async 属性表示异步执行引入的 JavaScript，与 defer 的区别在于，如果已经加载好，就会开始执行，无论此刻是 HTML 解析阶段还是 DOMContentLoaded 触发(HTML解析完成事件)之后。需要注意的是，这种方式加载的 JavaScript 依然会阻塞 load 事件。换句话说，async-script 可能在 DOMContentLoaded 触发之前或之后执行，但一定在 load 触发之前执行。
从上一段也能推出，多个 async-script 的执行顺序是不确定的，谁先加载完谁执行。值得注意的是，向 document 动态添加 script 标签时，async 属性默认是 true。
使用 document.createElement 创建的 script 默认是异步的，示例如下。
console.log(document.createElement("script").async); // true所以，通过动态添加 script 标签引入 JavaScript 文件默认是不会阻塞页面的。如果想同步执行，需要将 async 属性人为设置为 false。
如果使用 document.createElement 创建 link 标签会怎样呢？
const style = document.createElement("link");
style.rel = "stylesheet";
style.href = "index.css";
document.head.appendChild(style); // 阻塞？其实这只能通过试验确定，已知的是，Chrome 中已经不会阻塞渲染，Firefox、IE 在以前是阻塞的，现在会怎样目前不太清楚。
结合渲染流程，可以针对性的优化渲染性能：
这里主要参考Google的浏览器渲染性能的基础讲座，想看更详细内容可以去瞅瞅~
setTimeout(callback)和setInterval(callback)无法保证callback函数的执行时机，很可能在帧结束的时候执行，从而导致丢帧，如下图：
requestAnimationFrame(callback)可以保证callback函数在每帧动画开始的时候执行。注意：jQuery3.0.0以前版本的animate函数就是用setTimeout来实现动画，可以通过jquery-requestAnimationFrame这个补丁来用requestAnimationFrame替代setTimeout
JS代码运行在浏览器的主线程上，与此同时，浏览器的主线程还负责样式计算、布局、绘制的工作，如果JavaScript代码运行时间过长，就会阻塞其他渲染工作，很可能会导致丢帧。前面提到每帧的渲染应该在16ms内完成，但在动画过程中，由于已经被占用了不少时间，所以JavaScript代码运行耗时应该控制在3-4毫秒。如果真的有特别耗时且不操作DOM元素的纯计算工作，可以考虑放到Web Workers中执行。
var dataSortWorker = new Worker("sort-worker.js");
dataSortWorker.postMesssage(dataToSort);
// 主线程不受Web Workers线程干扰
dataSortWorker.addEventListener('message', function(evt) {
var sortedData = e.data;
// Web Workers线程执行结束 // ...});由于Web Workers不能操作DOM元素的限制，所以只能做一些纯计算的工作，对于很多需要操作DOM元素的逻辑，可以考虑分步处理，把任务分为若干个小任务，每个任务都放到 requestAnimationFrame中回调执行
var taskList = breakBigTaskIntoMicroTasks(monsterTaskList);
requestAnimationFrame(processTaskList);
function processTaskList(taskStartTime) {
var nextTask = taskList.pop();
// 执行小任务
processTask(nextTask);
if (taskList.length > 0) {
requestAnimationFrame(processTaskList);
}
}打开 ChromeDevTools>Timeline>JSProfile，录制一次动作，然后分析得到的细节信息，从而发现问题并修复问题。
添加或移除一个DOM元素、修改元素属性和样式类、应用动画效果等操作，都会引起DOM结构的改变，从而导致浏览器要repaint或者reflow。那么这里可以采取一些措施。
尽量保持class的简短，或者使用Web Components框架。
.box:nth-last-child(-n+1) .title {}
// 改善后
.final-box-title {}由于浏览器的优化，现代浏览器的样式计算直接对目标元素执行，而不是对整个页面执行，所以我们应该尽可能减少需要执行样式计算的元素的个数。
布局就是计算DOM元素的大小和位置的过程，如果你的页面中包含很多元素，那么计算这些元素的位置将耗费很长时间。布局的主要消耗在于：1. 需要布局的DOM元素的数量；2. 布局过程的复杂程度
当你修改了元素的属性之后，浏览器将会检查为了使这个修改生效是否需要重新计算布局以及更新渲染树，对于DOM元素的几何属性修改，比如width/height/left/top等，都需要重新计算布局。对于不能避免的布局，可以使用Chrome DevTools工具的Timeline查看布局的耗时，以及受影响的DOM元素数量。
老的布局模型以相对/绝对/浮动的方式将元素定位到屏幕上，而Floxbox布局模型用流式布局的方式将元素定位到屏幕上。通过一个小实验可以看出两种布局模型的性能差距，同样对1300个元素布局，浮动布局耗时14.3ms，Flexbox布局耗时3.5ms。IE10+支持。
根据渲染流程，JS脚本是在layout之前执行，但是我们可以强制浏览器在执行JS脚本之前先执行布局过程，这就是所谓的强制同步布局。
requestAnimationFrame(logBoxHeight);
// 先写后读，触发强制布局
function logBoxHeight() {
// 更新box样式
box.classList.add('super-big');
// 为了返回box的offersetHeight值
// 浏览器必须先应用属性修改，接着执行布局过程
console.log(box.offsetHeight);
}
// 先读后写，避免强制布局
function logBoxHeight() {
// 获取box.offsetHeight
console.log(box.offsetHeight);
// 更新box样式
box.classList.add('super-big');
}在JS脚本运行的时候，它能获取到的元素样式属性值都是上一帧画面的，都是旧的值。因此，如果你在当前帧获取属性之前又对元素节点有改动，那就会导致浏览器必须先应用属性修改，结果执行布局过程，最后再执行JS逻辑。
如果连续快速的多次触发强制同步布局，那么结果更糟糕。比如下面的例子，获取box的属性，设置到paragraphs上，由于每次设置paragraphs都会触发样式计算和布局过程，而下一次获取box的属性必须等到上一步设置结束之后才能触发。
function resizeWidth() { // 会让浏览器陷入'读写读写'循环 for (var i = 0; i < paragraphs.length; i++) { paragraphs[i].style.width = box.offsetWidth + 'px'; }}
// 改善后方案var width = box.offsetWidth;function resizeWidth() { for (var i = 0; i < paragraphs.length; i++) { paragraphs[i].style.width = width + 'px'; }}注意：可以使用FastDOM来确保读写操作的安全，从而帮你自动完成读写操作的批处理，还能避免意外地触发强制同步布局或快速连续布局，消除大量操作DOM的时候的布局抖动。
Paint就是填充像素的过程，通常这个过程是整个渲染流程中耗时最长的一环，因此也是最需要避免发生的一环。如果Layout被触发，那么接下来元素的Paint一定会被触发。当然纯粹改变元素的非几何属性，也可能会触发Paint，比如背景、文字颜色、阴影效果等。
绘制并非总是在内存中的单层画面里完成的，实际上，浏览器在必要时会将一帧画面绘制成多层画面，然后将这若干层画面合并成一张图片显示到屏幕上。这种绘制方式的好处是，使用transform来实现移动效果的元素将会被正常绘制，同时不会触发其他元素的绘制。
浏览器会把相邻区域的渲染任务合并在一起进行，所以需要对动画效果进行精密设计，以保证各自的绘制区域不会有太多重叠。另外可以实现同样效果的不同方式，应该采用性能更好的那种。
打开DevTools，在弹出的面板中，选中 MoreTools>Rendering选项卡下的Paint flashing，这样每当页面发生绘制的时候，屏幕就会闪现绿色的方框。通过该工具可以检查Paint发生的区域和时机是不是可以被优化。通过Chrome DevTools中的 Timeline>Paint选项可以查看更细节的Paint信息
使用transform/opacity实现动画效果，会跳过渲染流程的布局和绘制环节，只做渲染层的合并。
TypeFuncPositiontransform: translate(-px,-px)Scaletransform: scale(-)Rotationtransform: rotate(-deg)Skewtransform: skew(X/Y)(-deg)Matrixtransform: matrix(3d)(..)Opacityopacity: 0-1
使用transform/opacity的元素必须独占一个渲染层，所以必须提升该元素到单独的渲染层。
应用动画效果的元素应该被提升到其自有的渲染层，但不要滥用。在页面中创建一个新的渲染层最好的方式就是使用CSS属性will-change，对于目前还不支持will-change属性、但支持创建渲染层的浏览器，可以通过3D transform属性来强制浏览器创建一个新的渲染层。需要注意的是，不要创建过多的渲染层，这意味着新的内存分配和更复杂的层管理。注意，IE11，Edge17都不支持这一属性。
.moving-element { will-change: transform; transform: translateZ(0);}尽管提升渲染层看起来很诱人，但不能滥用，因为更多的渲染层意味着更多的额外的内存和管理资源，所以当且仅当需要的时候才为元素创建渲染层。
* { will-change: transform; transform: translateZ(0);}开启 Timeline>Paint选项，然后录制一段时间的操作，选择单独的帧，看到每个帧的渲染细节，在ESC弹出框有个Layers选项，可以看到渲染层的细节，有多少渲染层，为何被创建？
用户输入事件处理函数会在运行时阻塞帧的渲染，并且会导致额外的布局发生。
理想情况下，当用户和页面交互，页面的渲染层合并线程将接收到这个事件并移动元素。这个响应过程是不需要主线程参与，不会导致JavaScript、布局和绘制过程发生。但是如果被触摸的元素绑定了输入事件处理函数，比如touchstart/touchmove/touchend，那么渲染层合并线程必须等待这些被绑定的处理函数执行完毕才能执行，也就是用户的滚动页面操作被阻塞了，表现出的行为就是滚动出现延迟或者卡顿。
简而言之就是你必须确保用户输入事件绑定的任何处理函数都能够快速的执行完毕，以便腾出时间来让渲染层合并线程完成他的工作。
输入事件处理函数，比如scroll/touch事件的处理，都会在requestAnimationFrame之前被调用执行。因此，如果你在上述输入事件的处理函数中做了修改样式属性的操作，那么这些操作就会被浏览器暂存起来，然后在调用requestAnimationFrame的时候，如果你在一开始就做了读取样式属性的操作，那么将会触发浏览器的强制同步布局操作。
通过requestAnimationFrame可以对样式修改操作去抖动，同时也可以使你的事件处理函数变得更轻
家好，很高兴又见面了，我是"高级前端进阶"，由我带着大家一起关注前端前沿、深入前端底层技术，大家一起进步，也欢迎大家关注、点赞、收藏、转发！
Free JavaScript form builder library with integration for React, Angular, Vue, jQuery, and Knockout.
SurveyJS 表单库是一个免费的 MIT 许可客户端组件，允许开发者在任何 JavaScript 应用程序中渲染基于 JSON 的动态表单、收集响应并将所有表单数据提交到目标数据库。
开发者可以将 SurveyJS 用于任意长度和复杂程度的多页表单、弹出式调查、测验、计分调查、计算器表单等。SurveyJS 表单库对 React、Angular、Vue 和 Knockout 等框架都具有原生支持，jQuery 通过 Knockout 版本的包装器也能获得支持。
SurveyJS 产品系列还包括一个强大的表单构建器库，可自动生成 JSON 格式的表单配置文件。表单构建器具有拖放式 UI、CSS 主题编辑器和用于条件逻辑和表单分支的 GUI。
目前 SurveyJS 在 Github 通过 MIT 协议开源，有超过 4k 的 star、1k 的 fork、代码贡献者 150+、妥妥的前端优质开源项目。
SurveyJS Form Library for React 由两个 npm 包组成：survey-core（独立于平台的代码）和 survey-react-ui（渲染代码）。首先需要运行以下命令安装 survey-react-ui，survey-core 包将作为依赖项自动安装。
npm install survey-react-ui --saveSurveyJS 表单库附带了几个预定义主题（如下所示）以及基于 CSS 变量的灵活主题自定义机制。
import 'survey-core/defaultV2.min.css';接着需要指定模型，以下模型架构声明了两个文本问题，每个问题都有一个标题和一个名称。标题显示在屏幕上，名称用于在代码中识别问题。
const surveyJson = {
elements: [{
name: "FirstName",
title: "Enter your first name:",
type: "text"
}, {
name: "LastName",
title: "Enter your last name:",
type: "text"
}]
};接着可以导入 Survey 组件并渲染表单，将其添加到模板中：
// Uncomment the following line if you are using Next.js:
// 'use client'
import {Survey} from 'survey-react-ui';
// ...
const surveyJson = {...};
function App() {
const survey = new Model(surveyJson);
return <Survey model={survey} />;
}SurveyJS 与其他框架，比如：Angular、Vue 、 Knockout、jQuery 等的集成也非常简单，这里不再赘述，可以参考文末资料。
https://github.com/surveyjs/survey-library
https://surveyjs.io/form-library/documentation/get-started-react
https://surveyjs.io/documentation/surveyjs-architecture
*请认真填写需求信息，我们会在24小时内与您取得联系。
