AI 摘要：作者以一种反思式的语气询问开发者——我们为什么要在浏览器里使用 React？文章从技术惯性、前后端职责演变、开发者文化到框架优先级等多个角度分析 React 的盛行原因与隐形代价。作者最终的立场是：在服务端使用 React 无可厚非，但在客户端运行 React 则可能损害用户体验。若仅因文化或团队习惯而加载庞大的 React 库，不如考虑 Preact、Astro 或直接用原生 JavaScript（vanilla JS），以提升性能和用户友好度。

1. 选择 React 的现象与动机
• 多数开发者使用 React 并非出于设计或性能考虑，而是出于团队惯性或工作要求。
• 作者将“被强制使用的技术”定义为企业级软件（enterprise software）。
• 惯性（Inertia）被认为是 React 持续流行的首要原因。

2. 前端与后端的边界变化
• 过去前端与后端有清晰分工，如 HTML、CSS、JavaScript 属于前端，PHP、Ruby、Python 属于后端。
• 随着 JavaScript 可在服务器端执行，开发者常忽视客户端代码的性能代价。
• 客户端执行环境有限，文件体积和加载时间至关重要，而服务端则可通过硬件“买掉”性能瓶颈。

3. React 开发者文化与生态迁移
• React 从最初强调虚拟 DOM 到后来因组件化架构与 JSX 被开发者喜爱。
• React 不再只是前端库，而是类似 Rails、Django 的全栈式生态。
• 这种文化层面的认同让开发者倾向于“全用 React”，即便这并不总是对用户友好。

4. 框架优先级与替代方案
• Next.js 推行服务端渲染（SSR），但仍倾向输出同样的客户端 React 代码，造成资源浪费。
• Astro 框架提出“最小化客户端 JavaScript”的思路，保留 JSX 作者体验但减轻用户负担。
• React/Next/Vercel 生态的惯性使这种思路被边缘化，但 Astro 展示了另一种可能。

5. 回归问题：为什么在浏览器使用 React？
• 若使用 React 只是团队协作或文化原因，可仅在服务端保留 React。
• 前端若非单页应用（SPA），应尽量减少 JavaScript 框架负担。
• 若确需前端状态管理，可考虑 Preact 或探索原生 JavaScript 的能力。
• 作者倡导：让框架留在服务器，充分利用浏览器本身的强大功能。

AI 摘要：本文由 Rachel 撰写，灵感来自 TechBash 会议中 Mike Rapa 的讲座，介绍了 6 个鲜为人知的 Chrome DevTools 技巧。本篇是 Part 1，涵盖前三个内容：用 console.time() 和 console.timeEnd() 精准计时函数执行、利用 DOM Breakpoints 实时捕捉元素变化，并自动暂停脚本运行、以及用 monitor() 在控制台监听任意函数调用。

1. 文章背景与启发来源
• 作者参加 TechBash 会议，受到 Mike Rapa 的 DevTools 演讲启发。
• 本文专注于 Chrome DevTools 的 3 个隐藏功能，Firefox 部分功能支持略有不同。
• 计划分上下两篇，本篇为 Part 1，介绍前三个功能。

2. 计时函数性能监控
• 介绍 console.time() 与 console.timeEnd() 的使用，可精确测量代码块执行耗时。
• 提及 console.timeLog() 用于中间打印时间进度。
• 举例说明结合 React Hook 使用场景，展示暂停与超时逻辑的时间追踪方案。
• 来源：Mike Rapa 的演讲及 Github 仓库。
• 支持情况：原生 JS 特性，各浏览器均可使用。

3. 通过 DOM Breakpoints 检测元素变化
• 介绍如何在 Chrome Elements 面板中为任何 DOM 元素设置 "Break on" 断点。
• 当该元素属性、子树或节点被修改时，自动暂停脚本执行。
• 可快速定位导致页面 UI 异常的脚本。
• 提供 Stack Overflow 示例，展示实际操作方法。
• 支持情况：主流浏览器支持，Firefox 行为略有差异。

4. 使用 monitor() 监听任意函数调用
• 在控制台中可用 monitor(functionName) 监控任意函数调用及其参数。
• 帮助调试第三方脚本或不易插入 console.log() 的代码。
• 示例：sum(1,2) 会在控制台输出调用信息。
• 来源：Google DevTools Utilities 文档。
• 支持情况：仅支持 Chrome。

