AI 摘要：本文深入探讨了前端开发中主题和颜色命名的设计实践及困惑，从流行 CSS 框架的色板设计现状、手动与程序化生成色板的方法谈起，剖析了颜色变量定义中的“语义命名”混乱，并提出了更灵活与语义化兼容的命名及管理方式，以支持更加多变且有辨识度的 Web 设计系统。

CSS-Tricks

Thinking Deeply About Theming and Color Naming | CSS-Tricks

Today, I want to discuss a couple of patterns for naming color palettes that the community is using, and how I propose we can improve, so we achieve both flexibility and beauty.

AI 摘要：Tree shaking（摇树优化）已成为现代前端打包（bundler）领域的重要优化手段。不同 bundler 工具（如 Webpack、Rollup、esbuild、Turbopack）由于应用场景和关注点不同，实现 tree shaking 的原理与细节也有所差异。文章系统对比了这些工具的 tree shaking 实现，包括分析粒度、副作用（side effects）判定、模块/语句/AST（抽象语法树）层面的优化，以及各自的优势与局限性，并详细剖析了典型案例。对于需要深入理解前端 build 工具原理与优化策略的开发者极具参考价值。

GitHub

Bundler Tree Shaking 原理及差异 · web-infra-dev · Discussion #28

Tree shaking 在如今的前端打包领域已成为极为重要且不可或缺的一部分。鉴于各个 bundler 的适用场景和侧重点存在差异，因此各个 bundler 之间的 tree shaking 实现方式也各不相同。例如，Webpack 主要用于前端应用打包，侧重于正确性，其 tree shaking 主要关注跨模块级别的优化；而 Rollup 主要用于库打包，侧重于优化效率，其 tree s...

AI 摘要：本文作者作为 Claude Code 的深度用户，详细介绍了自己从 Cursor 转向全程使用 Claude Code 的开发体验，总结出一系列高效实用的使用建议。文章覆盖了 Claude Code 的 VS Code 插件启动、终端界面、权限系统、GitHub 集成、大型代码库表现、经济性、队列系统、自定义扩展、可视化界面及团队协作等方面，旨在帮助开发者最大化 Claude Code 在日常工作中的价值与便捷性。

Builder.io

How I use Claude Code (+ my best tips)

I switched from Cursor's agents to Claude Code weeks ago and I'm not going back. Here's how I use it and my best practical tips

本文系统介绍了 RAG（Retrieval-Augmented Generation，检索增强生成）模型的基本原理、实际应用场景及其在 NodeJS 环境下的基础实现。作者围绕文本数据的预处理、向量化、向量检索、多路召回、召回重排，以及 LLMs（大语言模型）在流程中的作用展开，详细讲解了如何以轻量级工具搭建一个实用的 RAG 检索服务，并讨论了分片策略、编码方法、检索优化及与开箱即用方案的取舍，为构建定制化AI知识问答系统提供了开源思路和技术参考。

1. RAG 简介与应用场景
• RAG 是结合检索（Retrieval）与生成（Generation）的 AI 架构，能提升对专业领域、高时效性内容的问答、代码生成等场景的回答质量。
• 适用于最新知识获取、特定领域知识补充、提升透明度与可解释性、长尾数据检索、垂直智能问答等实际需求。
• RAG 以内容检索为核心，兼容多种方式（如向量检索、倒排索引、图谱检索等），并与 LLMs 配合工作。

2. 文本向量化流程设计
• 数据预处理包括文本清洗和分片，分片方式有固定长度、overlap 重叠、句段分割、结构分片等，应兼顾语义完整性与检索效率。
• 分片时建议结合元信息（如标题、作者、时间等）以辅助召回与重排。
• 编码方式的演变从 one-hot，TF-IDF，到更先进的 Word2Vec、Transformer-based Embedding。实际项目推荐使用现成高效模型如 all-MiniLM-L6-v2。
• 分片及编码细节优化显著影响检索召回质量和成本。

3. 向量检索与多路召回机制
• 检索的核心是计算 Query 与候选文本的向量相似度，常用余弦相似度（Cosine Similarity），因其只关注方向信息，适合高维稀疏空间。
• 采用 hnswlib-node 快速完成高维向量检索，实际实现还需与实际内容并行存储，便于元数据同步。
• 多路召回建议综合关键词检索、向量召回、图谱召回等互补方式，通过加权、融合、重排序等策略提升检索全面性和精度。

4. 召回重排（Re-Ranking）及其优化
• 初次召回后需对候选结果做重排，提升真正相关内容在前，常见方法如下：
• 传统交叉编码器（如 BERT NSP）精排。
• LLMs 或专门 ReRanker 模型（如 BGE-Reranker）基于上下文深度理解排序。
• 分片元信息和人工打标可进一步增强重排效果，提升系统最终响应准确性和相关性。
• 重排虽可提升体验，但不可避免加大系统复杂度和响应耗时，需按场景权衡。

