摘要：前端开发圈子里，总有人在争论到底该不该用框架。这场关于浏览器原生能力与技术栈选择的讨论，在一次次技术大会上被反复提及。从对滚动驱动动画的深度探索，到对自动化工具与无障碍体验的反思，再到对AI与浏览器未来形态的大胆设想，这些讨论背后都指向同一个核心：当我们沉迷于用框架解决一切问题时，可能正在错过浏览器本身提供的强大能力。本文通过一次技术大会的经历，聊聊如何用CSS滚动驱动动画这类原生能力，让开发过程变得更有趣，也更高效。
被忽略的浏览器超能力
CSS滚动驱动动画（Scroll-Driven Animations）这个关键词，说的是一种让动画与页面滚动进度绑定的技术。早在2023年，浏览器就已经开始支持这个特性，但直到今天，很多人还在用复杂的JavaScript库去实现类似效果。
这就像明明家里有自来水，却偏要跑去井里打水。视图过渡API（View Transitions API）也是类似的情况，它能实现单页应用那种丝滑的页面切换效果，但很多人因为习惯了React Router之类的方案，压根没想过浏览器自己就能做到。
现场有位开发者分享了一个观点特别扎心：现在的框架就像当年网飞邮寄DVD的服务，明明可以直接在线观看，却还要把光盘寄来寄去。想想看，每次写代码都要npm install一堆依赖，最后打包出来的东西比论文还厚，但真正用到的浏览器原生能力可能还不到十分之一。
重新审视技术栈
框架依赖的悖论
在大会第一天，有个环节专门讨论了现代开发技术栈的问题。主讲人一上来就说“你们可能会恨我”，然后开始剖析大家对框架的盲目依赖。
拿React来说，它解决的是十年前浏览器能力不足时的问题。那时候组件化、状态管理、虚拟DOM都是刚需。但现在浏览器早就支持了Web Components、原生模块化、CSS自定义属性，很多东西已经不需要框架来帮我们做了。
更讽刺的是，大型语言模型（LLMs）的训练数据里充斥着大量React代码，这导致AI生成的代码示例也默认全是React写法。这就形成了一个怪圈：新人学框架是因为教程都这么写，教程这么写是因为AI训练数据里都是框架代码，而AI训练数据来自网上已有的代码，网上已有的代码又来自…这一连串下来，想跳出框架思维反而成了难事。
浏览器能力的实战检验
演示场景搭建
准备现场演示的时候，需要把一年来写过的CSS-Tricks文章内容压缩成半小时的分享。最大的挑战不是技术本身，而是怎么让观众在短短几分钟内理解那些复杂的CSS语法。
解决方案是用reveal.js来做幻灯片，它支持代码块之间的自动动画过渡。先把老旧的长篇语法展示出来，然后用动画一步步展示新语法如何替代它们。比如：
旧语法可能需要这样写：
@keyframes slide-in {
0% {
transform: translateX(-100%);
}
100% {
transform: translateX(0);
}
}
.slide-in {
animation: slide-in 1s linear;
animation-timeline: scroll();
}新语法直接简化为：
.slide-in {
animation: slide-in 1s linear, scroll();
}这中间省掉的不仅是代码量，更是理解和维护的心智负担。
互动环节的设计思路
演示过程中，设计了一个互动环节。让观众投票决定演示程序里的主角是空手迎战还是逃跑。结果现场投票五五开，这反而成了最好的效果——因为无论选哪边，都能展示滚动驱动动画的不同应用场景。
选空手迎战，主角会先被打败；选逃跑，则可以通过滚动触发新的路径，找到装备后反杀。滚动方向决定了故事走向，向左滚动是逃跑，向右滚动是战斗。这种设计把技术演示变成了一个可玩的迷你游戏，让观众在体验中理解技术原理。
从工具回归问题本身
自动化测试的盲区
无障碍测试这个话题，现场有个分享特别实在。自动化测试工具就像一把双刃剑，用得好能发现问题，用不好反而制造问题。
举个例子，一张装饰性的图片本来不应该加alt文本，但Lighthouse可能会报错说缺少替代文本。如果开发者为了通过检测随便加一段描述，反而会干扰读屏软件的正常工作。
真实用户测试的价值就在这儿。只有真正让残障人士来操作，才能发现工具检测不出来的问题。有个观点特别到位：如果AI训练数据本身就来自一个有问题的网页，那AI学出来的结果肯定也是错的。
开发者能力的本质
不管用什么工具，解决问题的核心能力永远是：关键路径分析、信息质量把控、创意实现。这些能力跟会不会写React Hooks没有半毛钱关系。
回想一下自己做项目的经历，真正让人头疼的从来不是用哪个框架，而是怎么让页面加载更快，怎么让用户更容易理解信息，怎么把设计稿完美还原。框架只是实现这些目标的工具，不是目标本身。
技术分享的实操要点
如何准备一场技术演讲
现场分享的经验可以拆解成几个步骤：
第一步，确定分享形式。文章和演讲是两种完全不同的载体，不能把文章直接念给观众听。文章可以慢慢读，可以反复看代码块，但演讲只有半小时，观众注意力有限。
第二步，建立情感连接。开场用自嘲的方式破冰，承认自己紧张，反而能拉近和观众的距离。把个人经历和专业知识结合起来，让内容更有温度。
第三步，用故事串联知识点。把CSS滚动驱动动画的技术点，包装成一个“勇者斗恶龙”的故事。每一次滚动都是剧情推进，每一个动画都是战斗招式，观众在听故事的过程中自然而然地理解了技术原理。
第四步，设计可互动的演示。现场演示不是秀技术，而是让观众参与进来。投票、提问、举手，这些互动环节能让观众从被动听变成主动参与。
第五步，控制时间节奏。现场演讲最怕的就是时间失控。可以多准备一些备用内容，发现时间有余就补充讲解，时间不够就跳过。确保主要演示内容无论如何都能完整呈现。
演示代码的准备策略
写演示代码的时候，可以遵循几个原则：
先搭建基础框架，确保核心功能跑通。比如滚动驱动动画的核心就是监听滚动位置，改变元素状态。这个基础功能稳定了，再往上加故事剧情、视觉效果这些锦上添花的东西。
代码注释要写清楚，不仅写“这段代码做什么”，还要写“为什么要这么做”。这样就算观众没有完整看完代码，也能理解设计思路。
准备降级方案。如果浏览器不支持某个特性，至少保证基本功能可用。就像现场演示里，即使滚动驱动动画不生效，观众至少还能看到静态的故事情节。
应对突发状况
现场演示最怕出bug。有个经验是：提前录好备份视频。万一代码真的跑不起来，可以直接播放视频，保证分享不中断。
另外，把演示内容设计成模块化的。每个小功能都可以独立运行，万一某个环节出问题，可以跳过这一部分，直接进入下一个环节。不要把所有希望寄托在一个复杂的演示流程上。
时间膨胀效应（Time Dilation）在现场是真的会发生。站上台之后，感觉时间过得特别快，明明准备了半小时的内容，总觉得10分钟就讲完了。解决方案是多准备一些可以随时插入的讲解点，时间有余就深入讲，时间不够就快速带过。
技术社区的反馈价值
现场分享结束后，收到了不少反馈。有人说这种带故事情节的技术分享让人印象深刻，有人觉得把个人经历融入技术讲解的方式很新颖，还有人专门提到用滚动方向控制剧情走向的设计特别巧妙。
这些反馈最有价值的点在于，它们证明了技术分享不一定非得板着脸讲干巴巴的知识点。游戏化设计、叙事手法、互动体验这些看似跟技术无关的东西，反而能让技术传播效果更好。
有个刚入行的开发者说，听完分享才知道原来CSS现在已经这么强大了，以前一直以为复杂动画必须用JavaScript。这种反馈说明，当技术被用更生动的方式呈现时，更容易打破新手对框架的路径依赖。