5. 预告与后续主题
• 作者计划在 Part 2 中讨论剩余三项：可视化编辑网页（WYSIWYG）、记录与重放用户操作、按需限速网络请求。
• 鼓励读者关注后续更新、尝试在实际项目中运用这些技巧。

AI 摘要：本文介绍了如何通过 CSS 3D transform 与 “layered pattern（分层模式）” 创建栩栩如生的 3D 图片效果。作者从 HTML 结构设计、CSS 3D 场景设置、层间位移计算、亮度与饱和度调节到交互控制面板（含 JavaScript）完整展示了创建流程。文章强调了分层视觉的本质是在二维平面中利用透视与光影制造立体幻觉，并通过 perspective、translateZ()、filter 等技巧实现动态的 3D 效果。

1. 3D CSS 概念与分层模式简介
• 概述 CSS 3D 的发展历史，从 2009 年起被 W3C 规范化
• “layered pattern（分层模式）”通过多个图层叠加制造立体幻觉
• 提示需理解 CSS perspective 与坐标系 (x, y, z) 概念

2. HTML 结构设计
• 使用 <div class="scene"> 包裹整个 3D 场景
• 建立多层重复图像 (.layer) 并以自定义属性 --i 标识层级
• 通过 aria-hidden="true" 处理无障碍可访问性问题
• 提及未来可通过 sibling-index() 和 sibling-count() 优化层索引

3. CSS 构建 3D 场景
• 设置 .scene { perspective: 1000px } 以控制深度
• 启用 transform-style: preserve-3d 让所有层在三维空间可见
• 通过 --layers-count 和 --layer-offset 控制层数与间距
• 利用 translateZ(calc(var(--i) * var(--layer-offset))) 实现纵深位移
• 计算标准化变量 --n 以动态调节亮度与饱和度实现光影变化
• 使用 filter: brightness() 与 filter: saturate() 增强立体层次
• 布局上将 .layer 与 .layers 设为 position: absolute; inset: 0 覆盖叠加

4. 动画与交互控制
• 通过 @keyframes rotate3d 添加旋转动画模拟立体旋转
• 创建交互控件（input range 滑块与按钮）控制 perspective、层间距与旋转角度
• 使用 JavaScript 监听输入事件动态更新 CSS 自定义属性与图像内容
• 示例函数 updateRotation() 绑定 X/Y 旋转值，支持图片更换

5. 附加功能与扩展
• 控制面板提供图像切换与参数调节体验
• JS 实现与视觉绑定，删除原有动画以改为实时控制
• 结尾展示延伸案例 “3D CSS steak”，说明同一技术可应用于更复杂视觉模型

6. 小结与启示
• 3D CSS 的核心在于“二维模拟三维”的视觉幻象
• 有效结合 transform、perspective 与 filter 可获得高性能的 3D 效果
• 分层模式可扩展用于文字、图片、UI 元素等多种设计

AI 摘要：本文介绍了在 JavaScript (ES2022) 中引入的 Error.cause 属性，展示它如何让错误处理更具可追溯性。作者 Matt Smith 通过实例说明了传统错误包裹的缺陷，以及 Error.cause 在保持原始堆栈信息、改进调试体验和测试断言方面的优势。最终总结出一套现代错误链最佳实践，帮助开发者构建更清晰、更稳健的错误追踪体系。

1. 传统错误处理的问题
• 层层调用的代码容易丢失原始错误信息；
• 以字符串拼接错误信息会破坏堆栈和错误类型；
• 导致调试困难，追踪难度高。

2. 引入 Error.cause 的改进
• 通过 new Error(message, { cause }) 保留原始错误；
• 可同时访问顶层与底层堆栈信息；
• cause 属性为非枚举属性，不污染日志或循环输出；
• 与 message、stack 一样保持一致的行为。

3. 实践与代码演示
• 示例：从 JSON.parse 到自定义函数的错误传递；
• 在日志中手动输出 err.cause 获取完整上下文；
• 适合层次式系统（如服务嵌套调用）排查问题。

4. 历史背景与 cause 出现前的替代方案
• 旧方案包括自定义字段 .originalError、字符串拼接等；
• 这些方式不统一且容易破坏原始错误结构；
• 标准化的 cause 提供更安全一致的机制。

5. 自定义错误类的支持
• 在自定义类中通过 super(message, { cause }) 传递原因；
• 适用 ES2022+ 环境即可直接使用；
• 对 TypeScript 用户，需在 tsconfig.json 中启用 "target": "es2022" 与 "lib": ["es2022"]。

