一个标准React脚手架占用245MB磁盘空间,而纯手写HTML/CSS/JS方案仅需12KB——相差两万倍的背后,是数据中心里持续运转的CPU和真实存在的电费账单。
「我不为奖金,只为完成徽章」
![]()
这篇投稿来自一位匿名开发者,参加的是DEV社区的「地球日周末挑战」。他开篇就划清界限:不做AI工具,不跑区块链节点,「纯粹作为参与者」。
他的「项目」没有上线任何新应用。理由很直接:「我不想让新应用躺在服务器上白白烧电。」
取而代之的,是一份《精益网页架构标准》——给自己未来项目用的开发规范。
臃肿的代价:每一行多余代码都在耗电
作者算了一笔账。数据中心的电力往往来自化石燃料,而教程里推崇的「 heavier frameworks, more API calls, and bloated libraries」(更重的框架、更多API调用、臃肿的库)直接推高能耗。
他用终端命令做了直观对比:
React脚手架方案:245MB
纯手写方案:12KB
差距不是几倍,是20480倍。
作者的核心论点:服务器处理12KB静态文件所需的CPU周期,远低于编译和注水(hydrate)庞大JavaScript包的消耗。「Less CPU = less power = lower emissions」(更少CPU=更少电力=更低排放)。
三条实操规则
这份个人标准聚焦三件事,原文未展开细节,但从上下文可还原其指向:
第一,用原生代码替代依赖。作者明确提到「relying on vanilla code instead of dragging in 500MB of node_modules」(依赖原生代码而非拖入500MB的node_modules)是他眼下最可行的环保动作。
第二,服务端处理替代客户端重逻辑。示例显示,用.htaccess文件处理路由和缓存,而非引入重型JavaScript库。
第三,缓存即绿色技术。作者称「Caching is arguably the best 'Green Tech'」(缓存堪称最佳「绿色技术」),因为它能避免服务器重复处理相同请求。
他贴出的.htaccess配置包括:图片缓存一年、CSS/JS缓存一个月、URL重写简化后端解析。
为什么是现在?
这个实验的微妙之处在于时机选择。地球日挑战通常催生「种树计数器」或「碳足迹计算器」这类应用——它们本身也是新部署的服务器负载。
作者反其道而行:用「不构建」来构建。这种自我约束指向一个被忽视的真相——开发者工具链的膨胀速度远超业务需求的增长速度。
245MB的脚手架里,真正服务于「简单店铺页面」的代码占比极低。剩余部分是开发体验优化(热更新、语法转换、打包分析)、潜在功能预留、以及层层嵌套的依赖依赖。
12KB方案牺牲了这些,但保留了核心交付能力。
争议与边界
作者的方法论有明显适用范围。他自认技术栈是「HTML, CSS, JavaScript, and PHP」——这是经典服务端渲染路线,与React代表的客户端渲染范式存在架构分歧。
原文未声称此法适用于所有场景。没有数据证明「所有React应用都可被PHP替代」,也没有企业案例支撑「12KB方案在大型项目中同样高效」。
但作者的论证严格限定在个人项目维度:「for my own future projects」(针对我自己的未来项目)。这是一种个体层面的技术债务清理,而非行业宣言。
数据收束
245MB到12KB的对比是夸张的,但作者提供的终端截图(或伪代码)格式让它可被复现验证。关键数字未被模糊处理:React脚手架245MB,手写方案12KB,缓存周期精确到「1年」和「1个月」。
这个实验的真正价值不在于推广PHP,而在于提出一个可量化的自检问题:你的工具链体积,是否已经超过你实际交付的功能所需?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.