为什么我还在折腾技术？一个35岁老前端的深夜自白
凌晨两点，成都窗外淅淅沥沥下着小雨，楼下的烧烤摊终于收摊了。我端起已经凉透的咖啡，盯着屏幕上那行闪烁的光标——又是一个为了优化页面交互动效而熬的夜。说实话，35岁了还在写代码，有时候自己都觉得有点“轴”。但每次看到用户在产品里流畅地滑动、点击、反馈，那种成就感，真的会上瘾。
今天想聊聊一个看似很“大”的话题：为什么我们还要花时间去探索和实践新技术？ 尤其是在前端这个卷得飞起的领域。
面试题不是终点，是起点
上周五晚上，团队来了个实习生小张，吃饭时聊起他最近面了几家大厂，被问到“你有没有做过自定义动画性能优化？”、“如何实现高性能滚动列表？”这类问题。他说自己背了很多答案，但实际项目里根本没用过。我笑了笑，说：“面试题只是引子，真正的问题是你能不能把它们变成你项目里的肌肉记忆。”
我自己也是这么过来的。记得去年双11前，我们团队接到需求：要在商品详情页加入一个“动态价格波动”效果，模拟股票那种上下跳动的感觉。产品经理画了个酷炫的原型图，说“要丝滑，不能卡”。当时我就知道，这玩意儿要是直接用 setInterval + DOM 更新，怕是要被用户骂死。
果然，第一次上线后，在低端安卓机上帧率掉到 20fps，测试同学直接甩我一句：“哥，这动画比我奶奶走路还慢。”我当时真的想砸电脑。
动手之前，先搞懂原理
于是那个周末，我没去宽窄巷子喝茶，而是窝在家里翻文档、看源码。前端动画这块，其实核心就几个点：
- 渲染路径：CSS 动画 vs JS 控制
- 合成层（Composite Layer）：哪些属性能触发 GPU 加速
- requestAnimationFrame：比 setInterval 更适合做动画调度
- will-change：提前告诉浏览器“我要动了”
我决定用 CSS transform + opacity 来做价格数字的变化，因为这两个属性不会触发重排（reflow），而且能走硬件加速。关键代码如下：
// 模拟价格波动
function animatePrice(element, targetValue, duration = 800) {
const startValue = parseFloat(element.textContent);
const startTime = performance.now();
function step(currentTime) {
const elapsed = currentTime - startTime;
const progress = Math.min(elapsed / duration, 1);
// 使用 ease-out 缓动函数，更自然
const easedProgress = 1 - Math.pow(1 - progress, 3);
const currentValue = startValue + (targetValue - startValue) * easedProgress;
element.textContent = currentValue.toFixed(2);
if (progress < 1) {
requestAnimationFrame(step);
}
}
requestAnimationFrame(step);
}
为了让它真正“不卡”，我还加了 will-change: transform; 到父容器上，并且确保整个动画区域是独立的合成层：
.price-container {
will-change: transform;
transform: translateZ(0); /* 强制开启硬件加速 */
}
上线后，低端机帧率稳定在 55fps+，测试同学终于笑了。那一刻我觉得，熬夜值了。
技术探索不是为了装X，是为了少背锅
很多人觉得，前端嘛，切切图、调调样式、联调接口，完事。但现实是，用户不会区分“这是前端问题还是后端问题”，他们只觉得“这破网站卡死了”。
有一次，我们线上有个表单提交按钮点了没反应。查了半天，发现是因为某个第三方埋点 SDK 在低端机上阻塞了主线程。运维甩锅给前端，后端说“接口都返回 200 了”，最后还是我硬着头皮用 PerformanceObserver 把耗时任务揪出来，再用 Web Worker 把埋点逻辑挪出去。
那次事故让我明白：技术深度不是简历上的装饰品，而是你在生产环境里保命的底牌。
前端不是“界面仔”，是体验架构师
现在很多人还在用“切图仔”形容前端，我真的想翻白眼。现代前端早就不只是写 HTML/CSS/JS 了。我们得考虑：
- 首屏加载速度（LCP）
- 交互响应延迟（INP，以前叫 FID）
- 视觉稳定性（CLS）
- 无障碍访问（a11y）
- 跨设备兼容性
这些都不是靠“套模板”能解决的。比如我们最近重构的一个活动页，要求在微信内置浏览器、Safari、Chrome 上表现一致。结果发现 iOS 的 scroll-snap 行为和其他平台不一致，安卓 WebView 对 IntersectionObserver 支持又差。
怎么办？只能自己封装一套“滚动吸附”逻辑，用 touchmove + requestAnimationFrame 手动控制。虽然累，但换来的是用户体验的一致性——这才是前端真正的价值。
实践中的技术选型：别为了新而新
当然，我也不是那种盲目追新的人。Vue 3 出来时，团队有人嚷嚷着要立刻重构。我说：“兄弟，咱们这系统还有 30% 用户用着 IE11 呢，你 Vue 3 写完了打包出来能在 IE 跑吗？”
技术选型必须结合业务。我们现在的策略是：
| 场景 | 技术选择 | 理由 |
|---|---|---|
| 核心业务系统 | Vue 2 + TypeScript | 稳定、团队熟悉、IE 兼容 |
| 新活动页/H5 | React + Vite | 快速迭代、生态丰富 |
| 动画密集型模块 | 原生 JS + CSS Houdini（实验性） | 精细控制性能 |
你看，没有“最好”，只有“最合适”。我甚至在某些简单页面里直接用原生 JS 写，连框架都不引入——省下的 200KB 包体积，对弱网用户就是几秒的等待时间。
那些“无用”的探索，终会回报你
去年我闲着没事，研究了一下 Web Animations API（WAAPI）。当时觉得这东西太新，浏览器支持也不全，可能用不上。结果今年做国际化项目时，需要根据语言方向（LTR/RTL）动态反转动画方向。用 WAAPI 只需要改个 direction 属性，而用传统 CSS keyframes 得写两套。
那一刻我庆幸自己当初“多此一举”。
还有一次，我在 GitHub 上看到一个用 ResizeObserver 实现响应式图表的 Demo，顺手扒下来改了改。没想到后来做数据看板时，直接复用了那段逻辑，省了两天开发时间。
技术探索就像存钱，平时看不见收益，但关键时刻能救命。
给还在路上的你：别怕“老”，怕的是停
经常有年轻朋友问我：“35岁还在写代码，会不会被淘汰？” 我的回答是：淘汰你的从来不是年龄，而是停止学习的心态。
我在成都，生活节奏舒服，不用像北上广那样天天焦虑。但我依然保持每周至少读一篇 RFC、试一个新工具、复现一个开源项目。不是为了跳槽涨薪（虽然确实有用），而是因为我喜欢解决问题的过程。
前端这个领域，永远有新的坑等着你跳。但每次填完一个坑，你就离“人形自走解决方案”更近一步。
最后一点真心话
技术探索与实践，不是为了在面试时吹牛，也不是为了在群里晒代码。
它是为了让你在面对“这个需求明天上线”时，能淡定地说一句：“没问题，我有方案。”
所以，别管别人怎么说“前端已死”、“AI 要取代程序员”。
只要你还在享受写出一行优雅代码的快感，还在为解决一个刁钻 Bug 而兴奋，
你就依然是那个闪闪发光的开发者。
好了，天快亮了，我得去睡了。
明天还要跟产品经理 battle 一个“能不能让 logo 跳舞”的需求……
（完）
P.S. 如果你也喜欢深夜 coding，欢迎留言交流。成都的程序员，约个茶？
评论 0