6. 在测试中的应用
• 测试断言可直接验证 err.cause 类型；
• 提升测试可读性与准确性。

7. 实用技巧与注意事项
• 浏览器默认不输出层级错误链，须手动打印；
• 不建议过度使用错误链，避免干扰阅读；
• 可递归打印完整错误链（logErrorChain 与 logFullErrorChain 示例）；
• 实践场景：数据库异常→业务异常→服务异常的多层错误追踪。

8. 环境支持与现代用法总结
• 支持于现代浏览器与运行环境（Chrome 93+、Node.js 16.9+、Deno、Bun 等）；
• 推荐实践：
• ✅ 使用 Error(message, { cause })
• ✅ 支持内建与自定义错误类型
• ✅ 改善日志和调试体验
• ✅ 对 TypeScript 进行正确配置
• ⚠️ 记得手动输出或递归追踪错误链。

AI 摘要：本文系统解析了 JavaScript 中 Source Map 的内部机制，从 TypeScript 构建流水线到 Source Map 的 JSON 结构与 Base64 VLQ 编码，作者逐步展示了浏览器如何通过这些映射信息，将压缩后的生产代码还原回开发者可读的源文件位置。

1. 引言：Source Map 的作用
• 解释 Source Map 如何连接构建后的 “生产代码” 与原始源文件
• 举例说明浏览器在 DevTools 中如何利用 Source Map 还原源码位置

2. TypeScript 构建管线（Build Pipeline）
• 概述现代 JavaScript 构建的三个阶段：转译 (Transpilation)、打包 (Bundling)、压缩 (Minification)
• 展示原始 TypeScript 源文件示例（add.ts / fibonacci.ts / main.ts）
• 强调每个阶段 Source Map 保持了源代码映射关系

3. Source Map 文件结构
• Source Map 为 JSON 格式，通常以 .js.map 结尾
• 字段详解：
• version：版本号（通常为 3）
• file：对应的生成后文件名
• sourceRoot：源文件路径前缀
• sources / sourcesContent：原始文件路径和内容
• names：标识符数组（变量与函数名）
• mappings：压缩映射字符串（核心内容）
• 指出 mappings 字段使用 VLQ 编码进行空间压缩

4. 理解映射机制：VLQ 编码 (Variable Length Quantity)
• mappings 字符串由逗号与分号组成，分号分行、逗号分列表示段（segment）
• 三种 segment 格式：
• 单值：仅表示生成列位置
• 四值：完整的源映射
• 五值：包含原始名称索引（变量或函数重命名时使用）
• 说明相对位置编码（delta encoding）原理——通过存储偏移量而非绝对位置实现高压缩率

5. VLQ 编码的工作原理
• 每个数字通过以下步骤编码为 Base64：
1. 编码符号位（sign bit）区分正负数
2. 拆分成 5 位数据块+1 位延续标志 (continuation bit)
3. 使用 Base64 字符表映射（A–Z, a–z, 0–9, +, /）
• 举例说明数字 7 如何被编码为 “O”
• 总结其节省空间与高效解析的优点

6. 实例解读与调试意义
• 通过 add.js.map 的 decode 过程展示行列映射
• 演示如何由压缩代码精确反查到原始 TS 源文件行列
• 强调 Source Map 在前端调试、错误定位和代码回溯中的核心地位

Do more with less. | Polar Signals

The Inner Workings of JavaScript Source Maps

A deep dive into how JavaScript source maps work under the hood, with examples showing how all the pieces fit together.

AI 摘要：作者以在写书时想展示一个简单的 Elm 与 JavaScript 交互的例子为起点，却发现实现“复制文本到剪贴板”这一任务远比想象复杂。从浏览器支持、权限、各版本 Safari 到移动端兼容问题，现代 Clipboard API 充满意外。由此引出反思：Web 平台为兼容历史与安全性付出的代价是越来越厚重的复杂层。最终，作者选择一个可用的示例，提醒开发者：有时候要接受现实的混沌与妥协。

1. 起因与动机
• 作者在写一本面向 React 开发者的 Elm 书，想找一个简洁、通用的浏览器 API 示例。
• 选择了实现一个“复制到剪贴板”的小功能，却意外发现这是 Web 平台的一个“大坑”。

2. 寻找方案与初步尝试
• 作者在 npm 搜索时，发现竟有上千个剪贴板相关包。
• 表面上使用 navigator.clipboard.writeText() 非常简单，但实际上问题重重。

