如果你是一个前端开发者，今年的技术选型越来越让人头疼——我懂。
React 的 RSC、Next.js 的 App Router、Vue 的 Vapor Mode……每个框架都在往上堆东西。打开一个新项目，先把 webpack/vite/turbopack 的配置折腾一遍，然后对着几千个 node_modules 发呆。
另一边，一股相反的潮流正在悄悄壮大。
Astro 的 GitHub Star 数已经超过 Next.js。htmx 的增速碾压了 React 和 Svelte。而 Web Components——被喊了好多年”要火”的技术——终于在 今年找到了自己的生态位：Lit + Tailwind + Vite 的组合可以支撑生产级应用了。
这三个被戏称为”前端轻量化三剑客”的技术，正在把”更少的 JS”从口号变成工程实践。
本文从实际选型切入，看它们各自解决什么问题，什么时候值得用。
为什么”少写 JS”突然又流行了？
先聊背景。
过去十年，前端开发几乎等于 JavaScript 开发。SPA 时代把 JS 从”脚本语言”变成了”整个应用的底座”——HTML 和 CSS 经常由 JS 生成、被 JS 操作、甚至被 JSX 取代。
我们告诉自己这是在进步。React 和 Vue 的组件模型确实比 jQuery 时代强太多了。但走过头了。
没 JS 页面就白屏。水合完成前用户对着空白 loading 发呆。一个简单博客背后是几十个 npm 依赖。爬虫抓不到内容，屏幕阅读器读不了，网络差的时候整个网站直接废掉。
InfoQ 上有篇文章说得挺好：”开发者变成了运维工程师——管理构建管道、webpack 配置、打包工具、Tree Shaking 和水合策略。”说白了，各种原本为了解决问题而生的工具，反过来成了制造复杂度的来源。
所以”少写 JS”不是怀旧复古，而是一次理性的校正。
Astro：默认零 JS 的静态站点生成器
Astro 是 2025 年增长最快的 Web 框架之一。核心理念很简单：默认输出零 JS 的纯静态 HTML，只在需要交互的地方按需引入。
什么意思？你写一个 Astro 页面，默认就是一坨干净的 HTML + CSS。如果某个组件需要交互，标一个 `client:load`，Astro 会把它单独打包成 JS，只在浏览器端激活。其他部分仍然是纯静态的。
这就是”岛屿架构”（Islands Architecture）——页面上大部分是静态的”海洋”，只有个别交互组件是动态的”岛屿”。
对比一下传统思路：
– 用 Next.js 写博客：整个页面是 React 组件，需要服务端渲染 + 客户端水合。即使页面上只有一个搜索框需要交互，整个 React runtime 也得打包丢给浏览器。
– 用 Astro 写同样的博客：99% 的内容是纯 HTML，只有搜索框那个组件才加载 React。
内容型站点用 Astro 太划算了。
Astro 不绑定任何 UI 框架。你可以在它里面写 Vue、Svelte、React，甚至 Lit 的 Web Components——都支持。它是真正意义上的”框架无关”。
适合场景
内容型网站、博客、文档站、营销页面、电商产品页。你在犹豫用 Next.js 还是 Astro？一个简单的判断标准：如果 80% 以上页面是静态内容，选 Astro。
接入成本
你不需要学一套新语法。Astro 的模板语法非常接近 HTML，`.astro` 文件看起来就是在 HTML 里加了 `—` 分隔的服务端脚本部分。有 React/Vue 基础的话，上手就半小时。
htmx：用 HTML 属性搞定 AJAX
它可能是今年争议最大但也涨得最快的库。
基数小是一方面，但这个增速说明一件事：开发者对”为了一个点击事件装整个 React”这件事烦透了。
它的理念叫”超文本驱动开发”——在 HTML 标签上加属性，就能实现 AJAX 请求、表单提交、实时更新，甚至 WebSocket 通信。
一个搜索框实时查询的例子：
<p>
<input type="text" name="q" hx-get="/search" hx-trigger="keyup changed delay:500ms" hx-target="#results" placeholder="搜索..."></p>
<div id="results"></div>就这几行属性，用户在输入框打字 500ms 后自动发 GET 请求到 `/search`，返回的 HTML 片段塞进 `#results`。不需要写一行 JS。
后端返回 HTML 片段，不是 JSON。这意味着你的后端框架（Django、Laravel、Rails、Spring Boot）可以直接渲染模板返回，前端不用再写一套 API 处理逻辑。
适合什么
– 后端主导的项目：后端工程师想给页面加点交互，又不想碰 React/Vue
– 内部工具和后台管理系统：不需要复杂的客户端状态管理
– 渐进式增强：给现有服务端渲染页面加点动态能力
什么时候别用
– 需要复杂客户端状态管理的场景（在线表格编辑器、设计工具）
– 交互要求极高（拖拽排序、实时协作编辑）
htmx 官网有一篇自嘲文章叫《htmx sucks》，里面承认得很诚实：它不是万能的，但能解决 80% 的日常交互需求，剩下 20% 交给 JS 框架。这个定位很清醒。
Web Components：终于找到了正确用法
它被吐槽了很多年——API 太底层、模板语法难用、Shadow DOM 跟框架生态不兼容。这些吐槽大部分都对。
但今年情况变了。两个关键变化。
第一，Lit 让它变得好用了。
Lit 是 Google 维护的 Web Components 库，把底层的 custom elements 和 shadow DOM 封装成一套清晰的 API：
import { LitElement, html, css } from 'lit';
import { customElement, property } from 'lit/decorators.js';
@customElement('my-button')
export class MyButton extends LitElement {
@property({ type: String }) label = 'click me';
render() {
return html`<button>${this.label}</button>`;
}
}然后你可以在任何框架（React、Vue、Angular、Astro）里用 `
第二，Tailwind + Vite + TypeScript 补齐了工程化体验。
早期 Web Components 开发体验很原始，但现在用 Lit + Tailwind + Vite + TypeScript，开发体验已经不输 React。配合 Suunta 之类的路由状态管理库，甚至能做完整的 SPA。
我的判断是：Web Components 最适合做跨框架共享的 UI 组件库。如果你在维护一个同时用了 React 和 Vue 的项目，或者在做设计系统，它是天然的选择，因为它跟框架无关。
但如果你项目已经用了 React 或 Vue，没有跨框架需求，那就用自己框架的组件系统——没必要为了用而用。
三剑客怎么组合用？
这三者不是二选一的关系，而是互补：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 内容型网站 | Astro + 少量 Lit 组件 | Astro 默认零 JS，Lit 处理交互部分 |
| 后台管理系统 | htmx + 服务端框架 | 快速出活，前端代码量极少 |
| 跨框架 UI 库 | Web Components (Lit) | 真正的框架无关，一次开发随处用 |
| 混合型应用 | Astro + htmx + Lit | Astro 做整体架构，htmx 处理动态交互，Lit 封装 UI 组件 |
一个实际的工作流：整个站点用 Astro 搭建，大部分内容是纯 HTML + CSS。服务端交互的部分（搜索、表单、翻页）用 htmx。可复用的 UI 组件（按钮、弹窗、表格）用 Lit 写 Web Components。
这样你写的大部分代码是 HTML 和 CSS，JS 只在确实需要的地方出现。项目跑起来又快又稳。
值得现在入坑吗？
答案是分情况。
如果你在做内容型项目（博客、文档、企业站、个人主页），Astro 值得马上用——比 Next.js 简单太多，性能也好得多。
如果你主要写后端（Python/Django、PHP/Laravel、Ruby on Rails），htmx 能让你在基本不碰 JS 的情况下做出不错的交互体验。花一个周末试试不亏。
如果你在维护跨框架组件库或设计系统，Lit是唯一正确的方向。别再给 React 和 Vue 各写一套了。
但你在做一个重度交互的客户端应用（在线 IDE、设计工具、实时协作平台），那还是继续用 React 或 Vue，它们在这方面依然是最优选。轻量化不是银弹。
写在最后
前端技术这几年越走越复杂，但后来发现：用户不在乎你的技术栈是不是前沿，他们在乎的是页面加载快不快、交互流不流畅。
“轻量化三剑客”的崛起，本质是对”过度 JavaScript”的一次集体反思。不是要回到纯静态网站，而是让 JS 回归它本来的角色——在真正需要增强体验的地方出手，而不是成为体验的负担。
这不是倒退。是前端终于学会对自己的冲动说不了。
如果你还没接触过这三者，从 Astro 开始——体验一下”默认零 JS”的爽感，你会对前端性能有全新的认识。
📖 推荐阅读
这些也是跟前端工程师有关的文章，你可能会感兴趣：
React Compiler 1.0 来了：以后useMemo 和 useCallback 可以删了？