5. LLMs 在 RAG 流程中的多重角色
• 查询改写：修正拼写、分解多意图、格式化表达、扩展关键词等，显著提高召回精准度。
• 输入优化：用LLMs提升分片、编码智能化水平，以及用于多模态信息抽取、知识图谱构建等。
• 生成增强：将高相关检索片段作为上下文，辅助 LLMs 生成更自然、连贯、有据可溯的答案，并可提升系统的可用性与信任度。
• LLMs 贯穿流程多环节，兼具结构化与半结构化内容的处理与优化能力。

6. 方案总结与工程实践建议
• RAG 作为 AI Infra 基础模块，值得深入学习和灵活定制。开箱服务适用于通用场景，复杂定制或增量优化建议自行实现。
• 流程各节点（分片、编码、检索、重排、生成）都可精调优化，针对需求选择技术方案、服务模型和参数设定。
• RAG 在提升 LLMs 时效性、知识深度、成本控制等方面具备不可替代优势。

本文总结了 ViteLand 生态系统在 2025 年 7 月的主要动态，包括 Vite、Vitest、Oxc、Rolldown 等关键项目的最新进展，以及社区即将举办的线下盛会 ViteConf 的首场线下会议预告。Vite 团队将发布全新产品 Vite+，并聚焦前端开发领域的未来趋势。文章还预告了 Vite 纪录片的上线情况，为开发者提供了丰富的行业洞察和社区信息。

1. 生态系统进展
• 概述了 Vite、Vitest、Oxc、Rolldown 等项目在本月取得的主要更新和迭代。
• 着重强调了团队在提升开发者体验（DX, Developer Experience）方面的持续努力。

2. ViteConf 线下大会预告
• 预告 10 月将在阿姆斯特丹举行的首届线下 ViteConf，此前已有三届线上大会成功举办。
• 届时将首次发布 Vite+，介绍其功能和对团队工作流的提升作用。
• 大会将邀请知名演讲嘉宾，包括 Bolt.new/StackBlitz CEO Eric Simons 和 Netlify CEO Mathias Biilmann。
• 会议主题将围绕下一代开发工具（next-generation tooling）、智能 agent 体验等前端领域热点展开。

3. 社区与纪录片
• 宣布由 CultRepo 出品的 Vite 纪录片即将在活动中全球首映，展示 Vite 团队及 Svelte、Solid、Astro 等明星项目作者的未公开故事。
• 官方预告片已发布，可供提前观看，进一步增强社区凝聚力。

void(0)

What’s New in ViteLand: July 2025 Recap

July 2025 brings exciting updates in the Vite ecosystem, including the release of Vite 7, Rolldown's new features, and the upcoming ViteConf in Amsterdam. Discover the latest news in Vite, Vitest, Oxc, Rolldown and more!

AI 摘要：本期 Frontend Focus 报道了前端领域的最新动态和趋势，涵盖 CSS 新规范（如无 JavaScript 的走马灯、Masonry 布局、Scroll-Spy）、React/Next.js 开发中的常见陷阱、MDN 发展二十周年纪念，以及一批最新实用工具和开发资源。此外，简要提及了 Safari/Edge 等主流浏览器新特性和业界法规、社区大事件，适合前端开发者了解行业资讯和提升技术能力。

1. 前端社区动态与大事件
• MDN 文档网站庆祝成立 20 周年，目前拥有超 14,000 页内容，是 Web 开发的重要资料库
• 2025 Stack Overflow 开发者调查结果公布，涵盖开发工具、AI 代理、LLM 使用现状等
• W3C 发布关于组织使命与价值观的重要新文档
• HTML Day 活动将举办超 40 场全球盛会，HTML 技术持续推进
• Wikimedia 积极挑战英国在线安全法案，关注数字法规生态

2. CSS 新特性与最佳实践
• CSS Masonry 布局：探讨新规范进展与当前解决方案，兼顾未来性与可用性，附带交互反馈征集
• CSS Scroll-Spy ：Chrome 140 浏览器引入 scroll-target-group 和:target-current，可用两行 CSS 实现目录高亮跟踪效果
•  Responsive Video is (Almost) Easy Now：如何处理垂直和横向视频以适应不同场景，在上下文需要时提供垂直和水平版本。
• “现代 CSS 杀死 SPA”观点：提倡服务器渲染与页面级动画，倡导 CSS 动画和意图性预加载

3. Web 技术深度/创新话题
• The Useless useCallback：React 状态管理与性能相关实践讨论，分析 useCallback、useMemo 潜在问题，展望 React Compiler 与 useEffectEvent 等新工具的改善能力。
• Performance Extensibility API：允许自定义轨迹供 Chrome DevTools 性能面板分析
• WebAssembly（WASM）与 DOM 互操作性进展，工具链提升正降低 WASM 开发门槛
• Liquid Glass ：苹果新一代视觉样式的网页实现尝试
• Web Components 及 Shadow DOM 实践解析