3. 现实中的各种问题
• 浏览器支持：仅在安全上下文（HTTPS/localhost）可用，HTTP 环境失效。
• 权限机制：不同浏览器策略不一，有的需用户交互，有的静默失败。
• Safari 特例：行为不可预测，有时 API 存在但无效。
• 传统方案重新上场：通过隐藏的 <textarea> 加 document.execCommand('copy') 方法，虽然过时，却更稳定。
• 移动端挑战：iOS、Android 各有怪癖，需在真实设备上测试。

4. 为什么有 1000+ npm 包
• 每个包都是在调和这些兼容性问题的尝试。
• 从 polyfill、fallback，到各框架（React/Vue）的封装，最终形成生态的“碎片化复杂性”。

5. 深层反思：复杂性在何处
• Web 平台无法移除旧 API，只能持续叠加新接口。
• 浏览器行为微妙差异导致“只想复制文本”都需多层抽象。
• 开发者的“临时解决方案”又进一步催生新复杂。

6. 结语：接受不完美
• 作者在书中只展示了一个工作的例子，并指出“这事复杂，但这不是重点”。
• Elm 通过 port（端口）层与 JavaScript 保持距离，体现了设计上对混乱生态的隔离思路。
• 对开发者而言，重要的不只是解决问题，而是理解复杂系统背后的现实与妥协。

cekrem.github.io

The Clipboard API: How Did We Get Here?

Or: why there are 1000+ npm packages for copying text to clipboard

AI 摘要：本文由 Tanner Linsley 撰写，分析了当代 JavaScript 框架中兴起的 “use server”、“use client” 等自定义指令 (Directive) 趋势。这些指令表面上像平台特性，却缺乏标准规范，模糊了语言与框架的界线，引发生态混乱、工具负担与可移植性风险。作者主张：指令应保持极少且标准化，用于语言层；而具参数化、策略性或扩展需求的功能应采用显式 API（具来源 import、可组合与可版本化），以维持平台边界清晰和生态长远健康。

Tanstack

Directives and the Platform Boundary | TanStack Blog

A Quiet Trend in the JavaScript Ecosystem For years, JavaScript has had exactly one meaningful directive, "use strict". It is standardized, enforced by runtimes, and behaves the same in every environm...

AI 摘要：本文系统地讲解了如何在网站中使用 View Transition API，通过 CSS 与 JavaScript 结合实现页面或内容间的动画过渡，从基础语法、调试技巧、命名规范、类型区分到最佳实践完整覆盖。作者强调利用伪元素与动画组结构可极大简化复杂转场开发，提出在 prefers-reduced-motion 设置下应合理退化，同时介绍跨页面转场与未来 CSS 原生增强的前景。

1. View Transition API 基础
• View Transition API 允许在状态切换间实现平滑动画，方式包括自动触发或通过 JavaScript 手动调用。
• 浏览器在启动转场时会创建当前和未来状态的快照进行对比并生成关键帧动画，机制类似 FLIP 技术但由 CSS 自动处理。
• 若未改动浏览器原生导航，可简单通过 @view-transition { navigation: auto; } 启用。

2. View Transition 结构与伪元素 (pseudo elements)
• 介绍转场的 DOM 架构：::view-transition-group、::view-transition-image-pair、::view-transition-old、::view-transition-new。
• 每个转场组独立包含前后状态快照，开发者可用 view-transition-name 命名控制。
• 快照为非交互式静态影像，转场中无法修改其内容或动态更新样式。

3. 调试与命名
• Chrome DevTools 的动画面板 (Animations Drawer) 可用于调试、调整动画速度与暂停查看。
• 推荐为每个转场元素添加独立的 view-transition-name，跨页面动画需在两页手动匹配命名。
• 使用 match-element 可支持同文档内转场。

4. View Transition 类型与事件
• 通过 JavaScript 可在 document.startViewTransition() 调用时传入 types 参数，区分不同交互的转场类型。
• 可结合 :active-view-transition-type(filter) 伪类为特定类型设置动画样式。
• 使用 pagereveal 事件判断页面跳转方向与来源，实现更复杂的跨页面转场逻辑。
• 当前部分旧版 Chrome 不支持类型参数，可通过 try-catch 或自定义 data 属性兼容处理。

