零依赖、零构建:我给个人站做减法

  • 建站笔记

这个站从决定要弄,到真的挂上去,中间隔了挺久。不是没时间,是我一直在纠结一件事:到底要不要上框架。

一开始,我也想过上框架

我当时在纸上列过一堆“应该要有”的东西:框架、模板引擎、路由、打包工具、代码检查、自动部署。清单是从别人的教程里抄来的,抄的时候觉得挺有道理,好像少一样都不算正经网站。

真坐下来想,我这个站要干的事就两件:把文章放上去,改起来方便。就这两件。首页、关于我、文章列表,加上每篇文章一个页面;全部的“交互”也就是列表按标签筛一下。

我不是职业程序员,在办公室做维护,平时的活是修设备、修电脑、管一管内部系统的日常问题。写代码属于我自己爱折腾的那部分。所以用框架的代价对我来说不是“学不会”,而是要一直养着它:依赖会过期,版本会打架,某天跑一条命令报出一串红字,我得花一晚上去查一个跟网站内容毫无关系的问题。这个站只有我一个人维护,多一层东西,就多一层我得记住的东西。

个人站最重要的不是“技术上先进”,而是三年后我还敢动它。

我实际选的做法

手写 HTML 和 CSS,加一点点原生 JavaScript。没有构建步骤,没有包管理器,也就没有那层装了几百个包的依赖目录。整站就是一堆能用记事本打开的文件,一个页面真正干活的就三个:

index.html   页面结构
style.css    样式
main.js      一点点交互

改完把文件复制到服务器上的网站目录,刷新就是最新版。没有“打包了没”“缓存清了没”“这次发的是哪个版本”这些来回确认的事。改错了,把上一份文件复制回去,一分钟就回到原样。

文章列表也是一样的思路:所有文章的信息集中放在一个数据数组里,标题、日期、路径、标签、摘要都写在里面,首页和列表页从同一个数组里取。加一篇文章,只动这一处。

好处比我想的多

举个前阵子的小事:首页的样式忽然不生效,我打开样式文件从头扫一遍,是前面少了一个括号,后面全断了。定位、改完、再传上去,前后不到五分钟。要是中间隔着打包和缓存,同样一个毛病,我大概得先怀疑半天人生。

代价也是真的

好处说完,得说账单,不然就成推销了。

一个是列表要自己管。文章少的时候没感觉,写到十几篇,首页的“最新几篇”和文章列表页就是两份手工清单,加一篇要改两个地方,漏一处列表里就少一篇。我后来把文章信息集中成一个数组,只在那一处加一条,两个页面同时更新,问题才算解决。这也是上面说的那个数组的由来——不是一开始就设计好的,是被漏更新坑出来的。

二是没有组件复用。框架里“改一次页脚,全站生效”这件事,在这儿不存在。页脚在首页、列表页、每一篇文章里都有一份,改一次要动好几个文件。我的办法是写个小脚本批量替换,改完再全文搜一遍旧内容,确认没有漏网的。这做法不优雅,好在一年也就改那么几次。

三是没有服务端就没有后端功能。想做个留言板、想按访问热度排个序,静态文件做不到,要么接别人的服务,要么自己再搭一套后端。所以我从一开始就没打算做这些,需要后端的东西我直接不做,而不是先搭起来再说。

还有一条得诚实讲:列表是脚本渲染出来的,浏览器把脚本关掉,列表就是空的。我在页面上留了一段兜底链接,够用,但算不上完美。

什么时候该上框架

做减法不是信仰,是看需求。下面这几种情况,我会用框架,而不是硬扛:

这几条背后有个共同点:复杂度是真的,不是想出来的。真到那个份上,框架省下的力气远大于它带来的维护成本。反过来,一个只有几页的个人站,复杂度基本是零,框架带来的那部分成本就是净支出——花了时间,换回来的是本来就不需要的能力。

别去维护“可能”

我见过,也干过这种事:觉得“以后可能用得上”,于是先把评论、搜索、统计、一堆配置项都加上。结果一年过去,评论一条没有,搜索没人点,那些配置每次改别的地方还得跟着照顾一下。到头来,被维护的其实不是网站,是那个“可能”。

现在的做法是先不加,等真觉得疼了再说。文章多到翻着费劲,我再加搜索;真有人想看评论,我再想办法。那时候加的东西是被真实需求推着加的,至少我知道它为什么在那儿。

这个站现在很简单,简单到有点朴素。但它有个好处:隔一个月回来,我还能认出每个文件是干什么的,改两行就敢传上去。对我来说,这比用什么技术重要得多。


本文写于 2026-09-05,记录的是当时的情况与做法,未必适用于所有环境,仅供参考。

← 返回文章列表