前端周刊

💬 推荐语 本期关键词是“原生能力回归 + 架构复杂度再评估”。一方面，popover、dialog、Anchor Positioning、backdrop-filter、外部 import maps

过去几年，低代码工具几乎成了企业数字化里的“标配”。从表单搭建到活动页面，从运营后台到数据看板，各类拖拽工具层出不穷。但很多前端开发者用过几次之后都会产生一种微妙的感觉：这些工具很适合“搭页面”，却很

如果你做过企业活动页面开发，大概率会对这种场景非常熟悉：运营提出活动需求，设计师给出视觉稿，开发团队在极短时间内完成页面搭建并上线。等活动结束后，这个页面往往就被废弃

一篇实用的实战讲解：使用 React Three Fiber 和 GLSL 构建一个弯曲的 3D 商品网格，涵盖着色器、动画与性能。 作者：Matt Greenberg 分类：Tutorials 日期

Next.js 在 next 包内置了与版本精确匹配的文档，使 AI 编码代理可以引用准确、最新的 API 和实践模式。你只需在项目根目录放置一个 AGENT

如今的用户默认就期待应用“又快又顺”。性能不再只是“锦上添花”，它是真正的产品优势，会直接影响留存、转化和收入。 难点在于：排查性能问题常常让人崩溃，因为一个应用变慢的原因实在太多了。 在这份指南中，

Next.js 开箱即用，体验通常很顺手——直到流量和复杂度同时上来。本文讨论的是：在不推倒重写的前提下，如何把 Next.js 推到企业级规模，从缓存与 CDN，到横向扩容、API Gateway，

关于 TypeScript 泛型的文章有很多。本文不做基础入门，而是围绕一个真实的小问题，展示如何把泛型、条件类型和函数重载组合起来，构建一个类型完善且可维护的 API。 重点不是“类型体操”，而是在

React 非常适合构建动态交互界面，但随着应用增长，客户端渲染开销、包体积和状态管理复杂度会逐渐增加。 HTMX 提供了另一条路径：通过 HTML 属性驱动请求与局部替换，把一部分更新逻辑交还给服务

JavaScript 开发者大致可以分成两类：一类偏“随性”，一类偏“整理控”。作者说自己在现实生活里并不整洁，但写 JavaScript 时会非常在意秩序：默认使用 const、重视作用域，并希望代

每个字母单独动画的文字效果总是很酷、很吸睛。这类错峰动画通常依赖 JavaScript 库实现，对我们要实现的这种相对轻量的设计效果来说，代码往往偏重。本文将探索只用 CSS、无需 JavaScrip

说到图表……你上次使用饼图是什么时候？如果你是那些需要到处做演示的人之一，那么恭喜！你既在我个人的地狱里……也被饼图包围着。幸运的是，我想我很久没需要用过它们了，至少直到最近是这样。 去年，我自愿为墨

💬 推荐语 本期围绕“AI First 前端架构 + WebMCP 与 Agent 生态 + 大规模性能与工具演进”展开：从“纯前端开发者之死”与 AI-First 前端架构出发，讨论前端角色边界与

本期围绕“浏览器互操作标准 Interop 2026 + TypeScript 6.0 Beta + Web 与 AI/Agent 能力结合”展开：一组来自 web.dev、WebKit

Angular 的增量水合（Incremental Hydration）通过把“可见”与“可交互”的成本拆开：页面仍然用 SSR 很快渲染出完整 HTML（有利于 LCP/SEO），但把某些区域的客户

嵌入视频往往会显著拖慢页面：播放器会加载一堆额外资源，即使用户最终根本不点播放。 常见的优化是用 lite-youtube-embed 之类的轻量组件先占位、再按需加载。但如果视频就在首屏（above

过去几年里，我们经常需要用 JavaScript（滚动事件、Intersection Observer）来回答一些看似简单的问题： 这个 sticky 头部现在真的“贴住”了吗？ 这个 scroll-

本文想回答两个很直接的问题： 大型 SVG 的渲染是否显著比小 SVG 慢？有没有一个“超过就很糟糕”的尺寸阈值？ 如果把这些 SVG 转成 PNG，渲染表现会怎样？ 为此，作者生成了一批测试图片，并

WebView 桌面应用”这条路线的本质很朴素： 界面层用 HTML/CSS/JS 来获得极高的 UI 生产效率，渲染层交给系统自带的 WebView（Windows WebView2 / macOS

前端写 UI 写久了，你总会遇到一种特别别扭的视觉：内容明明只有两三行字，容器却像被“撑到一整行”那样宽，留下一大块无意义的空白。标题、标签、气泡、tooltip、legend、图片 caption…