5. 最佳实践与组织结构
• 应为所有 view-transition-name 设置一致的动画时长、缓动函数（animation-timing-function）与填充模式（fill-mode）。
• 建议用短变量如 --vt 生成唯一 ID，在使用 CMS 或框架时可轻量生成名称。
• 使用 prefers-reduced-motion: no-preference 媒体查询，以保证可访问性良好的退化行为。
• 可通过选择器 [style*="--vt"] 一次性添加全部转场名称。

6. 高阶应用与动画逻辑
• 转场组中可能只存在 old/new 状态，用于筛选（filter）或排序（sort）操作表现不同。
• 使用 CSS 伪类 :only-child 区分仅有 old/new 状态的元素，实现“进入”或“退出”动画。
• 案例包括从总览页到详情页的转场动画。
• 当前 :has 尚无法检查组内是否同时存在 old/new 元素，此功能已在 W3C 提案中。

7. 浏览器兼容性与后续发展
• Firefox 144 已支持 View Transition API，但仅限同文档转场。
• 跨文档转场（cross-document transitions）正在推进，可跟踪 MDN 与 Chrome 团队 Demo 获取更新。

Piccalilli

Start implementing view transitions on your websites today

Browser support for view transitions is rocketing and there's not many better out there to help you understand how to implement them than Cyd Stumpel.

AI 摘要：介绍了已进入 Baseline 的新浏览器功能 URLPattern API，它为 URL 匹配和路由提供了标准、简洁且高性能的原生解决方案。过去开发者需使用复杂的正则表达式或第三方库来解析和提取 URL 参数，而 URLPattern 使得这些操作更清晰、可维护且无需额外依赖。

1. URLPattern 基础与核心概念
• 介绍 URLPattern API 的推出背景：取代传统正则匹配与第三方路由库。
• 提供新 URLPattern 接口，可通过 .test() 与 .exec() 操作直接匹配并提取参数。

2. 基本 URL 模式匹配
• 对比旧方法（URL + 正则）与新 API 的简化写法。
• 展示匹配 /users/:id 的例子，体现代码可读性和简洁性。

3. 提取动态参数（Dynamic Parameters）
• 传统方法依赖匿名的正则捕获组，易出错。
• URLPattern 支持命名参数，可通过结构化对象获取（如 result.pathname.groups）。
• 示例：提取书籍分类 category 与 id。

4. 复合匹配（Compose Multipart Matches）
• 传统方式需多处判断主机名与路径。
• URLPattern 原生支持同时匹配多个部分，例如 hostname + pathname。
• 示例：匹配 .cdn.com 下的 /images/ 文件。

5. 减少项目依赖（Project Dependencies）
• URLPattern 是内置能力，无需加载第三方库，减少 bundle 体积与维护成本。
• 使用浏览器原生实现，跨引擎一致且性能更优。

