刚刷到HN那篇《The fun has been optimized out of the Internet》，深有感触。其实现在不少前端开源项目也踩了这个坑，为了抠几KB的bundle size、符合所谓的“极简定位”，把很多用户贡献的好玩但“非核心”的特性全砍了。
我前两年参与维护一个Vue组件库的时候，就碰到过这事：有个在校学生贡献了个自定义动画插槽，测下来只增加了1.8KB的打包体积，最后还是被核心组以“偏离核心目标”打回了。这就像你为了让Vue项目首屏快100ms，把用户最喜欢的交互动效全删了，完全得不偿失啊。
大家有没有碰到过类似的过度优化的情况？

哎哟我去，这帖子简直是我最近的心声啊。昨天刚在GitHub上看到一个React动画库，最新版本把“粒子效果”模块给移除了，理由是“不符合轻量化设计理念”。我点开issue一看，好家伙，那模块总共就3KB，但评论区一堆人在哀嚎说自己的星空背景特效没了。
呵呵
说真的，现在有些开源项目维护者是不是有点走火入魔了？为了追求那个bundle size的数字好看，把项目搞得跟毛坯房似的。我理解性能优化很重要，但1.8KB的动画插槽都要砍，这已经不是优化了，这是强迫症晚期吧？用户用你的库是为了解决问题、做出酷炫的东西，不是为了看你的打包体积排行榜拿冠军。

我前阵子给一个Node.js工具库提PR，加了个彩色控制台输出的功能，也就多了两个依赖。结果维护者回复说“这会增加安装时间0.3秒”。我当时就在想，大哥，这工具是给开发者用的，谁会在意那0.3秒啊？大家想要的是更好的开发体验好吗？

不过话又说回来，有时候也能理解维护者的难处。我之前参与过一个小型UI库，刚开始什么功能都往里加，后来发现文档写不过来，测试覆盖率也跟不上。最后确实得做减法，但关键是怎么减——是砍掉那些没人用的冷门功能，还是把用户真心喜欢的小彩蛋给优化没了？这中间的平衡点太难找了。

笑死你们有没有遇到过那种“过度优化”到反人类的例子？我最近看到一个前端框架，为了省那几KB，连错误提示信息都简化成了代码，用户得去查文档才知道什么意思。这简直是把用户体验按在地上摩擦啊。

话说回来，那个Vue组件库后来怎么样了？那个贡献动画插槽的学生还在参与开源吗？有时候这种打击对新人来说挺伤的。

你说的那个平衡点难找的问题，我倒是见过挺多团队用插件化的方案解决了。我之前帮同校计算机系的学长做他的开源日历组件的中文文档翻译，那时候他们就用的这种思路，核心包只留最基础的日历渲染功能，打包完才11.7KB，像自定义动画、农历标注、节假日提醒这种非核心的功能，全做成独立的扩展包，每个也就2到4KB，用户有需要的自己引入就行，既不影响核心包的轻量化定位，也不会把大家喜欢的实用小功能砍没。
我之前看过npm 2023年的前端开发者调研数据，76%的受访者愿意为实用的额外功能接受小于1秒的安装延迟，以及5KB以内的打包体积涨幅，你之前提的0.3秒安装时间、1.8KB体积的改动，其实完全在用户接受阈值里的。
还有你说的把错误提示换成代码的我太有共鸣了，上个月我写课程作业用某个轻量框架，报错只蹦个E-2049，我翻了三页文档才知道是props类型传错，대박，当时我对着屏幕愣了三分钟，完全想不通省那几个字节的意义到底在哪。
对了你们有没有遇到过插件化做的特别顺畅的前端库？我最近做小项目想找个参考。

我之前自己瞎写的那个机车码表同步的小开源脚本，还有用户给加了个同步当前播放死核BPM的小彩蛋呢，我直接就合进去了，反正也就多了不到1KB，好多玩改装的朋友说每次骑的时候踩点特爽。理解的
其实真没必要卡这么死，实在嫌占体积做个可选的扩展包不就完事了，何苦把最有意思的部分先咔嚓掉啊。

骑机车跟着死核BPM卡着油门点的画面感，简直像把晒得发烫的公路变成了livehouse的延伸舞台啊。
我前阵子熬大夜打gacha，顺手写了个统计抽卡掉率的小脚本扔同好群里，后来有个读计科的学生给加了个小功能，但凡出了SSR就会弹出个半透明的Q版miku晃着荧光棒跳十秒，整个功能压缩完才六百多字节。一起写脚本的朋友本来嫌多余要删，我拦着做了个可选的插件包，上个月还有个姑娘私信我说，那天连续沉了三池正抱着电脑掉眼泪，突然弹出个晃着呆毛的miku，一下子就笑出了鼻涕泡。
以前在唐人街刷盘子的时候，厨师长总要求我们擦完盘子直接摞好，不许在边角摆多余的橙皮小花，说耽误上菜速度。我总趁他不注意给单独来吃饭的客人摆个极小的，有次八十多岁的华裔老太太吃完，专门绕到后厨给我塞了块杏仁糖，说那朵小橙花让她想起小时候外婆家的橙子树。嗯…
其实代码和瓷盘一样，那些看起来没什么用的小零碎，才是让冷冰的东西活过来的气脉。其实说起来我那脚本的miku插件最近还有人要加镜音铃的版本，这周没课的时候改改去。