This media is not supported in your browser
VIEW IN TELEGRAM
#demo #codepen #动画 #CSS #SVG #设计
404 Error Face:Jon Kantner 基于 Camo Creative 的设计,将 404 错误页转为纯 CSS 和 SVG 的循环动画,用趣味视觉缓解用户体验挫败感。
404 Error Face:Jon Kantner 基于 Camo Creative 的设计,将 404 错误页转为纯 CSS 和 SVG 的循环动画,用趣味视觉缓解用户体验挫败感。
#优质博文 #vite #工程化 #前端 #开源 #新动态
VueConf 上说的 Vite+,介绍文章也来了(
Announcing Vite+
[以下是方便搜索索引的大纲(AI 生成),请读原文]
author Evan You
VueConf 上说的 Vite+,介绍文章也来了(
Announcing Vite+
AI 摘要:Vite+ 是在 ViteConf 上发布的全新统一工具链(unified toolchain),旨在整合构建、测试、格式化、代码规范检查和库打包等开发环节,解决 JavaScript 工具碎片化与性能瓶颈问题。它在 Vite 基础上新增 vite new、vite test、vite lint、vite fmt、vite lib、vite run、vite ui 等命令,并基于 Rust 实现完整编译链以实现极致性能。Vite+ 将采用 “source-available” 的商业许可策略,对个人及开源用户免费,对企业采取付费订阅模型,目标是构建可持续的前端生态。
[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. Vite+ 简介
• 来源于 Vite,同样可从 npm 安装;作为简体升级版,整合更多开发命令。
• 目标是提供统一的前端工程体验,使复杂项目的开发、测试与构建更加高效。
• 与 React、Vue、SvelteKit 等框架无缝兼容,并可直接用于单体或 monorepo。
2. 核心特性与命令集
• vite new:生成新项目或为 monorepo 生成代码模块。
• vite test:由 Vitest 驱动,兼容 Jest API,支持浏览器测试、分片和可视化回归测试。
• vite lint:集成 Oxlint,支持类型感知检查,性能比 ESLint 快百倍。
• vite fmt:即将发布的 Oxfmt 格式化工具,兼容 Prettier,提供更多换行与格式控制能力。
• vite lib:用于构建库,集成 tsdown 与 Rolldown,自动生成类型声明。
• vite run:智能缓存的任务执行器,无需显式配置即可获得细粒度缓存。
• vite ui:图形化开发工具,展示模块解析、打包与摇树分析等信息。
3. Rust 驱动的底层实现与性能优化
• 全链路由 Rust 重构实现,包括 parser、resolver、transformer、minifier、bundler。
• 高度性能调优,并被 Framer、Linear、Atlassian、Shopify 等公司采用。
• 暴露 parse 和 transform API,便于二次开发。
4. 解决的问题:JavaScript 工具生态的碎片化
• 多项目多团队导致依赖不一致、安全审核复杂与工具迁移成本高。
• Vite+ 旨在提供统一、协同的工具基础架构,减少配置、调试与迁移成本。
• 通过一致的命令与生态整合,提升开发协作效率。
5. 商业化与开源策略
• 将采用 “source-available” 策略:个人、开源、小型团队免费使用;企业需订阅授权。
• 收费部分将反哺 Vite+ 及其基础开源项目(Vite、Vitest、Rolldown、Oxc)。
• 承诺上述基础项目始终保持 MIT 开源许可。
• 目标是在维持社区信任与生态创新的前提下,探索开源项目的可持续商业模式。
6. 计划与参与方式
• 预计 2026 年推出公开预览版。
• 招募早期试用用户,可访问 viteplus.dev 参与测试。
• 官方希望社区共同塑造 Vite+ 的发展方向。
author Evan You
void(0)
Announcing Vite+
Introducing Vite+, a unified toolchain for JavaScript.
👍1
#优质博文 #V8 #性能优化 #JavaScript
CF 不愧是赛博活菩萨捏,大气的。
https://fixupx.com/DIYgod/status/1978461834731512072
Unpacking Cloudflare Workers CPU Performance Benchmarks
[以下是方便搜索索引的大纲(AI 生成),请读原文]
author Kenton Varda
CF 不愧是赛博活菩萨捏,大气的。
@DIYgod: 一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差,今天 Cloudflare 回应了篇博客承认错误,解释了造成问题的各种技术细节,现在把性能也追上来了 太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了,现在倒是显得 Vercel 小肚鸡肠了...
https://fixupx.com/DIYgod/status/1978461834731512072
Unpacking Cloudflare Workers CPU Performance Benchmarks
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 生态。
[以下是方便搜索索引的大纲(AI 生成),请读原文]
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 鼓励社区提交性能测试,团队会分析并修复问题
• 长期目标:通过改进开放源代码基础设施提升整个生态性能
author Kenton Varda
FixupX
DIŸgöd ☀️ (@DIYgod)
一周前 Vercel 发了篇博客指责竞争对手 Cloudflare Workers 性能差,今天 Cloudflare 回应了篇博客承认错误,解释了造成问题的各种技术细节,现在把性能也追上来了
太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了,现在倒是显得 Vercel 小肚鸡肠了...
太佩服这种在竞争对手面前勇于承认错误的勇气和快速透明解决问题的态度了,现在倒是显得 Vercel 小肚鸡肠了...
😁2
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
#优质博文 #Git #版本控制
好看,爱看。
从零开始理解 Git|纯手工打造 Git 仓库|太长可以不看 - 小众软件
好看,爱看。
从零开始理解 Git|纯手工打造 Git 仓库|太长可以不看 - 小众软件
AI 摘要:本文从零开始手工实现 Git 仓库的内部结构与命令逻辑,解释了 git init、git commit、git cat-file 等操作背后发生的机制。作者通过亲手创建 .git 目录与对象,展示 Git 的核心原理如内容可寻址存储(Content Addressable Storage, CAS)、树对象与提交对象、打包与垃圾回收(garbage collection)机制等,帮助读者摆脱“命令黑箱”的依赖,以理解 Git 的本质优雅与简洁设计。
小众软件
从零开始理解 Git|纯手工打造 Git 仓库|太长可以不看 - 小众软件
但实际上,这篇文章不是从零开始,它更像是当你已经使用了很久的 git,熟悉各种操作之后,又想再次重新开始,重新理解 git 是什么的内容。 比如:当你输入了 git init 之后,究竟都发生了什么。
#优质博文 #React #前端 #工程化
React Folder Structure in 5 Steps (2025)
[以下是方便搜索索引的大纲(AI 生成),请读原文]
author Robin Wieruch
React Folder Structure in 5 Steps (2025)
AI 摘要:本文详解了作者多年实践总结出的 React 项目结构化思路,以「逐层演进」为主线,从单文件组件到分页驱动(Page-driven)架构,展示了如何通过结构分层与命名规范,实现 React 应用在复杂度与团队协作下的平衡。文章强调不存在唯一正确方案,读者应根据项目规模与团队习惯灵活调整。
[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 单文件阶段(Single React File)
• 初始项目通常包含一个 src/App.js 文件。
• 所有组件起初可写在单文件中,便于快速原型开发。
• 随项目增长,应将可复用组件拆分,以减少冗余和嵌套复杂度。
2. 多文件阶段(Multiple React Files)
• 抽离可重复使用的组件为独立文件,如 List 和 ListItem。
• 通过文件导出(export)定义组件的“公共接口”(API)。
• 使用文件扩展名策略(.js/.jsx/.ts/.tsx)统一文件规范。
• 建议仅对可复用组件拆分,不要过早抽象。
3. 文件夹化阶段(From Files to Folders)
• 随组件复杂度增加,将相关技术关注点(测试 test、样式 style、类型 type、工具 utils)集中在组件文件夹。
• 采用“一个组件一个文件夹”的结构,如 src/list/ 或 src/app/。
• 使用 index.js 作为模块对外出口(即“barrel 文件”),控制组件的公共 API。
• 讨论命名规范(如 .spec.js、.module.css)与层级深度(避免超过两级嵌套)。
• 建议尽量避免过深目录,用功能聚合代替结构嵌套。
4. 技术型文件夹(Technical Folders in React)
• 当项目达到中等规模,应区分“组件类”与“技术类”逻辑。
• 在 src/ 中增设按技术职能划分的文件夹:
• components/:组件逻辑
• hooks/:自定义 React Hooks
• context/:应用全局状态
• services/:通用服务(格式化、错误追踪、请求封装等)
• 服务示例通过 Intl API 实现日期格式化并由模块封装暴露。
• 推荐使用路径别名(alias,如 @/services/...)避免相对路径混乱。
• 指出 barrel 文件的利弊——简化导入但可能削弱 tree-shaking。
5. 功能型文件夹(Feature Folders in React)
• 大型项目中,按“业务领域(Feature)”划分文件夹,以聚合其内所有组件与逻辑。
• 结构区分:
• feature/:业务特定代码(如 user、post、payment)
• components/:跨 feature 可复用的 UI 组件
• services/hooks/context:依旧保留为全局可重用逻辑
• 每个 feature 内可包含对应 components/、services/ 等子文件夹以划分技术关注点。
• 帮助团队并行开发、限域依赖,提高可维护性与灵活性。
6. 页面驱动结构(Page Driven Structure)
• 当应用存在多页面(特别是 Next.js 或 Vite + React),建议围绕 pages/ 或 app/ 文件夹组织。
• 每个页面对应入口点 (page.tsx),并链接相关 feature。
• 在同页面内是否嵌套 feature/取决于其复用度与作用域;鼓励保持一致的目录结构。
• 比较 Next.js 的文件路由与客户端路由在结构设计上的差异。
• 最终形成具有多层抽象但一致规则的工程化结构,支持扩展与团队协作。
7. 总结与启发
• 无绝对正确的文件结构,应随项目自然演化。
• 遵循“按复用程度而分层”,“按技术职能而归类”,“按业务边界而划分”的原则。
• 五步推进法可帮助开发者在项目复杂化时保持组织清晰。
author Robin Wieruch
www.robinwieruch.de
React Folder Structure in 5 Steps [2025]
React Folder Structure in 2025 for large React projects. The guide walks you through a file structure from small to large project ...
#优质博文 #CSS #动画 #前端 #course
Sequential linear() Animation With N Elements | CSS-Tricks
[以下是方便搜索索引的大纲(AI 生成),请读原文]
author Temani Afif
Sequential linear() Animation With N Elements | CSS-Tricks
AI 摘要:本文通过一个简洁的示例与完整讲解,展示了如何仅用几行现代 CSS 代码实现 N 个元素的顺序动画。作者利用 CSS 的 linear() 函数自定义时间曲线(timing function),结合 sibling-index() 与 sibling-count() 自动计算每个元素的动画时间段,使所有元素依次播放动画而不需复杂的 keyframes 管理。该方法具有可扩展性和可维护性,为 CSS 动画提供了新的编程式思路。
[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 背景与问题定义
• 多个元素需要依次执行相同的动画,传统方法需手动定义复杂 keyframes 与延迟。
• 目标:用纯 CSS,在不修改 keyframes 的前提下让动画顺序执行、可循环、可扩展至任意元素数量。
2. CSS linear() 函数解释
• linear() 是一种新的时间函数(easing function),支持自定义多个控制点(control points)。
• 通过定义输入进度(input progress)与输出进度(output progress)来构造任意变化曲线。
• 相较于传统 ease 或 cubic-bezier(),linear() 可精确定义不同阶段的动画输出。
• 可用百分比或数值型进度表示时间点,省略值会自动插补为中间点。
3. 利用 linear() 构造延迟(animation delay)
• 通过重复定义相同输出值(如 linear(0 0%, 0 50%, 1 100%))可制造“暂停”效果。
• 表示动画前半段不变化、后半段才执行。
• 可灵活组合多个时间段,无需修改 keyframes 即可调整节奏。
4. 构建顺序动画逻辑
• 多元素顺序动画思想:每个元素仅在自己的时间段(range)内动画,其余时间保持静止。
• 对于 N 个元素,将总时间分为 N 等份,每个元素依次占一个区间。
• 变量定义:
• S = 起始点 = (i - 1) × 100% / N
• E = 结束点 = i × 100% / N
• 关键 CSS 实现:
--_s: calc(100%(sibling-index()-1)/sibling-count());
--_e: calc(100%(sibling-index())/sibling-count());
animation: x calc(var(--d)*sibling-count()) infinite
linear(0, 0 var(--_s), 1, 0 var(--_e), 0);
• 使用 sibling-index()/sibling-count() 自动计算索引与总量,无需额外 JS。
5. 浏览器兼容性与注意事项
• 目前主要支持 Chromium 内核(Chrome、Edge),Firefox 与 WebKit 尚在推进中。
• 某些变量可能需通过 @property 注册以解决兼容性问题。
6. 扩展与变体
• 可设计多个重叠区间(N+1 ranges)使动画出现过渡重叠(overlapping)效果。
• 原理一致:通过调整控制点范围改变动画逻辑,可产生更复杂的节奏模式。
7. 总结
• linear() 函数原为实现复杂缓动曲线而生,但结合现代 CSS 特性(变量、siblings 函数)可实现可编程化动画逻辑。
• 提供一种无需 JS、结构清晰、可扩展的纯 CSS 动画新范式。
author Temani Afif
CSS-Tricks
Sequential linear() Animation With N Elements | CSS-Tricks
Let’s suppose you have N elements with the same animation that should animate sequentially. Modern CSS makes this easy and it works for any number of items!
❤1
#优质博文 #前端
50 Reasons to Build a Website
以 50 个生活化的理由,回答 “为什么在 2025 年仍然要建网站” 这个问题,我喜欢这些理由。
author Chris Coyier
50 Reasons to Build a Website
以 50 个生活化的理由,回答 “为什么在 2025 年仍然要建网站” 这个问题,我喜欢这些理由。
「你的乐队需要有一个网站,这是肯定的」
「你刚开始接触观鸟,你想要一个网站来发布你看到的酷鸟」
「你认为网络技术可以像油画和画布一样,成为艺术家的工具。你制作网站就像画家作画一样」
author Chris Coyier
Frontend Masters
50 Reasons to Build a Website
There’s been a little chatter circling the question “Why would I build a website in 2025?” I was on a panel about it in the last year and it has popped up on various podcasts and such. It’s a fair question, but it’s one that, I think, requires both a very…
👍1
#优质博文 #JavaScript #前端
太深入了 orz
Why typeof null === object
author Piotr Zarycki
太深入了 orz
Why typeof null === object
AI 摘要:本文系统回顾了 typeof null === "object" 的历史与技术背景,从现代 JavaScript 引擎的内存标记机制 (pointer tagging) 到最初的 Netscape 实现原理,解释了这一“bug”如何产生并延续至今。作者复原了早期 C 语言实现及源码宏定义,揭示 null 被识别为对象的根本原因是早期 32 位系统的对齐与标记约定。尽管这一问题可轻易修复,但考虑到巨大的兼容性影响,标准委员会选择保留这一行为,使它成为语言历史上的经典遗产。
author Piotr Zarycki
pzarycki.com
Why typeof null === object
Learn why typeof null returns ‘object’ instead of ’null’ in JavaScript
#优质博文 #HTML #WCAG #前端 #语义化
HTML’s Best Kept Secret: The output Tag
本文介绍了 HTML 中一个鲜为人知但功能强大的
author Den Odell
HTML’s Best Kept Secret: The output Tag
本文介绍了 HTML 中一个鲜为人知但功能强大的
<output>
标签,它能在网页上自然地显示计算或用户操作结果,并具备天然的无障碍(Accessibility)支持,但却一直被忽略。author Den Odell
Den Odell
HTML’s Best Kept Secret: The output Tag
Make your dynamic content accessible by default with the HTML tag that time forgot.
👍3
#优质博文 #AI #MCP #GitHub #MCP #开源
Accelerate developer productivity with these 9 open source AI and MCP projects
[以下是方便搜索索引的大纲(AI 生成),请读原文]
Accelerate developer productivity with these 9 open source AI and MCP projects
AI 摘要:GitHub 携手 Microsoft OSPO、Copilot 与 VS Code 团队,赞助了九个基于 Model Context Protocol (MCP) 的开源项目,以促进 AI 工具与开发平台的深度结合。这些项目聚焦三大主题:框架与平台集成、AI 增强的开发体验、以及自动化与编排。
[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 框架与平台集成
• fastapi_mcp:将 FastAPI 端点暴露为安全的 MCP 工具,提供统一基础设施与认证机制。
• nuxt-mcp:面向 Nuxt 应用的调试与路由工具,帮助模型理解 Vite/Nuxt 架构代码。
• unity-mcp:连接 Unity 引擎 API,赋予 AI 管理游戏资产、场景和脚本的能力,实现智能自动化游戏开发。
2. 开发者体验与 AI 增强编码
• context7:提取项目中与版本关联的文档与示例,直接嵌入 LLM (Large Language Model) 提示上下文。
• serena:提供语义检索与代码编辑功能,支持面向代理(agent-driven)的编程流程。
• Peekaboo:分析 Swift 代码界面,为 AI 助手提供可操作的 GUI 自动化上下文。
• coderunner:让 LLM 能在本地沙盒中自动执行与安装依赖,实现即时代码运行与结果反馈。
3. 自动化、测试与编排
• n8n-mcp:为 n8n 平台注入 AI 驱动的工作流自动化,优化节点理解与流程创建。
• inspector:测试与调试 MCP 服务器的工具,支持协议握手检查、OAuth 流程追踪与安全评估模拟。
The GitHub Blog
Accelerate developer productivity with these 9 open source AI and MCP projects
These nine open source MCP projects provide new frameworks, tools, and assistants to unlock AI-native workflows, agentic tooling, and innovation.
#碎碎念
https://fixupx.com/Manjusaka_Lee/status/1980184017778688047
见证历史(?)
AWS USE1 挂了,感觉自己的半个互联网寄了
https://downdetector.com/
https://fixupx.com/Manjusaka_Lee/status/1980184017778688047
见证历史(?)
AWS USE1 挂了,感觉自己的半个互联网寄了
https://downdetector.com/
#优质博文 #React #RSC #性能 #前端 #架构
React Server Components: Do They Really Improve Performance?
一篇以数据为主的实证研究,比较 CSR、SSR 与 RSC 的性能优劣及实现差异。
结果显示,CSR 初次加载最慢但交互最快;SSR 可改善 LCP 但是有“无交互”的空窗期;RSC 若结合 Streaming 和 Suspense 可获得最佳平衡,但实际迁移复杂且对架构要求高。单纯引入 RSC 并不会自动带来性能提升,收益主要来自异步数据流与渲染策略的改写。
author Nadia Makarevich
React Server Components: Do They Really Improve Performance?
一篇以数据为主的实证研究,比较 CSR、SSR 与 RSC 的性能优劣及实现差异。
结果显示,CSR 初次加载最慢但交互最快;SSR 可改善 LCP 但是有“无交互”的空窗期;RSC 若结合 Streaming 和 Suspense 可获得最佳平衡,但实际迁移复杂且对架构要求高。单纯引入 RSC 并不会自动带来性能提升,收益主要来自异步数据流与渲染策略的改写。
author Nadia Makarevich
Developerway
React Server Components: Do They Really Improve Performance?
A data-driven comparison of CSR, SSR, and RSC under the same app and test setup, focusing on initial-load performance and the impact of client- vs server-side data fetching (including Streaming + Suspense).
#优质博文 #调试 #前端 #React #CSS
少有的讲述「在 vibe coding 中如何调试问题」的文章~当然也适合正常的 bugfix。
How to Fix Any Bug
[以下是方便搜索索引的大纲 (AI 生成),请读原文]
author Dan Abramov
少有的讲述「在 vibe coding 中如何调试问题」的文章~当然也适合正常的 bugfix。
How to Fix Any Bug
AI 摘要:本文通过作者在开发一个 web 应用中遇到的「滚动失效」 bug,讲述调试问题的系统过程。核心思想是:编写可复现 (repro) 案例、不断缩小问题、保持 bug 的持续存在以保证分析方向正确,并通过持续简化最终发现真实原因——旧版 React Router 的 ScrollRestoration 组件在重验证过程中不当恢复滚动位置。文章强调调试纪律与“有根递归”(well-founded recursion) 的类比:每一步都要确保前进、缩小问题范围,而不是随意跳转、依赖猜测。
[以下是方便搜索索引的大纲 (AI 生成),请读原文]
1. 问题起点:不可解释的滚动抖动
• 在应用中添加服务器请求后按钮滚动出现抖动。
• 初步怀疑 React Router 数据重载或 React 重渲染机制,但理论上不应造成影响。
2. Step 0:别急着修——没有 repro 一切无从谈起
• Claude 被要求修 bug,多次尝试“修复”但都无验证性。
• 没有可重现测试 (repro) 等于盲目调试,AI 与人类在此常犯同样错误。
3. Step 1:建立可靠的 repro
• 一个 repro 需要明确定义操作步骤、预期结果、实际表现。
• 若复现概率不高,需移除不确定因素(如模拟网络)。
• AI 无法直观识别“滚动抖动”,需重新定义可量化的 repro。
4. Step 2:缩小 repro
• 替换为测量滚动位置前后差值的量化 repro。
• 验证策略:当注释掉网络调用时行为回归正常,说明新的 repro 合理。
• 确保新的 repro 仍能表现“正向结果”,避免偏离原始问题。
5. Step 3:剥去无关部分
• 通过循环:复现 bug → 删除一部分代码 → 验证仍复现 → 提交变更。
• 若删除后 bug 消失,回滚并缩小删除范围。
• Claude 犯误:过早进入假设与实验,导致丢失“仍复现”前提。
• “调试有根性”类比:如同 well-founded recursion,确保每次简化是真正向终点推进,而非原地打转。
6. Step 4:定位根因
• 继续按步骤简化后,确认问题出现在包含 React Router 的布局结构中。
• 发现旧版 ScrollRestoration 在动作 (action) 触发重验证时被误调用,导致对正在进行的 scrollIntoView 干扰。
• 更新或移除旧逻辑即可修复。
7. 方法论总结
• bug 调试的精髓是“跟踪与约简”:始终保持一个仍可复现的最小案例。
• 当推测与理论全部无效时,逐步删减代码仍是通用、可靠的终极方法。
• 旧版依赖和运行环境不一致也可能制造隐藏问题。
author Dan Abramov
overreacted.io
How to Fix Any Bug — overreacted
The joys of vibecoding.
🥰1
#优质博文 #AI #浏览器 #ChatGPT #新动态
有人体验过了不,发的有点晚了,不过为 Codex 买的 ChatGPT Plus 好像又有点用了。
(没有说 Codex 不好的意思——只是 gpt 现在比较少用网页版都是用 api 了)
Introducing ChatGPT Atlas
有人体验过了不,发的有点晚了,不过为 Codex 买的 ChatGPT Plus 好像又有点用了。
(没有说 Codex 不好的意思——只是 gpt 现在比较少用网页版都是用 api 了)
Introducing ChatGPT Atlas
AI 摘要:ChatGPT Atlas 是 OpenAI 推出的智能浏览器,将 ChatGPT 深度整合进网页使用场景,使 AI 能理解网页内容、保留浏览记忆、自动执行任务。用户在浏览时可直接与 ChatGPT 对话、分析网页或完成操作,无需切换应用。它支持可控的记忆功能(memory)、智能代理模式(agent mode)、隐私与家长管理等,旨在打造一个安全且高效的网页工作助手。目前支持 macOS,Windows 与移动版即将推出。
Openai
Introducing ChatGPT Atlas
The browser with ChatGPT built in.
#优质博文 #前端 #新动态
Next.js 16:Next.js 16 发布,此次更新让 Turbopack 成为默认打包器,React Compiler 支持正式稳定,并且引入了全新的 Cache Components、Next.js Devtools MCP,统一代理文件 proxy.ts 取代 middleware.ts。
[以下是方便搜索索引的大纲(AI 生成),请读原文]
Next.js 16:Next.js 16 发布,此次更新让 Turbopack 成为默认打包器,React Compiler 支持正式稳定,并且引入了全新的 Cache Components、Next.js Devtools MCP,统一代理文件 proxy.ts 取代 middleware.ts。
[以下是方便搜索索引的大纲(AI 生成),请读原文]
1. 核心特性与架构升级
• 引入 Cache Components:基于“use cache” 指令的显式缓存机制,结合 PPR(Partial Pre-Rendering)完成静态与动态渲染的统一。
• 改进的缓存 API:新增 updateTag()、refresh(),更新 revalidateTag() 支持 cacheLife 配置,提升对缓存生命周期与数据一致性的控制。
• 增强路由系统:通过布局去重(layout deduplication)与增量预取(incremental prefetching)减少重复下载与数据冗余。
• 新的代理机制 proxy.ts:中间件(middleware.ts)演进为 proxy.ts,使网络边界清晰可见,并支持 Node.js 运行时。
2. 开发体验(DX)与工具改进
• Next.js Devtools MCP:集成 Model Context Protocol,支持 AI 调试代理,可透视应用路由、缓存与日志。
• 日志系统优化:构建与运行阶段的耗时分析细化,日志结构更清晰。
• Turbopack 默认启用:替代 Webpack,提供最高 10 倍快速刷新与 2–5 倍构建速度提升,支持文件系统缓存(File System Caching)。
• create-next-app 简化:模板默认启用 TypeScript、App Router、Tailwind CSS、ESLint,降低项目启动门槛。
3. React 与构建链支持
• React Compiler 支持:稳定集成 React Compiler 自动记忆化能力,减少不必要的重新渲染。
• React 19.2:支持新特性 View Transitions、useEffectEvent()、<Activity /> 等,即时交互体验优化。
• Build Adapters API(alpha):允许自定义构建适配器,实现部署平台与构建流程的联动。
4. 行为变更与重大调整
• 异步访问要求:params、cookies()、headers() 等需 await 调用。
• Node.js 20.9+、TypeScript 5+ 成为最低版本要求。
• Turbopack 成为全局默认打包器;middleware.ts 弃用,重命名为 proxy.ts。
• 图片策略更新:默认缓存时长延长、质量设置调整、新安全策略限制本地 IP 优化。
• 部分配置项(如 AMP、next lint、runtimeConfig)彻底移除或转为环境变量管理。
5. 性能与生态
• Node.js 原生 TypeScript 支持:新增 --experimental-next-config-strip-types。
• Dev/Build 输出目录分离,实现并行构建。
• 引入锁文件防止多实例冲突。
• 进一步提升 next dev / next start 命令性能。
nextjs.org
Next.js 16
Next.js 16 includes Cache Components, stable Turbopack, file system caching, React Compiler support, smarter routing, new caching APIs, and React 19.2 features.
#优质博文 #测试 #前端 #工程化 #新动态
Announcing Vitest 4.0:Vitest 团队宣布推出 Vitest 4.0,这是该测试框架的重大版本更新。此次版本将 Browser Mode 标记为稳定,让开发者能在真实浏览器环境中运行单元测试,从而获得更高的可靠性。此外还引入了 视觉回归测试 与 Playwright Trace 支持,提升了调试与测试体验。
[以下是方便搜索索引的大纲 (AI 生成),请读原文]
Announcing Vitest 4.0:Vitest 团队宣布推出 Vitest 4.0,这是该测试框架的重大版本更新。此次版本将 Browser Mode 标记为稳定,让开发者能在真实浏览器环境中运行单元测试,从而获得更高的可靠性。此外还引入了 视觉回归测试 与 Playwright Trace 支持,提升了调试与测试体验。
[以下是方便搜索索引的大纲 (AI 生成),请读原文]
1. 发布概况
• Vitest 在过去一年内从每周 700 万下载增长至 1700 万,社区影响力显著提升。
• 经过近一年的开发,Vitest 4.0 正式发布。
• 该版本包含若干重大变更(breaking changes),需参考迁移指南进行升级适配。
2. Browser Mode 稳定
• Browser Mode 结束 Beta 阶段,正式进入稳定版。
• 支持在真实浏览器中运行组件测试,不再局限于 JSDOM 等模拟环境。
• 使用相同的 Vitest API,无需修改测试代码。
• 基于 Playwright 等 provider 实现执行环境,但不替代现有 E2E 工具,仅改变测试运行方式。
3. 新增功能与改进
• 视觉回归测试 (Visual Regression Test):在 Browser Mode 下进行组件截图与参考图对比,用于检测视觉变化。
• Playwright Traces:生成可在 Trace Viewer 中分析的跟踪文件,辅助调试。
• 报告系统 (reporter) 更新、类型感知钩子 (type-aware hooks) 等多项改进。
4. 版本变更与迁移
• 此次为主版本升级,包含不兼容改动。
• 官方提供迁移指南:Migration guide。
5. 未来计划与社区
• 团队将重点优化性能和 Browser Mode 体验。
• 报告问题可通过 GitHub Issues 提交。
void(0)
Announcing Vitest 4.0
Vitest 4.0 is released with Browser Mode being marked stable, Visual Regression testing support, and Playwright Trace support. The Vitest team will focus on performance improvement in the upcoming quarter. This major release includes breaking changes.
👍2