4. 工具、组件与资源推荐
• World Clock Slider：多城市世界时钟组件，支持暗黑模式
• FossFLOW：等距基础架构图形工具，支持丰富图标与数据管理 【这个挺酷炫的】
• StaticSearch：为静态站点增添搜索，无需后端，基于 Javascript，数据存储为 JSON
• Oklchroma：基于 OKLCH 色彩空间的色板生成器，提供基色，使用三角函数生成不同色阶
• difit：使用 GitHub 风格查看器查看和审查本地 git 差异的 CLI 工具，评论还可以作为 AI 提示进行复制。
• 7.css：忠实还原经典 Windows 7/XP UI 的 CSS 设计系统
• 使用 Three.js、WebGPU 和 TSL 进行交互式文本销毁

MDN Web Docs

Celebrating 20 years of MDN | MDN Blog

MDN turns 20! Let's look at how we started, how MDN became the most trusted resource for web developers, the impact it's had on the open web, and yes, there's cake, too.

AI 摘要：本文由 Makito 首次在 Project AIRI 的 DevLog 分享，聚焦于如何在前端应用中处理和实现流式 UTF-8 字节流的文本动画，尤其是在聊天或语音转写等实时场景下正确分割和显示「字素簇」（grapheme cluster）。作者深入探讨了 Unicode 编码、多码点合成字符的边界难题，以及利用 Web API，如 TextDecoder、Intl.Segmenter，实现安全高效的字素簇流式提取，并介绍了自己的开源库 Clustr。文章结合了丰富的实例和交互组件，面向希望在项目中实现高质量文本动画及多语言兼容的前端开发者，具有较高参考价值。

1. 背景与动机
• 投稿者首次在 DevLog 发文，介绍参与 Project AIRI 过程。
• 动画文本在现代 UI（如聊天消息）中的作用和实现难点。
• 第三方库（Anime.js, splt, GSAP）在文本动画实现上的进展与现有不足。
• 项目的需求：需实时处理和动画化接收自 UTF-8 字节流的数据。

2. Unicode 基础与「字素簇」难题
• 码点（Code point）与 UTF-8 字节流的对应关系，字节组装所需注意事项。
• Unicode「字素簇」的定义，即多个码点合为视觉整体的最小文本单元。
• 通过实际 Emoji 和南亚文字示例，阐释组合字符的裸数据和视觉表现。
• 传统 Web API 如 TextDecoder 能将字节流还原为码点字符，但不足以分割复杂字素簇。

3. Web API 应用与完善方案
• 利用 TextDecoder.decode（stream选项）实现流式解码，拼接字符串缓冲区。
• 使用 Intl.Segmenter 拆分字符串为字素簇，支持多语言处理。
• 提出解决方案：因为流数据随时变化，需确保不完整的字素簇不被导出，因而采用「丢弃最后一个」策略缓冲输出，避免合成字符的过早显示。

4. 流式字素簇库 Clustr 的诞生
• 市场调研发现缺乏专门处理流式 UTF-8 字节流并输出字素簇的库。
• 作者自研 Clustr，核心代码不到100行，实现了上述需求。
• Clustr 能帮助前端实时渲染流式文本动画，兼容多语言复杂字符。

5. 互动组件与社区交流
• 提供探索字素簇组合和实时代码交互的小组件。
• 鼓励开发者参与 Project AIRI 相关 GitHub 仓库，共同讨论和改进工具。

AI 摘要：本文深入介绍了 Web Components 中 Shadow DOM（影子 DOM）的原理和实际应用。作者不仅阐述了 Shadow DOM 在隔离 HTML 和 CSS、避免组件冲突中的重要性，也详细讲解了如何通过命令式和声明式方式创建 Shadow Root 以及相关配置（如克隆、序列化、焦点委托），并介绍了 slot（插槽）机制以实现内容分发。文章面向希望提升组件封装性、可维护性和安全性的前端开发者提供了清晰的实践指南。

1. Web Components 与 Shadow DOM 概述
• Web Components 由 Custom Elements（自定义元素）、HTML Templates（模板）和 Shadow DOM 等技术组成，三者可单独或组合使用。
• 传统 DOM 架构容易导致样式与脚本污染，难以维护。
• Shadow DOM 可实现 DOM、CSS、JS 的局部封装，提升组件独立性与安全性。

2. 为什么需要 Shadow DOM
• 现代应用常集成来自不同来源的组件，容易出现 ID 冲突与样式覆盖问题。
• 原生 HTML 元素如 video、details 等都标准使用 Shadow DOM 避免全局影响。

3. Shadow Root 的宿主元素与创建方式
• 多数 HTML 元素（如 div、section、span 等）均可作为 Shadow Root 宿主。
• 创建方式分为：
• 命令式（JavaScript）：attachShadow({mode})，可选择 open（开放）或 closed（私有）模式，建议默认使用 closed，以增强安全性。
• 声明式（HTML）：利用 <template shadowrootmode=""> 内嵌 shadow root，可和 Custom Elements 配合使用，支持 open/closed 模式。
• 讨论 open/closed 模式的脚本访问区别与安全考虑。

4. Shadow DOM 配置项
• clonable：允许带有 shadow root 的节点可被完整克隆（包括模板内容），提升组件复用性。
• serializable：能将 shadow root 内容序列化为字符串，便于缓存或跨节点注入，但需注意闭合模式下的数据泄露风险。
• delegatesFocus：启用后，宿主获得焦点时自动将焦点转移到 shadow root 内第一个可聚焦元素，常用于自定义表单组件，增强用户体验。

