评论
点赞
收藏"稍后再说"本就是一项功能
本文提出一个反直觉的开发洞见：不写代码才是最具价值的"功能"。作者从自身经验出发指出，开发团队的积压任务（backlog）中大量功能从未被真正优先处理，而几年后回头看，没实现这些功能反而是好事——它们要么已过时，要么与产品方向背离。每次选择"不构建"，都是在为团队和产品加速。更值得警惕的是，随着AI编程工具普及，人们正用token大量生成那些本不该建设的积压功能，导致代码库膨胀到人类无法阅读、只能靠AI接口才能交互的地步。文章引用了Hyrum's Law说明API的不可控扩散定律，并尖锐指出：删除代码的净收益往往被非技术人员忽视。这是一篇有强烈个人立场和独特视角的技术反思，观点鲜明，能引发开发者的强烈共鸣与讨论。
为何编程智能体都转向终端？
当前AI编程工具厂商正集体押注终端/命令行界面，连OpenAI也推出了基于终端的Codex变体。但作者旗帜鲜明地认为这个方向可能彻底错了，并提出了自己的质疑理由。一篇有真实观察、有明确立场的个人观点文章，挑战行业主流叙事，适合引发讨论和反思。
心碎——Gatsby.js 为何失败了
作者以第一人称讲述 Gatsby.js 如何成为他"生命中的爱"，最终又如何让他心碎的历程。背景是 2017 年传统 CMS（WordPress、Drupal 等）仍主导网站构建的时代。这是一个有明确立场、个人情感和一手经验的深度回顾，对前端开发者有很强的共鸣和讨论价值。
与 ChatGPT 聊自我提升
作者分享日常使用 ChatGPT 的真实体验：用它生成职位描述、写基础描述文案、建议代码，以及尝试与它进行关于自我意识的有趣对话。展示了 AI 工具的实际可用性和娱乐价值，但主题已较常见，缺乏独特洞见或深度对话记录。
React —— 框架还是库？
作者重提十年前那场从未真正平息的热门争论：React 到底是框架还是库？以个人视角回顾这场辩论曾有多激烈，反思它当年是否重要、如今是否还有意义。短小但有讨论入口的文章，适合想参与技术定义之争的读者。
2021 年度技术关注清单
作者列出进入 2022 年时最兴奋的技术方向：Solid.js、Astro、Next.js、Remix、Netlify、Cloudflare Workers、tRPC、PlanetScale 等。纯列表式写法，没有解释为什么看好、没有对比或经验分享，信息密度低，更像个人备忘而非可读内容。
Astro —— 梦想中的静态站点生成器
作者介绍当时新兴的静态站点生成器 Astro，先从 SSG 的整体定位说起——它们擅长什么、不擅长什么，再解释为何认为 Astro 可能改变游戏规则。有对比背景、有个人判断，适合关注前端构建工具和 SSG 发展的技术读者。
arnorhs.dev launches
Open for orders
如何出色地构建UI线框图
作者用一段亲身惭愧经历开场：花了几天写代码，信心满满提交代码审查，结果被同事连番质问"这是什么？""为什么要这样做？""会不会影响产品其他地方？""Arnor，你到底造了个什么？"——这场公开处刑式的审查让作者意识到自己闭门造车的问题。文章从这次教训出发，探讨构建UI线框图的正确方法，包括如何提前对齐预期、如何在动手前做低保真原型验证、如何把反馈前置而非等到代码写完才暴露问题。是一个真实开发者踩坑后的实用反思，对产品经理、前端工程师和独立开发者都有参考价值。
移动应用设计：利用1%醒目度对抗感知复杂度
核心看点：提出"1%醒目度"（1% Prominence）这一可复用的设计原则，帮助移动产品在不牺牲功能的前提下对抗感知复杂度。作者从移动设计的根本矛盾切入——3-4英寸屏幕上，功能越多越难用但也越有用——指出盲目堆功能而不精心设计新用户流程，产品必然变得复杂臃肿。这不是空泛的趋势解读，而是一个有个人实践背景的具体设计工具，适合产品设计师和移动端创业者参考。
Math.floor()、parseInt 和位运算左移的性能对比
个人实测对比：JavaScript 中 Math.floor、parseInt 和位运算左移三种去除浮点数小数部分方法的性能差异。作者出于好奇亲自动手在 JSPerf 上跑测试，结果证实位运算左移最快、parseInt 最慢（推测因其需先解析字符串），并附完整测试数据。一篇有第一手实验、有人味的技术短笔记，适合对 JS 底层细节或性能优化感兴趣的读者。
Sensei DB：LinkedIn意外开源的数据库
作者意外发现LinkedIn在开源社区也有贡献，推出了名为Sensei DB的开源数据存储。文章带着个人好奇和探索色彩，简短介绍这一技术发现，适合对开源项目和数据库技术感兴趣的读者。
我的新Kindle Fire
作者在Hacker Buddy赠品活动中赢得一台Kindle Fire，打算写一篇使用体验，但开篇即声明不会讨论任何规格、细节或具体信息，认为网上已有足够资料。文章到此为止，没有任何实际体验、一手观察或可复用信息，属于空壳式发文。
Node.js 会成为下一个 Ruby on Rails 吗？
一篇2012年的个人技术博客，作者从与同事的对话出发，思考Node.js是否会像Ruby on Rails一样成为主流技术栈，还是只是一时热潮。起初作者坚信Node.js会成为史上最流行的框架，但冷静下来后意识到事情没那么简单。文章短小但带有真实的个人思考和困惑，保留了技术社区早期讨论Node.js前景时的原始氛围。适合对技术历史演变感兴趣的读者快速一瞥当年开发者如何看待新兴的Node.js。
一个坏习惯：把所有域名都买下来
作者坦白自己有个坏习惯：每当产生一个新想法，第一件事就是去买域名；而 brainstorm 出的 30 个候选名筛选到 3-5 个后，因为选择困难症（自称"天秤座"），最终把全部候选域名都买下。短文以自嘲语气分享了这个真实而具体的个人行为，篇幅极短但信息密度高，容易让有类似经历的读者会心一笑或产生共鸣。
为 Node.js 编写的基于 Stylus 的响应式网格框架
一篇作者在2011年底写的短笔记。作者刚接触 Node.js 两三个月，在 Express 项目中先用了默认的 SASS 编译器，经 TJ Holowaychuk 推荐改用 Stylus，随后同乡 Jokull Solberg 分享了他用 Stylus 写的一个响应式网格框架。全文只是简单记录了这个发现过程，没有给出框架的具体用法、代码示例、对比评测或任何实质技术细节，更像一则社区动态速记。对今天的技术选型参考价值极有限，但保留了早期 Node.js 社区里个人探索和互相推荐的痕迹。