6. 深度用法详解（Detailed Usage）
• 多种典型场景：
• 路径匹配与参数提取：示例 /products/:category/:id 展示 .test() 与 .exec() 双用法。
• 匹配子域名与版本号：支持在 hostname 层定义变量如 :subdomain.myapp.com，适用于多子域架构。
• 通配符与正则表达式结合：通过 * 和嵌入式正则增强匹配灵活度，如 /users/:userId(d+)/assets/*.(jpg|png|gif)。

7. 实战示例：Service Worker 路由
• 利用 URLPattern 拦截 fetch 事件，根据路径实行不同缓存策略。
• 示例：
• /images/* 采用缓存优先；
• /api/* 使用网络优先。
• 显示该 API 在渐进式 Web 应用（PWA）中的现实意义。

8. 结语与扩展阅读
• URLPattern 提升代码可维护性，简化路由逻辑。
• 推荐进一步查阅 MDN Web Docs 了解完整参考。

web.dev

URLPattern is now Baseline Newly available  |  Blog  |  web.dev

URLPattern became Baseline Newly available as of September 15, 2025.

AI 摘要：本文系统回顾了 typeof null === "object" 的历史与技术背景，从现代 JavaScript 引擎的内存标记机制 (pointer tagging) 到最初的 Netscape 实现原理，解释了这一“bug”如何产生并延续至今。作者复原了早期 C 语言实现及源码宏定义，揭示 null 被识别为对象的根本原因是早期 32 位系统的对齐与标记约定。尽管这一问题可轻易修复，但考虑到巨大的兼容性影响，标准委员会选择保留这一行为，使它成为语言历史上的经典遗产。

Piotr Zarycki - Programming Blog

Why typeof null === object

Learn why typeof null returns ‘object’ instead of ’null’ in JavaScript

@DIYgod: 一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差，今天 Cloudflare 回应了篇博客承认错误，解释了造成问题的各种技术细节，现在把性能也追上来了 太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了，现在倒是显得 Vercel 小肚鸡肠了...

AI 摘要：本文由 Cloudflare 首席架构师 Kenton Varda 撰写，针对独立开发者 Theo Browne 公布的基准测试结果展开调查与回应。原测试显示 Cloudflare Workers 在 CPU 密集型 JavaScript 任务中比 Vercel（基于 AWS Lambda）慢至 3.5 倍。Cloudflare 分析后发现，性能差异主要源自调度算法、V8 垃圾回收参数旧配置、OpenNext 框架实现低效及测试方法偏差。经过多项修复与调优，Workers 性能已与 Vercel 持平甚至超越。文中还披露了 Cloudflare 对 V8 与 Node.js 性能改进的贡献，证明其优化不仅服务自家平台，更惠及广泛的 JavaScript 生态。

1. 基准测试背景与问题调查
• 独立开发者 Theo Browne 公布测试，显示 Cloudflare Workers 明显落后 Vercel
• 两者皆基于相同的 V8 引擎，理论上应相近性能
• 性能差异达到 3.5 倍，引发 Cloudflare 团队深入分析
• 指出测试方法主要反映“等待时间”而非“实际 CPU 使用”

2. 平台调度算法与运行时优化
• Workers “warm isolate routing” 策略导致 CPU 密集型请求排队
• 调整调度算法，让系统更快检测并扩展新 isolate，避免阻塞
• 改进后大幅降低延迟波动，提高自动扩展效率

3. V8 (JavaScript 引擎) 垃圾回收 (Garbage Collector, GC) 调优
• 发现旧参数设定限制了“young generation”空间大小
• 放宽 GC 配置让 V8 自调内存区间，性能提升约 25%
• 改进已全球部署，影响所有 Workers

4. 优化 OpenNext 与 Next.js 性能
• 识别大量不必要的内存复制与 Buffer 分配
• 对流式响应 (Streaming) 做性能补丁，减少冗余数据操作
• 提交多个 PR 改进 OpenNext，包括缓存优化、流管道调度、正则重用等
• 针对 JSON.parse reviver 函数的低效执行向 V8 上游提交补丁，提升约 33% 性能

5. Streams 适配与数据传输改进
• Node.js 与 Web Streams API 转换时存在重复缓冲问题
• 改用原生 ReadableStream.from(chunks) 避免多层拷贝
• 调整 ReadableStream highWaterMark，使字节流读取更高效

6. Node.js 三角函数性能修复
• Node.js 未启用 V8 trig 函数快速路径
• Workers 已默认启用，因此跑分更好
• Cloudflare 提交 PR 修复 Node.js 构建配置，使全生态受益

7. 对基准测试方法的反思与改进
• 本地测试中网络延迟影响 CPU 计算评估
• Cloudflare 与 Vercel 所用硬件代际不同，会引入性能噪声
• Next.js 与 React SSR 测试中存在 force-dynamic 与 NODE_ENV 配置错误导致性能偏差
• 建议未来基准采用可控环境与更准确指标（TTLB 而非仅 TTFB）

8. 后续计划与开放协作
• 所有平台级修复已上线，无需用户手动更新
• 将继续优化 OpenNext 与 V8，推动上游框架改进
• Cloudflare 鼓励社区提交性能测试，团队会分析并修复问题
• 长期目标：通过改进开放源代码基础设施提升整个生态性能

FixupX

DIŸgöd ☀️ (@DIYgod)

一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差，今天 Cloudflare 回应了篇博客承认错误，解释了造成问题的各种技术细节，现在把性能也追上来了

太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了，现在倒是显得 Vercel 小肚鸡肠了...

AI 摘要：文章由 Matt Smith 撰写，全面介绍了 ES2024 新引入的 Object.groupBy() 与 Map.groupBy() 两个静态方法，展示它们如何取代繁琐的 reduce() 实现数组分组。文中对两者的区别、使用场景、常见陷阱以及浏览器支持进行了清晰对比，并通过任务列表、日志、商品价格等案例演示了它们的实际应用。文章强调这些新特性提高了代码的表达力与可维护性，使分组操作更加声明式与直观。

AI 摘要：作者通过对常见的 React 状态订阅写法 (useEffect + useState) 进行剖析，指出该模式在服务端渲染 (SSR) 下可能引发抖动 (jank)，并介绍了 useSyncExternalStore 的优势：它提供了更简洁的 API，支持订阅机制和服务端默认值，从而提升 SSR 渲染体验并减少 UI 闪烁。

1. 常见的 useEffect + useState 订阅模式
• 使用 useEffect 在组件挂载时订阅事件源 (event source)。
• 更新 useState 来触发组件重渲染，卸载时清理订阅。
• 常见于绑定 ResizeObserver、DOM 引用、外部事件等场景。

2. 该模式在服务端渲染 (SSR) 下的问题
• 初始渲染使用默认值，SSR 时无法订阅浏览器事件。
• 浏览器接管 (hydration) 后才启动订阅并更新状态。
• 导致界面多次渲染，出现 UI 闪烁、过渡不平滑的现象 (jank)。

3. 使用 useSyncExternalStore 的改进方案
• 提供显式的 subscribe 函数实现监听与取消订阅。
• 第二个参数为获取当前值的方法，确保 UI 与外部状态同步。
• 第三个参数允许定义服务端默认值，提升 SSR 初始化体验。
• 案例对比表明，useSyncExternalStore 渲染更平稳，减少 UI 抖动。

4. 开发实践与思考
• 在涉及外部状态订阅 (API、事件、可观察对象) 场景下，应优先考虑 useSyncExternalStore。
• 默认值的设计影响 SSR 渲染体验，可以通过合理设置来降低不适感。
• 对数据可视化、实时 UI 交互等高频场景尤其重要。

Swizec

You may be looking for a useSyncExternalStore | Swizec Teller

When you see a `useEffect` that updates a `useState` and returns a value, you might be looking for a `useSyncExternalStore`. This is my current vendetta.

AI 摘要：本文介绍了 JavaScript 新增的 findLast() 与 findLastIndex()，它们能高效地从数组末尾开始查找元素，解决传统 .slice().reverse().find() 的性能与可读性问题。文章展示了实际应用场景（如日志查找、消息列表、React 组件状态管理等），并详细说明了使用注意事项、最佳实践和浏览器支持情况。

AI 摘要：本期 React Status 报导了一个与 useEffect 使用不当导致 Cloudflare 仪表盘宕机的案例，提醒开发者谨慎处理副作用；同时探讨了控制 package.json 依赖膨胀的技巧；介绍了 AI 辅助的终端代码审查工具 CodeRabbit CLI；并整理了近期前端生态的更新，包括 React Canary 新特性、pnpm 安全机制、Expo 54 改进、TanStack 工具集更新，以及 JavaScript 社区内围绕 npm 供应链攻击、Safari 26.0 发布和 Bun 1.2.22 发布等动态。

AI 摘要：本文介绍了 Remotion 与 Mediabunny 的合作。Remotion 决定停止自身的 Media Parser 和 WebCodecs 项目，全面支持由 Vanilagy 开发的 Mediabunny，该库具备更快性能、更佳架构和更自由的许可。此举包括资金赞助、代码贡献和推广支持，目标是推动 Mediabunny 成为 Web 上的首选多媒体工具库，从而让浏览器能实现更高效的视频处理与应用。

www.remotion.dev

Sponsoring Mediabunny | Remotion | Make videos programmatically

With WebCodecs, we get an exciting new API for the browser, allowing us to bring performant multimedia workflows to the web.

AI 摘要：传统的 JavaScript 数组方法如 .sort() 、 .reverse() 和 .splice() 会直接修改原数组，可能带来难以排查的 bug，尤其在 React 等依赖 不可变数据 (immutability) 的框架中。ES2023 新增了 toSorted() 、 toReversed() 和 toSpliced() ，它们返回新数组而不会变异原始数据，从而提升代码可维护性和安全性。这一细小的语法改进带来了巨大的开发体验优化，特别是在现代前端应用中。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 新的不可变 (non-mutating) 方法
• toSorted()：返回排序后的新数组，允许自定义比较函数
• toReversed()：返回反转后的新数组，避免破坏原数组
• toSpliced()：返回元素增删后的新数组，保持原数组不变

2. 在 React 中的应用场景
• 保证状态不可变性，触发正确的重新渲染
• 常见用法：展示反向排序的任务列表、根据条件生成新数组
• 避免额外的深拷贝操作（如 structuredClone()）

3. 浏览器与环境支持
• Chrome/Edge 110+、Safari 16+、Firefox 115+、Node.js 20+ 原生支持
• 旧环境可依赖 core-js 提供 polyfill
• 与其他 ES2023 特性互补，如 optional chaining、top-level await

AI 摘要：本文从浏览器为何要限制 JavaScript 定时器 (setTimeout、setInterval 等) 的触发频率谈起，分析了其背后的性能与电池保护原因，并通过实验对比了不同的替代方案（MessageChannel、window.postMessage、scheduler.postTask 等）的性能表现。作者得出结论，scheduler.postTask 是最理想的方案，并进一步探讨了浏览器设计在“开发者自由 vs 用户体验保护”之间的平衡。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 背景与问题提出
• setTimeout(0) 实际上存在 4ms 的强制延迟 (clamping)
• 浏览器通过限制 (throttling) 避免过度消耗电量与降低交互体验
• 不同浏览器和环境对 setTimeout 的限制程度不同（例如后台标签页可达 1 秒，Safari 更严格）

2. 定时器替代方案的演进
• setImmediate：已废弃，仅存在于 IE/旧版 Edge
• MessageChannel.postMessage：常见 hack，但 Safari 有额外限制
• window.postMessage：性能较好，但可能与页面其他脚本冲突
• scheduler.postTask：新兴 API，表现最佳，且与浏览器渲染管线更契合

3. 实验与性能测试
• 测试方法：不同浏览器下运行 101 次迭代，测量定时器延迟
• 结果发现：
• Chrome 和 Firefox 的 setTimeout 明显受 4ms 限制
• Safari 对 setTimeout 和 MessageChannel 的限制更重
• scheduler.postTask 在 Chrome/Firefox 下表现优异
• fake-indexeddb 采用的最佳方案：优先 scheduler.postTask，降级 MessageChannel 或 window.postMessage

4. 浏览器设计哲学与开发者困境
• 设计者分为两派：
• 一派主张强制限制 API 防止开发者“自作聪明”导致性能恶化
• 另一派主张提供灵活 API，让开发者自负责任
• W3C 优先级原则：始终将用户体验放在开发者需求之上
• Scheduler API 的出现，体现了两派的折中：给开发者更精细的任务控制，但仍保持与浏览器渲染流程一致

5. 未来展望与风险
• 目前 postTask/postMessage 暂未遭到限制
• 但若开发者滥用（如滥用高优先级任务），未来也可能被浏览器进一步干预
• 文章提醒开发者谨慎选用 API，避免“自找麻烦”

AI 摘要：作者指出在 beforeunload/unload 里用 XMLHttpRequest 或 fetch 上报并不可靠，因为浏览器不会为脚本阻塞卸载流程，网络请求易被取消；推荐使用信标接口 (Beacon API) 的 navigator.sendBeacon 进行 fire-and-forget 异步上报：无需回调或 Promise，JS 立即结束，由浏览器后台传输；虽仅支持 POST 且负载很小，但非常适合离开页面、实时埋点与轻量级前后端同步等无需等待响应的场景，文末附 MDN 文档。

1. 问题背景与常见误区
• 用户离开网站不只关闭标签页，也可能修改地址栏或点书签，难以精准用单一事件捕获。
• 常见做法是在 beforeunload/unload 里用 XMLHttpRequest/fetch 上报，但实践中经常不稳定。

2. 为什么 beforeunload 不可靠
• 浏览器不会为执行 JavaScript 而阻塞卸载流程，以免影响用户体验。
• 页面卸载时网络请求可能未发出或被浏览器取消，导致上报丢失。

3. Beacon API 介绍与用法
• 核心调用：navigator.sendBeacon(url, data)；发送后立即返回，无回调或 Promise。
• 特性：fire-and-forget，浏览器接管传输，JS 执行立即结束，内存不被占用。
• 设计目标：在卸载等敏感时机可靠传递小数据。

4. 适用场景
• 页面关闭/跳转时的 analytics 上报、自动登出提示或状态同步。
• 任意时刻的轻量数据同步（如输入草稿、埋点）——无需等待响应即可继续交互。

5. 限制与注意事项
• 仅支持 POST，负载较小，适合“微消息”而非大体量数据。
• 不适用于需要确认响应、复杂重试或事务保证的场景；这类应选用 fetch/XHR 并在交互上做等待或队列重试。

6. 参考链接
• Beacon API - MDN

hemath.dev

Say bye with JavaScript Beacon

Send data, say goodbye, and move on. That's JavaScript's Beacon in one line.