5. Slot（插槽）与内容分发
• 通过 slot，可实现宿主与 Shadow DOM 之间的内容插入与分发，支持默认与命名插槽，并可定义 fallback（回退）内容。
• slotchange 事件用于监听 slot 内容变化，便于实现响应式组件行为。
• slotted 内容仍属于 light DOM，可在文档级直接操作。

6. 实用建议与局限性
• 推荐以 closed-first 策略增强组件安全性，特殊场景下才使用 open。
• 注意表单与可访问性（ARIA）相关的局限，部分需要借助 ElementInternals 等新 API 进一步处理。

Smashing Magazine

Web Components: Working With Shadow DOM — Smashing Magazine

Web Components are more than just Custom Elements. Shadow DOM, HTML Templates, and Custom Elements each play a role. In this article, Russell Beswick demonstrates how Shadow DOM fits into the broader picture, explaining why it matters, when to use it, and…

AI 摘要：Google Chrome 的 Performance Extensibility API （性能扩展 API）允许开发者将自定义的性能标记（performance.mark）和测量（performance.measure）集成进 Chrome DevTools 的性能面板，使自有应用、团队代码与第三方包可实现更细粒度、结构化和可视化的性能剖析。文中不仅介绍 API 的最小可用实践和高级特性（如自定义 track、颜色、分组与元数据），还探讨了如何借助这些新能力更好地组织跨团队、跨模块或第三方依赖的性能数据，以提升前端调优的效率和可读性。

1. 背景与意义
• Google Chrome 推出的 Performance Extensibility API 能让开发者自定义性能分析数据，在 DevTools 性能面板中更清晰展现。
• 适用于关注特定应用片段性能、跨团队协作及 API/第三方包开发者等多类场景。

2. 现有能力回顾（性能.mark 与 .measure）
• 介绍 performance.mark() 与 performance.measure() 的基础用法，展示如何标记重要事件并测量阶段耗时。
• DevTools 能自动捕获这些标记，方便用时长和起止点可视化查看。

3. Extensibility API 的最小实现
• 启用 DevTools 新特性（Show custom tracks）。
• 使用 mark 时 dataType 必填，measure 时 track 必填，其他均为可选。
• mark 实现更明显的“标志”，但缺乏精确时间信息，偏向定位关注点而非精确计时。
• measure 则可直接建立自定义轨道，并展现分时区间。

4. 高级用法与增强能力
• 支持自定义颜色（限定调色板）、显示 toolTipText 与挂载元数据（properties）。
• measure 可作详细事件描述和元数据列举（例如资源加载性能拆解）。
• 所有扩展项 (color、tooltipText、properties) 均适用于 mark 与 measure，但 measure 的实用性更强。

5. track 与 trackGroup 的组织能力
• 支持创建自定义 track（如 CSS、JS、API）以区分不同事件流。
• 支持 trackGroup，将多个 track 归为一个分组（例如 First Party < CSS、JS>），适合团队协作及区分自有与第三方数据流。
• 实现方式简便，极大提升了跨团队、模块性能整理与溯源的效率。

6. 实践建议与最佳实践
• 推荐从最小实现用法入手，不建议对 mark 过度扩展。
• 优先使用 measure 进行自定义 track/trackGroup 的组织管理。
• 针对第三方库或框架，鼓励将自有 Instrumentation 移入单独 trackGroup，以提升定位和用例分析效率。

7. 附录：实用代码示例
• 提供结合 Resource Timing API 的实践 demo，展示如何自动获取和展示资源性能细节。

Csswizardry

Making Sense of the Performance Extensibility API – CSS Wizardry

Making sense—and use!—of the new Performance Extensibility API in Chrome DevTools.

AI 摘要：本文深入探讨了 React 的 useCallback（及部分 useMemo）在许多开发实践中被滥用、实际无效甚至带来额外复杂性的现象。作者指出，只有在需要“引用稳定性”（referential stability）时才有必要使用 memoization（记忆化），但多数情况下由于组件、props 或 state 的传递与依赖管理不当，memoization 实际无法带来性能提升，甚至反而让代码维护变得困难。作者以真实项目为例，分析了 memoization 的链式依赖是如何轻易被打破，进而推荐采用最新引用（Latest Ref Pattern）和即将推出的 useEffectEvent 方案来简化副作用依赖管理。

1. 记忆化的真正动机
• 只有两大理由：性能优化、降低副作用（effect）频繁触发。
• 核心是保持“引用稳定性”，以防止不必要的重新渲染或副作用。

2. 错误/无用的 useCallback 场景分析
• 如果目标组件本身未被 React.memo 包裹，useCallback/useMemo 完全无效。
• 组件自身如果不关心 props 的引用稳定性，多余的 memoization 没有任何作用，例如原生 button 的事件处理。
• 不应将传入的非原始 props 用作内部依赖（dependency array），因为无法控制其稳定性。

