428 分、145 条评论。这个数字在 Hacker News 首页停留了一整天。
一个让按钮「抖起来」的 UI 库，为什么会引发如此激烈的讨论？支持者看到了触觉反馈的未来，反对者看到了无谓的 CPU 浪费，而技术评论者则把目光投向了代码注释的风格——这些注释看起来像 AI 写的。
Jelly UI 的创造者 baldvinmar 说：「有时候我们做东西只是为了纯粹的快乐。实用是 bonus。」
什么是 Jelly UI
Jelly UI 是一个零运行时依赖的 Web Components 库，提供了约 40 个自定义元素。它的核心卖点：原生的 HTML 表单控件——包括按钮、输入框、复选框、滑动条、选择器——都获得了软体物理（soft-body physics）表面，每次点击、切换和拖拽都会伴随着果冻般的抖动。
从技术指标上看：
- 零第三方依赖
- 单
<script>标签引入 - 支持
WCAG AA色板（亮色和暗色模式均通过验证） - 内置暗色模式和
RTL布局 - 所有表单控件通过
ElementInternals参与原生FormData
它的 GitHub 仓库（jelly-org/ui）使用 strict TypeScript 编写，用 Vite 打包成单个 ESM 文件，配合 Playwright 做真实浏览器测试。代码质量方面，LICENSE 是 MIT，项目仅有 4 个 commit，Stars 72 个，Fork 2 个——这更像是一个个人项目，而非大型团队的产物。
软体物理在浏览器中如何运作
如果你在 Chrome 的开发者工具中查看性能面板，会发现一个持续的 requestAnimationFrame 循环在每隔 8-11ms 运行一次。这就是 Jelly UI 的核心引擎。
从源码（src/core/engine.ts）看，Jelly UI 实现了一个名为 JellyEngine 的单例类。它维护一个 Set<JellyComponent>，记录所有当前活跃的组件。引擎的关键循环如下：
loop (now: number): void {
const dt = clamp((now - this.lastTime) / 1000, 0, 0.033);
for (const component of this.active) {
keep = component.frame(dt);
if (!keep && !component.colorEasing) {
this.active.delete(component);
}
}
if (this.active.size > 0) {
requestAnimationFrame(this.loop);
} else {
this.running = false;
}
}delta 被限制在 0.033 秒（约 30fps）以内，以防止后台标签页恢复后产生「时间跳跃」。每个 canvas 驱动的组件拥有一个 JellyBody 实例——一个闭合的弹簧耦合膜点环，围绕圆角矩形排列，具有基于压力的体积保持、指针跟随的按压目标、倾斜和透视效果。
物理模拟使用的是显式欧拉积分（explicit Euler integration），但通过子步进（substepping）来保持稳定性。MAX_STEP 设为 1/58 秒，确保即使帧率波动，模拟也不会注入额外能量。
当所有组件都报告「静止」后，引擎会自动暂停 RAF 循环，闲置时不消耗 CPU。这是一个重要的设计决策，也成了后续性能争论的焦点。
性能争议：3ms 的「空闲」重绘
Hacker News 上最激烈的争论围绕性能展开。用户 jlukic（另一个知名 UI 框架的作者）发布了自己的性能分析结果：
「光标静止，视口停在按钮示例上。每 8-11ms 发生一次 3ms 的重绘。动画帧指向了我提到的代码。」
jlukic 进一步解释了他的担忧：「如果一个空闲任务持续占据帧预算的很大一部分，那么在点击、滚动、浏览时很容易出现帧丢失。」
另一位用户 wbobeirne 则提出了不同看法：「在 Chrome 中运行性能分析并不支持这个结论。这个循环维护了一个活跃的 Set<JellyComponent>，在组件停止运动时将其清除。当没有动画发生时，核心循环的耗时以微秒计。」
Rohansi 补充了一个重要发现：性能问题的主要源头可能包括页面头部和底部的 Lottie 动画带来的额外开销。删掉 section.hero 后，CPU 使用率从约 35% 降到了 6.6%。
这场争论揭示了一个边界条件：Jelly UI 本身的物理引擎在空闲时确实会暂停，但演示页面上的装饰性动画（Lottie）产生了额外的性能开销。当批评者和辩护者测试的是不同页面元素时，得出截然不同的结论也就不奇怪了。
AI 生成代码之争
一个耐人寻味的副线是代码注释风格的讨论。jlukic 在最初的分析中提到：
「上面的注释看起来像是 AI 生成的：
// One shared animation frame: step every live component, park when idle.」
wbobeirne 虽然为性能辩护，但也同意「注释看起来有点 slop-ish」。bogwog 则更直接地猜测这是 AI 产物：「他们用的 AI 把它叫做 ‘physics-based’ 可能是幻觉……要么就是他们自己不懂，让 AI 做了个 ‘physics based’ 系统，AI 太 sycophantic 了没纠正他们。」
从 src/core/engine.ts 的源码来看，注释的风格确实比较「规范」——每个方法都有清晰的目的说明，变量命名也相当正式。但这本身并不构成 AI 生成的证据。一个严谨的开发者完全可能写出类似的注释。
这个问题触及了 2026 年前端社区的一个敏感神经：当 AI 代码生成变得普遍，什么样的代码才算是「人工编写的」？如果一个库的功能是正确的、性能是可接受的，注释风格的「AI 感」是否真的重要？
UX 创新还是花哨噱头
这是 HN 讨论中最两极分化的问题。
支持者认为，触觉反馈填补了原生控件的一个空白。blauditore 说：「我喜欢它通过动画反馈来强调正在发生的变化。原生控件在这方面做得并不好。动画不只是装饰性的，它们有真实的 UX 价值（当然，前提是用对了）。」
red_hare 提出了一个折中观点：「使用这类库的关键是不要全面铺开。把效果应用到每个元素上会显得俗气。但如果只用在单个点赞按钮、效果滑动条或神奇搜索框上，那会是一种可爱的点缀。」
反对者的感受同样强烈。snitty 批评了交互的不一致性：「一个按钮不应该根据你点击的位置而表现出不同的形变。……点击拖拽一个按钮，形状不变。点击拖拽一个开关，形变跟随鼠标。仅仅点击开关，形变又不跟随那个小圆形了。」
altairprime 的表述更为直接：「Ew ew ew 对开关控件的恐怖谷反应。我都没往下翻页。」他还从能耗角度提出了更大的质疑：「没有任何视觉进步值得用持续不断的 JavaScript 重绘来换取。」
petilon 的建议则相对温和：「效果很酷，但过头了，容易分散注意力。微妙的动效可以增强可用性，但应该几乎察觉不到才对。」
可访问性与生产就绪度
Jelly UI 宣称遵守 WCAG AA 标准，也确实实现了几个关键的可访问性特性：
- 所有颜色 token 在亮色和暗色模式下均通过
WCAG AA对比度验证 - 对
prefers-reduced-motion有完整的降级支持——当用户开启系统级减少动效时，物理模拟完全绕过脉冲生成，控件变为静态 - 使用
ElementInternals让表单控件参与原生FormData - 支持
forced-colors高对比度模式
不过，prefers-reduced-motion 的支持也引发了一个尴尬的副作用：许多用户根本不知道自己开启了这个设置（macOS 的「减少动效」选项位于「辅助功能 → 显示」下），导致他们访问演示页面时完全看不到任何物理效果，困惑地认为页面出了问题。
作者 baldvinmar 在收到反馈后，在页面上添加了一个小兔子图标，允许用户点击来覆盖系统设置。
rickydroll 提出了一个有趣的应用场景：「这个可以改进后对手部控制能力较差的人非常有用。我缺乏精细的运动控制能力，点击现代那些微小的目标通常需要在目标周围点好几次……如果目标能改变形状来提高瞄准能力或增大点击区域，那就太好了。」不过这个观点尚未被作者采纳或验证。
何时使用，何时避免
综合 HN 讨论和实际测试，以下场景可能适合 Jelly UI：
- 游戏化界面：面向儿童的网站、游戏内的 UI、娱乐性应用
- 关键交互的强调：在大量普通控件中突出某个特定操作（比如「点赞」按钮）
- 品牌差异化：需要营造柔软、亲切品牌感的产品
以下场景建议谨慎：
- 数据密集型应用：仪表盘、表格、管理后台
- 高频操作界面：需要快速连续点击的工具
- 低端设备：移动端或旧设备上的页面
- 需要严格一致性：控件行为必须可预测的支付、医疗等场景
结语
Jelly UI 的价值不在于它是否「革命性」——它并不是。物理模拟 UI 从 Compiz 的抖动窗口到 Apple 的 Liquid Glass，已经以各种形式存在了近二十年。Jelly UI 的真正贡献在于：它把软体物理封装成了标准的 Web Components，任何框架的用户都能通过一个 script 标签来使用。
它的争议也折射出 2026 年前端开发的深层焦虑。当 AI 工具可以批量生成 UI 组件，当性能优化和用户体验之间的平衡越来越微妙，开发者需要同时面对代码质量、感知性能、可访问性和审美品位的多重审视。
Jelly UI 在 HN 上获得的 428 分，与其说是对技术方案的认可，不如说是社区对这个议题本身的投票——我们到底想要什么样的界面？是精准、高效、不打扰的「工具」，还是柔软、有趣、偶尔任性的「玩具」？
答案或许因人而异，也可能因场景而异。
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
参考链接
- Jelly UI 官方文档和交互演示
- Hacker News 社区讨论帖（428 分，145 条评论）
- Jelly UI GitHub 仓库源码
