Now vibe coding, so learning hammer FE ?
《Oxlint 原生集成 React Compiler：Lint 速度提升 3 倍，Rust 工具链再进一步》
标签：
#前端开发 #React #Rust #Oxlint #性能优化 #编译器
总结：
Oxlint 在 v1.79.0 中正式原生集成了 React Compiler 的 22 条 lint 规则，无需 Babel 管道即可在 Rust 层直接运行。这意味着开发者可以在 lint 阶段就捕获 React Compiler 的 bailout（回退）情况，而 lint 任务耗时从约 29.2 秒骤降至 9.1 秒（3.2 倍加速），若去掉其他 JS 插件甚至可达 11 倍。作者强调：使用 React Compiler 时，启用全部 lint 规则是"不可争议的前提条件"，因为一次 bailout 就可能导致性能严重退化（如作者主页动画卡顿）。同时，oxc 的 Rust 版 React Compiler 构建时转换也已接近可用，比原版快约 2 倍。
文章要点：
1. React Compiler 的 Rust 重写已成官方版本 — React 团队近期发布了 Rust 重写的 React Compiler，作为新的 canonical 版本。作者已在 AI 建站工具 Outlyne 中使用近一年，彻底告别手动
2. 作者已全面迁移到 oxc 生态 — Rollup → Rolldown、ESLint → Oxlint、Prettier → oxfmt、Jest → Vitest，整体工具链已 Rust 化，但 React Compiler 的 lint 插件一直是瓶颈。
3. 旧方案的痛点：Babel 管道拖慢 lint 3 倍 — 此前通过 Oxlint 的 JS 插件支持运行 React Compiler linter，需要先跑 Babel 再跑 Compiler 核心构建 AST，导致 lint 任务耗时从 9 秒暴涨到 29 秒。
4. Oxlint v1.70.0 起引入原生支持 — 新增 nursery 规则
5. 推荐配置：correctness + 枚举剩余规则 — 启用
6. 速度实测：3.2 倍到 11 倍提升 — 原生规则下 lint 从 29.2s → 9.1s；若同时去掉无原生替代的 JS 插件（如 perfectionist），可进一步降至 2.6s，实现 11 倍加速。
7. 构建时转换也在推进中 — oxc 已合并原生构建时 transform，但 Rolldown/Vite 曾因二进制体积增加 17% 而暂时回退。oxc-transform-react v0.0.1 已发布，比原版 Rust Compiler 快约 2 倍，source map 已修复，支持 fast refresh，作者已在生产环境测试。
8. 迁移门槛极低 — 只需 lint 层面改动，不影响构建步骤。可用
9. 一个常见陷阱：props 重新赋值 —
10. 作者的底线原则 — "React Compiler without linting all bailouts considered unsafe"（不 lint 所有 bailout 的 React Compiler 视为不安全）。一次 bailout 曾导致其首页动画 placeholder 卡顿、视觉破碎。
URL：
https://blog.master.dev/react-compiler-linting-just-got-a-rust-native-speedup-in-oxlint/
标签：
#前端开发 #React #Rust #Oxlint #性能优化 #编译器
总结：
Oxlint 在 v1.79.0 中正式原生集成了 React Compiler 的 22 条 lint 规则，无需 Babel 管道即可在 Rust 层直接运行。这意味着开发者可以在 lint 阶段就捕获 React Compiler 的 bailout（回退）情况，而 lint 任务耗时从约 29.2 秒骤降至 9.1 秒（3.2 倍加速），若去掉其他 JS 插件甚至可达 11 倍。作者强调：使用 React Compiler 时，启用全部 lint 规则是"不可争议的前提条件"，因为一次 bailout 就可能导致性能严重退化（如作者主页动画卡顿）。同时，oxc 的 Rust 版 React Compiler 构建时转换也已接近可用，比原版快约 2 倍。
文章要点：
1. React Compiler 的 Rust 重写已成官方版本 — React 团队近期发布了 Rust 重写的 React Compiler，作为新的 canonical 版本。作者已在 AI 建站工具 Outlyne 中使用近一年，彻底告别手动
useCallback/useMemo。2. 作者已全面迁移到 oxc 生态 — Rollup → Rolldown、ESLint → Oxlint、Prettier → oxfmt、Jest → Vitest，整体工具链已 Rust 化，但 React Compiler 的 lint 插件一直是瓶颈。
3. 旧方案的痛点：Babel 管道拖慢 lint 3 倍 — 此前通过 Oxlint 的 JS 插件支持运行 React Compiler linter，需要先跑 Babel 再跑 Compiler 核心构建 AST，导致 lint 任务耗时从 9 秒暴涨到 29 秒。
4. Oxlint v1.70.0 起引入原生支持 — 新增 nursery 规则
react/react-compiler，直接在 Rust 中运行 React Compiler，无需 Babel。v1.79.0 正式发布 22 条 Compiler 驱动的规则，覆盖 React 规则的验证。5. 推荐配置：correctness + 枚举剩余规则 — 启用
correctness 类别可覆盖 12 条规则，再手动列出其余 10 条。若启用 restriction 类别则自动再纳入 5 条，suspicious 纳入 4 条，perf 纳入 1 条。6. 速度实测：3.2 倍到 11 倍提升 — 原生规则下 lint 从 29.2s → 9.1s；若同时去掉无原生替代的 JS 插件（如 perfectionist），可进一步降至 2.6s，实现 11 倍加速。
7. 构建时转换也在推进中 — oxc 已合并原生构建时 transform，但 Rolldown/Vite 曾因二进制体积增加 17% 而暂时回退。oxc-transform-react v0.0.1 已发布，比原版 Rust Compiler 快约 2 倍，source map 已修复，支持 fast refresh，作者已在生产环境测试。
8. 迁移门槛极低 — 只需 lint 层面改动，不影响构建步骤。可用
npx @oxlint/migrate 自动迁移 ESLint flat config，或让 LLM 帮忙。甚至可以先并行跑 Oxlint 和 ESLint，只替换 React Compiler 插件就能提速。9. 一个常见陷阱：props 重新赋值 —
function MyComponent({ value }) { value = value ?? fallback; } 这种写法会让整个组件被 Compiler 跳过（bailout），导致性能退化。建议用解构重命名解决，同时开启 eslint/no-param-reassign 规则。10. 作者的底线原则 — "React Compiler without linting all bailouts considered unsafe"（不 lint 所有 bailout 的 React Compiler 视为不安全）。一次 bailout 曾导致其首页动画 placeholder 卡顿、视觉破碎。
URL：
https://blog.master.dev/react-compiler-linting-just-got-a-rust-native-speedup-in-oxlint/
blog.master.dev
React Compiler Linting Just Got a Rust-Native Speedup in Oxlint
Update! This is a re-written version of this recently-published post about linting code bound for the React Compiler with Oxlint. Oxlint just published a new guide to this, so this post reflects that new information. The React team made a big splash recently…
《Python 3.15的JIT编译器重回正轨》
标签：#Python #JIT #CPython #性能优化 #Faster_CPython #编译器 #开源社区
总结：
Python 3.15的JIT编译器开发取得突破性进展，在失去主要赞助商后通过社区协作成功实现性能目标。目前macOS AArch64平台比解释器快11-12%，Linux x86_64快5-6%，提前完成预定目标。文章强调了团队建设、任务分解和幸运的技术决策（如追踪记录解释器和引用计数消除）对项目成功的关键作用。
文章要点：
- **性能目标提前达成**：Python 3.15的JIT在macOS AArch64上比尾调用解释器快11-12%，在Linux x86_64上比标准解释器快5-6%，提前一年多完成目标
- **从困境中重生**：Faster CPython团队2025年失去主要赞助商后，通过社区托管模式维持开发，作者曾怀疑JIT项目能否成功
- **降低"巴士因子"风险**：团队计划在JIT的前端（区域选择器）、中端（优化器）、后端（代码生成器）各配备2名活跃维护者，目前中端已有4名贡献者
- **任务分解吸引新人**：将复杂优化问题拆分为简单任务（如"优化单条指令"），提供详细可操作的指导，让无JIT经验的C程序员也能参与，共11人参与核心重构
- **关键技术决策**：Brandt建议改用追踪式前端，Mark建议双分派表机制，意外地将追踪解释器性能从慢6%提升到快1.x%，并将JIT代码覆盖率提升50%
- **引用计数消除优化**：消除每条Python指令的分支操作，这一优化易于并行化且适合教学，是3.15版本的主要优化方向
- **基础设施支撑**：Savannah Ostrowski一人搭建了等效于整个基础设施团队的CI系统，每日性能测试帮助快速发现回归问题
文章URL：
https://fidget-spinner.github.io/posts/jit-on-track.html
标签：#Python #JIT #CPython #性能优化 #Faster_CPython #编译器 #开源社区
总结：
Python 3.15的JIT编译器开发取得突破性进展，在失去主要赞助商后通过社区协作成功实现性能目标。目前macOS AArch64平台比解释器快11-12%，Linux x86_64快5-6%，提前完成预定目标。文章强调了团队建设、任务分解和幸运的技术决策（如追踪记录解释器和引用计数消除）对项目成功的关键作用。
文章要点：
- **性能目标提前达成**：Python 3.15的JIT在macOS AArch64上比尾调用解释器快11-12%，在Linux x86_64上比标准解释器快5-6%，提前一年多完成目标
- **从困境中重生**：Faster CPython团队2025年失去主要赞助商后，通过社区托管模式维持开发，作者曾怀疑JIT项目能否成功
- **降低"巴士因子"风险**：团队计划在JIT的前端（区域选择器）、中端（优化器）、后端（代码生成器）各配备2名活跃维护者，目前中端已有4名贡献者
- **任务分解吸引新人**：将复杂优化问题拆分为简单任务（如"优化单条指令"），提供详细可操作的指导，让无JIT经验的C程序员也能参与，共11人参与核心重构
- **关键技术决策**：Brandt建议改用追踪式前端，Mark建议双分派表机制，意外地将追踪解释器性能从慢6%提升到快1.x%，并将JIT代码覆盖率提升50%
- **引用计数消除优化**：消除每条Python指令的分支操作，这一优化易于并行化且适合教学，是3.15版本的主要优化方向
- **基础设施支撑**：Savannah Ostrowski一人搭建了等效于整个基础设施团队的CI系统，每日性能测试帮助快速发现回归问题
文章URL：
https://fidget-spinner.github.io/posts/jit-on-track.html