3. 真实工作中链式 memoization 失效的例子
• 多层 useMemo/useCallback、props 层层传递，一旦其中任意一环未 memoize，所有下游优化失效。
• 该问题不仅无法通过“层层 memoize”彻底修复，反而增加了理解和维护的负担，导致开发者难以溯源、清理无用优化。

4. 新的依赖管理模式推荐
• 最新引用（Latest Ref Pattern）：通过 useRef 保存当前最新值，通过 effect 始终同步，无需被动依赖。
• useEffectEvent（即将推出的 React 原生特性）：可直接在副作用 effect 内安全访问最新 props/state，无需显性依赖。

5. 结论与建议
• 仅在确有必要的场景使用 useCallback/useMemo，切勿滥用。
• 优先采用更健壮的依赖管理模式，减少人为记忆化的复杂性，提升组件可维护性和开发体验。

tkdodo.eu

The Useless useCallback

Why most memoization is downright useless...

AI 摘要：本文通过作者在调试 JavaScript 代码时遇到的一个由分号 (semicolon) 缺失引发的 TypeError: console.log(...) is not a function 问题，强调了分号在 JS 语法中的关键作用。作者通过简短实例和社区讨论，剖析了分号自动插入机制导致的意外行为，并分享了这一微小失误引发长时间调试的经历，提醒开发者关注代码细节。

1. 问题背景与经历
• 作者在调试时随意插入了 console.log('here') 语句并未加分号，位置恰好出现在 IIFE（立即执行函数）之前。
• 缺少分号导致 JavaScript 引擎将后续的 function 代码当作 console.log 的参数，最终抛出 TypeError。

2. 原因分析
• StackOverflow 社区成员 Sebastian Simon 解释了该错误机制：没有分号时，代码被解析为 console.log()(function(){})，而 console.log() 的返回值是 undefined，无法作为函数调用。
• 提供了最小可复现实例代码来说明问题本质。

3. 社区互动与反思
• 在 Mastodon 社区，Andre 提醒作者 Chris Coyier 的 Web Development Merit Badges（网页开发徽章）。
• 作者幽默地调侃自己，为“因为一个字符小失误花了一小时调试”自豪地领取了徽章，凸显开发中对细节的重视与共鸣。

Tomayac

What a diff'rence a semicolon makes

The personal blog of Thomas Steiner

AI 摘要：本文系统梳理了独立开发者在 Web 全栈开发过程中，如何以低成本（穷鬼套餐）快速启动和迭代产品。作者结合自身实战，详细分析了主流的技术栈（以 Next.js 为核心）、多种低成本云部署模式（如免费云平台、全栈 Cloudflare、自托管等），以及项目启动常见成本项（域名、邮件、支付等）的选择建议，旨在帮助新手独立开发者找到成本控制与效率兼顾、专注产品本身的最佳路径。

1. 最新技术栈的选择
• 推荐 Next.js 作为首选全栈开发框架，因其生态活跃、文档齐全、AI 代码生成友好。
• 详细列举配套库与工具（如 Drizzle ORM、Better Auth、Stripe、React Email、Tailwind CSS 等），并说明每类工具的优点与适用场景。
• 解释选择原则，强调“三方依赖的通用性”及“易于在不同平台部署”。

2. 明确你的需求和成本
• 强调“盈利/准备盈利”型项目需严肃对待成本预算。
• 简述独立开发三种低成本路径：A. 利用云平台免费额度（如 Supabase/Neon/Vercel 等），B. 全部服务基于 Cloudflare，C. 自托管（廉价 VPS + 开源 PaaS 平台）。
• 分析各模式优劣：云平台部署简单、运维压力小但成本不稳定；Cloudflare 适合高流量/无收入阶段；自托管自由度高但需解决运维/安全等问题。

3. 云平台方式
• 细分为“入门级完全免费组合”“面向小商业的稳定运营组合”，逐项对比主流云平台（Vercel、Railway、Fly.io）、数据库（Supabase、Neon、Upstash）、对象存储（Cloudflare R2）、邮件服务（Resend）等的免费额度与核心优缺点。
• 强调高流量/免费额度耗尽时，成本可能快速上涨，需要有盈利模式支撑。
• 建议新手优先选择云服务，节约运维精力，把重心放在产品与营销上。

4. 完全利用 Cloudflare 平台
• 总结 Cloudflare 作为一体化服务平台的优势（免费 CDN、极低成本、服务丰富），适用于“愿意折腾”及“高流量低收入”独立开发者。
• 介绍 Workers 计算、D1 数据库、KV 存储、R2 对象存储等服务的免费额度及场景限制。
• 结合实际项目案例，说明小型/海外流量项目长期运行的可行性。

5. 自托管部署
• 分析自托管的技术栈组合、支持工具（如 Dokploy、Coolify、Uptime Kuma、Umami、Unsend、n8n等），一并覆盖数据分析、监控、邮件、数据库等服务。
• 优点：极致成本控制与可控性，缺点：需自担安全、备份、扩容及持续运维压力。

