大多数我发布的工具都是一个HTML文件。内联CSS，内联JavaScript，没有构建步骤，没有打包器，没有CDN，没有npm install。你下载文件，打开它，它就能用。离线、永久，在任何浏览器上都能运行。

到现在我已经用这种方式做了几百个工具。我想把这种约束真正换来什么、又付出什么说清楚，因为互联网上对“我该不该用框架”的默认回答，往往是非此即彼的，没什么用。

打开网易新闻 查看精彩图片

零依赖腐烂

一个没有依赖的文件，就没有什么可以坏掉。没有传递性漏洞警报，没有废弃的包，没有因为工具链升级而停止工作的构建。我两年前写的工具，今天打开，行为完全一样。如果你维护过任何带node_modules目录的东西，并且跨了几年，你就知道这值多少钱。

分发就是一个文件

没有托管，没有部署流水线，没有运行时间。可以发邮件，可以放进U盘，可以提交到仓库，可以丢进Slack频道。它从file://就能运行。对付费工具来说，这就是整个产品：客户拥有这个工件，不会因为我做的任何事而失去访问权，包括我倒闭。

真正的隐私，而不是隐私政策

没有服务器，就没有服务器端日志。用户输入什么，就留在他们自己的标签页里。对于任何涉及文档、密钥、财务数据或客户工作的东西，“这不可能离开你的机器，因为它没有地方可去”这句话，比一个承诺要强得多，而且一句话就能解释清楚。

不用费力就能得到的速度

一次请求，没有水合，没有瀑布式加载。没有什么可优化的，因为那里本来就没有东西。

可审计性

查看源代码，整个程序就在你面前。对安全工具来说，这是一个真正的特性。任何人都能一口气读完整个程序。

如果我把这些说成是免费的，那我就是在撒谎。

没有共享状态

每个文件都是一座孤岛。一个文件里修好的bug，就只在这一个文件里修好。我是用生成和模板化来解决这个问题的，而不是用运行时共享。这等于把运行时耦合换成了构建时的纪律，而这个交换之所以成立，只是因为我让工具保持足够小。

文件之间没有组件复用

同一个头部写在八十个文件里。头部设计一变，八十个文件都要改。还是那句话：靠工具化，不靠架构。

复杂度有真实上限

这种做法在一定范围内非常漂亮，超过那个点就不行了。任何需要认证、跨设备持久化、协作，或者真正复杂状态的东西，都不应该做成单个文件。我大致把上限设在3000行左右，一旦某个东西想越过这条线，那就是一个信号：它想成为一个真正的应用了。

没有生态

没有组件库，没有状态管理，没有路由。对大多数单一用途的工具来说，你根本不需要这些。如果你确实需要，那和上面是同一个信号。

我实际使用的规则

当问题能装进一个屏幕的概念里时，就用单个文件。计算器、转换器、检查器、生成器、格式化器、分析器。一个输入，一些处理，一个输出。

一旦它需要登录或者数据库，它就不再适合这个形态了。