6. 其它成本项
• 域名：推荐优先在 Cloudflare 购买，兼顾成本、速度、稳定性。
• 邮件服务：若依赖登录/营销可选择 Resend、plunk 或自托管方案（Unsend+AWS SES等）。
• 支付平台：建议优先 Stripe/Paddle，初期可探索 Creem.io 等新平台并分享认证/提现实战经验。

7. 最后
• 提醒“穷鬼套餐不等于无止境折腾”，独立开发应聚焦产品与市场验证，合理分配时间资源。
• 强推 NextDevKit 作为一键多平台部署利器，降低初学者技术门槛。
• 鼓励读者分享各自技术栈与实践经验，集思广益，持续优化开发与部署流程。

Guangzhengli

独立开发穷鬼套餐(Web实践篇)

AI 摘要：本文介绍了当前 CSS 渐进网格布局（Masonry Layout）的浏览器支持现状及其多种语法方案，并提出了一种通过简洁 JavaScript 实现兼容所有主流浏览器的马赛克布局方法。作者详细解释了实现原理、兼容图片和响应式布局的技巧，同时分享了相关工具库的使用方法，为 CSS Grid 用户提供了生产可用、灵活可控的 masonry 解决方案。

1. CSS Masonry 布局的社区动态与支持现状
• Masonry 布局的引入持续讨论中，语法有三种主要提案：display: masonry、grid-template-rows: masonry、item-pack: collapse
• 当前未达成统一标准，不同浏览器支持程度不一（如 Firefox、Chrome 正在分别测试不同语法）
2. JS Polyfill 实现 Masonry 兼容性
• 介绍如何检测浏览器是否原生支持 grid-template-rows: masonry
• 若未支持，则使用 Polyfill 方案，纯 JavaScript 实现 Masonry 效果（仅需约 66 行代码）
3. Masonry 实现原理详解
• 利用 CSS Grid 的特性，将 grid-auto-rows 设为 0，row-gap 设为 1px
• 通过 JS 获取每个网格项实际高度后，调整 grid-row-end，实现项自适应高度并“堆叠”
• 恢复正确的行间隔后，布局完成，兼容性强
4. 对图片和媒体的兼容处理
• 首次渲染时图片未加载完成会导致布局错乱，需监听图片/视频加载后再计算布局
• 提供相关 JS 辅助函数，确保所有媒体加载完毕再执行布局函数
5. 响应式自适配
• 使用 ResizeObserver 监听容器宽度变化，实现自适应响应式布局
6. 工具库与复用建议
• 推荐使用作者开源的 Splendid Labz 库快速集成 Masonry 布局及更多布局工具
• 提供 npm、CSS、JS 完整使用示例

CSS-Tricks

Making a Masonry Layout That Works Today | CSS-Tricks

I went on to figure out how make masonry work today with other browsers. I'm happy to report I've found a way — and, bonus! — that support can be provided with only 66 lines of JavaScript.

AI 摘要：过去十年，JavaScript（简称 JS）运行时（JavaScript Runtime）经历了爆炸性增长，跨越云、边缘（Eadge）、微控制器、智能电视、移动/桌面原生应用（Native App）等众多环境。随着 Node.js、Deno、Bun、Cloudflare Workers、Hermes、QuickJS 等不同引擎和运行时的出现，JS 开发者获得了前所未有的选择自由。文章系统梳理了驱动 JS 运行时百花齐放的原因：硬件性能多样化、任务场景多元化、与原生 API 的融合需求以及跨平台/多语言互操作等。最终结论是：没有哪一个 JS 运行时能“一统天下”，不同场景必然产生不同最优解，也促成了生态繁荣与技术创新的持续推进。

1. JavaScript 运行时的多样化浪潮
• 过去十年 JS 运行时和引擎在数量和类型上激增，支持从云、大型服务器到边缘、物联网和嵌入式设备。
• 没有单一运行时能覆盖所有场景，各种任务对性能、包体体积、API 支持等需求差异巨大。

2. 边缘计算（Edge Computing）和“无服务器”
• JavaScript 在边缘的脚步：先由 Node.js 在 AWS Lambda 支持，继而 Cloudflare Workers、Deno Deploy、Bun 等新锐项目快速跟进。
• 各家采用不同 JS 引擎：V8（Node.js、Cloudflare）、JavaScriptCore（Bun）、SpiderMonkey/WinterJS，QuickJS（LLRT）等，厂商和开发者根据实际需求选择最优方案。
• 行业逐步形成新的标准组织，如 WinterCG 推动运行时 API 一致性。

3. 微控制器与极小型设备
• 资源受限场景驱动极致“瘦身”引擎（如 Duktape、JerryScript、Espruino、mjs、Moddable、Elk）。
• 推动对应微型 runtime 出现（IoT.js、Microlattice.js、low.js）使 JS 覆盖从命令行到“3 分钱”MCU 芯片。
• 跨语言调用与嵌入需求促进微型 JS 引擎/运行时出现。

4. 多语言互操作（Polyglot engines）
• 不同语言实现 JS 引擎，促进零成本语言互调。显著例子有 Rhino/Nashorn/Graal.js（Java/JVM）、jint（.NET/C#）、langjs/pyNarcissus（Python）、Boa/rquickjs（Rust）、Kiesel（Zig）等。
• 甚至有用 JS 编写 JS 引擎的项目（如 Narcissus、Porffor、Shadow），展现 JS 生态和语言本身的强大适应性。
• 多数主流 polyglot 项目追求互操作性和练手，更极大丰富了 JS 生态。

5. 原生应用开发与 JS 运行时
• Web View 类应用：Cordova/PhoneGap、Ionic/Capacitor（移动端）、Electron、NW.js（桌面）、Smart TV 平台广泛采用 webview+JS runtime 构建跨平台 GUI。
• React Native 体系：通过 JS runtime+bridge 机制渲染原生组件，最早依赖 JavaScriptCore，后主推 Hermes，还支持 V8/QuickJS/Chakra 等多引擎适配；已成为移动端主流，正在攻入桌面和智能电视。
• NativeScript：深度绑定原生 API，早期支持多引擎（JSC/V8），后统一到 V8；近期演化为 Node-API 驱动，以便灵活适配各主流 JS 引擎。
• Node.js 在原生开发中的特殊地位：广泛用于 CLI 服务和桌面集成，但在 GUI、移动原生方面更显边缘，行业也频繁尝试 V8/ChakraCore/JerryScript 等不同引擎 port。

6. 总结与反思
• JS 凭借开放性和简洁性，成为最有适应性的面向 GUI 与原生应用开发的语言，并渗透到各类设备终端。
• 运行时选择众多，驱动力多样，硬件特性、启动时/运行时性能、bundle 大小、API 支持、native 调用等需求差异难以统一，任何“统一 JS 运行时”设想都难以落地。
• 健康竞争、百花齐放推动了巨大的技术进步，使 JS 成为未来开发“最安全”的通用技术选择之一。

7. 附录：遗漏与新兴运行时一览
• ByteDance Lynx/PrimJS、Ladybird LibWeb/LibJS、gjs（SpiderMonkey/ GNOME）、MuJS、JXA（macOS automation）、dukluv/txiki.js、Bare、lo.js 等新老项目列举。

Buttondown

The many, many, many JavaScript runtimes of the last decade

This last decade has seen an inundation of new JavaScript runtimes (and engines in equal measure), enabling us to run JavaScript in all manner of contexts...

AI 摘要：本文介绍了 JavaScript 的逻辑赋值运算符（logical assignment operators），即 =, &&=, ??=，这些自 ES2021 起纳入标准的新语法极大简化了条件赋值的场景。这些运算符结合原有逻辑运算与赋值，帮助开发者更安全、高效地管理状态、赋默认值并减少样板代码，同时保留了短路（short-circuit）行为。作者详细对比了它们和传统写法的区别，以及在实际开发中的注意事项和最佳应用场景。

1. 逻辑赋值运算符基础
• 逻辑赋值运算符通过将逻辑运算符（||、&&、??）与赋值操作（=）结合，形成简写形式。
• 这些运算符延续了短路运算特性，仅在需要时才计算右侧表达式，提高性能并避免副作用。
• 非常适合简化日常中对变量赋默认值、状态更新的代码书写。

2. 三种主要运算及应用场景
• 逻辑或赋值（=）：当左侧为假值（falsy）时赋值，用于没有初始化或需要提供默认值的场景，但会覆盖如 0、''、false 这类本应保留的有效值。
• 逻辑与赋值（&&=）：当左侧为真值（truthy）时赋值，适合在当前条件满足基础上再作更新，注意右侧结果直接替换原值，可能变为假值。
• 空值合并赋值（??=）：仅在左侧为 null 或 undefined 时赋值，更安全地保持如 0、''、false 这类需要保留的有效值，适用于需严格区分“未赋值”与“有效但为假”的情况。

3. 使用场景与注意事项
• 组件属性默认值（如 React 的 props）：props.showHelpText ??= true;
• 全局状态或配置默认值：config.apiBase = '/api/v1';
• 数据清洗和表单处理：formData.username &&= formData.username.trim();
• 应避免使用可覆盖有效“假值”的 =，遇到需特殊区分空值的情况优先采用 ??=。
• 运算符左侧不能使用可选链（optional chaining），否则会抛出语法错误。
• 短路特性可避免无谓计算（如 API 密钥获取只在必要时执行）。

4. 浏览器与环境兼容性
• 支持：Chrome 85+、Firefox 79+、Safari 14+、Edge 85+、Node.js 15+
• 不支持：Internet Explorer
• 老旧环境可通过 @babel/preset-env（ES2021 配置）进行转译支持。

5. 实际意义与开发建议
• 逻辑赋值运算符虽然是小语法，但对代码可读性、简洁性以及防止常见赋值错误都极有帮助。
• 尤其适合前端组件状态管理、API 参数默认化、表单数据标准化等场景。
• 现已广泛兼容，开发者只需简单迁移习惯即可高效使用。

AI 摘要：本文深入探讨了在大型 TypeScript 项目、尤其是多团队、多仓库（polyrepo）架构下，如何在服务边界之间实现类型安全。作者通过剖析现有单仓库（monorepo）与多仓库在类型共享上的差异，提出了一套自动化提取、打包、共享和验证 TypeScript 类型定义的新思路，从而实现跨服务间类型兼容性检测，最大限度利用 TypeScript 本身的类型系统能力，实现 monorepo 式的类型安全体验。

1. TypeScript 项目架构对类型共享的影响
• 对比单仓库（monorepo）与多仓库（polyrepo）架构下服务间类型共享的简易性和复杂性
• 强调 monorepo 在类型共享上的先天优势，但多仓库在业务组织上的必要性

2. 跨仓库类型校验的实际挑战
• TypeScript 类型检查器需要获取完整工程上下文，但多仓库使类型定义分散
• 讨论依赖和类型递归拉取带来的复杂性，不同仓库可能存在同名、类似或依赖链深度不一的类型

3. 类型提取、打包和自动化流程
• 利用 ts-morph、SWC 等工具自动化精准地提取、分发类型定义
• 提出基于接口路由自动生成类型别名，解决多团队协作下类型命名不一致问题
• 持续集成（CI）流水线以独立项目方式聚合、校验和比对类型包，提高自动化校验覆盖面和准确率

4. 类型兼容与校验自动化策略
• 利用 TypeScript 类型赋值（assignability）规则进行自动验真，无需自定义冗余逻辑
• 构建临时 TypeScript 项目，自动加载各仓库导出的类型包，通过编译器 API 比对并提取错误
• 充分借力 TypeScript 编译器本身能力，让生态演进自然受益

5. 工程实践与系统扩展性
• 跨仓库类型校验架构具备良好的可扩展性和维护性
• 所有工程增强无需魔改 TypeScript，可高效适配未来升级

www.carrick.tools

The Multi-Repository TypeScript Problem

Navigating Type Safety Across Service Boundaries

AI 摘要：本文批判性地回顾了 HTTP 多个版本发展之后，Web 表单（forms）在处理和数据编码方式上依旧混乱与落后。作者剖析了现有的两种表单数据编码方式（application/x-www-form-urlencoded 和 multipart/form-data）存在哪些规范不统一、实现分歧和技术缺陷，以及标准缺失导致开发体验极差；尽管 HTTP 协议多次进化，表单数据交互方式却数十年未有本质改进。文章最后指出，业界对更优的数据编码格式需求迫切，当前的局面已难以令人满意。

1. HTTP 1.1 及标准库开发的挑战
• HTTP 1.1 并非设计良好，RFCs 更像现状描述参考而非真正规范文档
• 实现 HTTP 协议过程中遇到种种格式和约定的古怪乃至异常细节，增加开发复杂度
• 常见如 chunked transfers 的十六进制长度、状态行中的强制空格等非直观规则

2. 表单数据编码现状与问题
• application/x-www-form-urlencoded
• 历史悠久但缺乏清晰权威的完整规范，依赖 URI 查询参数语法（RFC 3986）
• 编码方式不唯一：对于特殊字符、非 ASCII 字符及数组字段，各实现可能不同
• 对文件与大体量（非 ASCII）数据极为低效（尺寸膨胀、难处理），仅适合简单字段
• 标准文件来源分散且部分已废弃（如 RFC 1866）
• multipart/form-data
• 基于 MIME，规范为 RFC 7578
• 通过分隔符（boundary）串联各部分；分隔符任意但需保证不与正文冲突，增加复杂度
• 无内容长度（Content-Length）头，需流式查找分界符，解析困难导致代码容易出错
• 各字段内容 Content-Type 可以随意宣称，可信度低
• 同样缺乏对数组、对象等复杂数据结构的直接支持，序列化无统一方案
• 不适合前端与后端所有技术栈无缝协作，且导致报文冗余、解析低效

3. 表单标准规范缺失与业界影响
• RFC 文档对主流表单格式覆盖不全，甚至可实现 HTTP 服务器时完全不支持表单却依旧合规
• 主流浏览器始终只支持上面两种，阻碍更现代、结构化的数据格式如 JSON 的广泛采用
• 早年曾有 JSON、XForms 作为新方案提出，但均未流行或长远落地

4. 现实与展望
• 浏览器与后端互操作受限，文件与字段混合上传尤为无解
• 新协议如 tus，仅可用于纯文件上传场景；JSON 提案因多方面原因未标准化
• 表单机制停滞，严重滞后于网络协议和数据交换发展的需求

AI 摘要：本文深入分析了 WebAssembly（WASM）与 Web 平台集成特别是直接访问 DOM（文档对象模型）的现状和未来可能性。作者强调，Wasm 自身并没有也可能不会获得直接 DOM 支持，但它自诞生以来就通过需要适量 JavaScript glue code（粘合代码）间接地实现了对 DOM 及其他 Web API 的访问。通过工具链和标准的持续推进，Wasm 集成会更加高效，但对纯“Wasm 直接操作 DOM”并无迫切需求或业界共识。开发重点应聚焦于优化性能和开发体验，而不是消除一切 JavaScript，Wasm 与 JavaScript 的共存将长期持续。