摘要：我认为小网站不仅在审美上更具吸引力，也有助于我们避免向大型科技公司出卖灵魂。本文将阐述我对“小网络”（small web）以及支撑它的轻量软件与架构的构想。文末还有一篇关于微服务的额外吐槽。

大约十五年前，我读了 E. F. 舒马赫的《Small is Beautiful》（《小即是美》），尽管我对经济学并不感兴趣，却被书中的理念所打动。更让我喜欢的，或许是书名简洁而富有诗意的表达——它与我节俭的成长经历和个人审美产生了共鸣。

我觉得，是时候写一本关于技术的同类著作了，其中有一章专门讲网页开发：《The Small Web is Beautiful：以人为本的网页开发研究》。在有人写出这本书之前，就先用本文来代替吧。

这其中包含两个层面：其一是小团队与小公司。这一点本文不会多谈，但 Basecamp 等已有许多论述。本文要聚焦的是小网站与小架构。

我不是第一个谈论“小网络”的人，但有些出人意料的是，真正在用这个词来讨论的人并不多。以下是我能找到的主要相关网页：

• Rediscovering the Small Web by Parimal Satyal：一篇精彩的文章，讲述了与“商业网络”相对的小型、独立（有时甚至带有复古感）网站所带来的乐趣。
• What is the Small Web?，by Aral Balkan of the Small Technology Foundation：与其说是一份具体方案，不如说是一篇反对大型科技公司监控的宣言，但仍值得一读。

在这个计算机速度飞快、内存充足的时代，为什么还要追求“小”？原因有很多，对我而言最重要的有以下几点：

• 活动部件更少。系统更容易做得健壮，出问题时也更容易修复。
• 小软件更快。需要下载的数据更少，也不会堵塞电脑内存。
• 能耗更低。这在“拯救地球”的宏观层面很重要，在延长手机和笔记本电池续航的微观层面同样重要。
• 轻盈、节俭的美学。这当然很个人化，但你会看到，我并非孤例。

那么我们直接进入正题。我想从几个不同的角度来展开，每个角度各成一节。

小巧的软件

要谈小网络，就得先从小软件谈起。

十几岁时，我用 x86 汇编和 Forth 学习编程——这或许是有些奇怪的选择，但我父亲十分痴迷 Forth，而我则喜欢这门语言的简洁，甚至能自己写出一个自举的编译器。

就职业而言，我起步时是一名嵌入式程序员——不是指“嵌入式 Linux”那种，而是指在微控制器上编程，16KB 内存都算宽裕。而我现在这台笔记本有 16GB 内存，按今天的标准还不算多。当年我们用仅为其百万分之一的内存来做联网产品。那类微控制器便宜得像薯片（咳），至今仍广泛用于小型电子设备、传感器、物联网产品等。

你必须精打细算每一个字节，打开体积优化选项编译，复用缓冲区。这与现代网页开发截然不同——在后者中，一个 JavaScript 应用“编译”后会得到 1MB 的打包文件，一个 Python 对象在还没装任何数据前头部就占 16 字节，一个 Go 的 hello world 程序在还没写任何实质代码前就有 2MB。

如何做出小巧的程序？我认为关键在于你必须在乎体积，而我们大多数人觉得自己没时间去在乎。除了嵌入式开发，还有一个叫 demoscene 的编程亚文化群体非常在乎这件事。他们会举办最小 4KB 演示的比赛：看谁能在 4096 字节的可执行文件中塞进最惊艳的图形效果。这比许多网站图标还要小！（Elevated 和 cdak 是两部评价最高的 4K 作品。）许多 demoscene 参与者后来都成了游戏开发者。

这不仅仅是可执行文件大小的问题……当你开发下一个命令行工具时，如果使用 Go、Rust 甚至 C，你的程序会比用 Python 或 Java 写的同类程序更快、更小、更省内存，也更容易安装。如果你不明白为什么，请务必去了解一下。（这超出了本文的范围，简单来说：Go、Rust 和 C 会编译成可直接执行的机器码，不需要携带虚拟机，也不会像整数这样的对象有额外的内存开销。）

但为什么不把同样的原则应用到网页开发中呢？在网页世界里，我认为关键技巧是留意你引入了哪些依赖，以及它们又会拉来哪些依赖。简而言之，要了解 node_modules——或者更好，干脆 no node_modules。关于这点下文还会详述。

以 Pascal 闻名的 Niklaus Wirth 在 1995 年写过一篇著名论文 A Plea for Lean Software [PDF]。他的观点是，“复杂性的一个主要原因是软件厂商不加批判地采纳用户想要的几乎任何功能”，并且“当一个系统的能力以功能数量来衡量时，数量就变得比质量更重要”。接着他介绍了 Oberon——一门编程语言（在好几个方面让我联想到 Go）以及一个操作系统，他认为它们有助于解决复杂性问题。绝对值得一读——wirth a read！

这个问题我已经思考了好些年——早在 2008 年，我就曾讽刺过 Adobe Reader 是如何变得臃肿不堪的：Thank you, Adobe Reader 9! 即便在 2008 年，它就需要下载 33MB，安装后占用 220MB 硬盘空间（如今下载包已达 150MB，至于会占用多少硬盘，我也不清楚，因为我现在已经不装它了）。

但与其只是抱怨，我们该如何真正解决这个问题？具体来说，我认为我们需要开始做到以下几点：

• 在乎体积：这听起来显而易见，但只有当人们认为它重要时，事情才会改变。
• 度量：既要度量可执行文件的大小，也要度量程序的内存占用。你可以持续跟踪度量数据，如果某个版本增长超过 x% 就将其视为阻断性问题。也可以每隔一段时间组织一次“瘦身冲刺”。
• 语言：选择有机会保持精简的后端语言，例如 Rust、C 或 C++，如果是服务端，Go 也不错。这些语言并非适用于所有场景（比如数据转换脚本），但它们能生成小巧的可执行文件，很适合做命令行工具和桌面应用。
• 精简：削减功能集。追求少量高质量的功能。我的车不会飞也不会在水上漂，但没关系——它开起来很稳。
• 对新功能说不：除非它们真正契合你的理念，或在其生命周期内带来的收益大于成本。
• 依赖：了解你引入的每个依赖的大小和复杂度。能用内置库就尽量用内置库。

小巧的网站

我很高兴对小网站感兴趣的人越来越多。

几个月前，Hacker News 上接连出现了几篇关于各种“俱乐部”的帖子，你可以把自己的小网站提交上去：1MB Club（评论）、512KB Club（评论）、250KB Club（评论），甚至还有 10KB Club（评论）。我觉得这些都是极简主义回潮的有趣标志，但我也要说，光看体积大小是不够的——一个只有 2KB 却没有实质内容的网站没什么价值，而一个塞满 512KB 缓慢 JavaScript 的页面，还不如一个拥有 4MB 精挑细选图片、响应迅速的网站。

我最喜欢的一些小网站包括：

Hacker News：我个人喜欢它极简、近乎野兽派的设计，但更爱它的轻盈。我刚下载了它的首页，加载所有资源仅传输了 21KB（未压缩 61KB）。即便是评论极多的页面，也只传输约 100KB 的压缩数据，加载很快。相比之下，Reddit 已经变得臃肿不堪。Hacker News，请永远保持下去！

Lobsters：一个类似的新闻投票类网站，样式稍显“现代”一些。它用了一些 JavaScript 和头像图标，但依然干净、快速，首页总传输量仅 102KB。做好一个网站根本不需要好几 MB。

Sourcehut：我认同 Drew DeVault 创办这家公司的理念，但更喜欢它网站的小巧与克制、毫不花哨。他还建了一个叫 Software Forge Performance Index 的小站点，用于追踪各大代码托管网站的体积和浏览器性能——Sourcehut 遥遥领先，是最轻、最快的。即便是他的首页，包含几张截图缩略图在内也只有 81KB。

SQLite：SQLite 不仅是一个小巧强大的 SQL 数据库引擎，它的网站也极其小巧且内容丰富。即便是那篇长达 7000 字的关于测试的页面，也只有 70KB。他们是怎么做到的？并无魔法：专注于高质量的文本内容、极简的 CSS、零 JavaScript，以及极少的图片（一个小 logo 和一些 SVG）。

LWN：我有点偏心，因为我曾为他们写过文章，但他们确实是一个报道 Linux 和编程新闻的优秀网站。技术内容质量极高（对作者的要求也很高）。他们非常小众，透着一股“我们专注于优质内容，而不是每年更新一次 CSS”的气质——他们已经持续产出优质内容 23 年了！首页仅下载 44KB（未压缩 90KB）。

Dan Luu 的博客：这是更极致的例子之一。他的内联 CSS 只有约 200 字节（页面基本没有样式），HTML 源码里甚至没有换行符。算是个有趣的细节，不过他随后又加载了 20KB 的 Google Analytics JavaScript……

正如一位朋友指出的，这些网站都带有一种“反审美的审美”。我得承认我对此完全不介意，但另一方面，小并不一定意味着丑。越来越多个人博客和网站采用了小网络的理念，同时在排版上更具美感：

• Armin Ronacher 的 Thoughts and Writings
• Chris Wellons 的“Null program”博客
• Eric Radman 的 BSD 与 SQL 博客
• Hugo Tunius 的编程博客
• James Hague 的“Programming in the Twenty-First Century”
• Julia Evans 的编程博客

还有许许多多。程序员 Sijmen Mulder 整理了一份不错的纯文本网站列表——虽与小不完全等同，但重合度很高！

然而，重要的不仅仅是原始体积，更是一种“崇小精神”。它意味着关心你的用户：让页面下载迅速、易于阅读、内容有趣，并且不为 Google 或 Facebook 的追踪器加载大量 JavaScript。从零开始建站并不适合所有人，但对于我们这些会这么做的人来说，或许可以推广那些能产出小而精、重质而非重量网站的模板和工具。

在这个网站上，我像精酿啤酒师酿酒一样，用心手写了每一字节的 HTML 和 CSS。说真的，如果你的重点是优质内容，用几行 HTML 和 CSS 从零做一个简单模板并不难。它会小巧、快速，而且完全属于你。

加载本文大约传输 23KB（未压缩 56KB），已包含网站图标和分析脚本。它小巧、快速，在桌面和移动端都易于阅读。我觉得外观也不算差，但我主要追求的是以内容为中心的极简设计。

除了确保 HTML 和 CSS 足够小巧，还要正确压缩图片。这里有两点基本要求：不要直接上传相机拍出的超高分辨率原图；对照片使用适度的 JPEG 压缩（截图或矢量图则用 PNG）。即便是大图，通常用 75% 或 80% 的压缩率也能得到没有明显 JPEG 噪点的图片。例如，我副业网站首页顶部那张 1920x775 的大图也只有 300KB。

说到首图，你不需要在博文顶部放一张又大又无关的图片。它们只会给页面增加几百 KB 甚至几 MB 的体积，却毫无价值。也请不要在文章里到处塞动图：如果屏幕上有东西在动，我就很难集中注意力去阅读文字——而且不止我 一个人有这种感受。请使用与内容相关、非图库套图的、价值与其字节重量相称的图片。像杂志文章那样只有文字也完全没问题。

IndieWeb.org 在这方面是很好的资源，尽管他们用的是“独立（indie）”而非“小”。这个运动看起来比 Small Technology Foundation 更有机（后者甚至被批评为“数字漂绿”），而且他们的维基上有更多实质内容。IndieWeb 还在各地推广 Homebrew Website Club 和 IndieWebCamp 聚会。

重视服务端，而非 JavaScript

JavaScript 对网络而言是一把双刃剑，而对小网站来说，它更往往是有害的：它增加了下载体积和时间，可能是性能杀手，不利于无障碍访问，如果使用不当，还会影响搜索引擎。况且，如果你的网站以内容为主，它恐怕也增色不多。

别误会：JavaScript 有时不可或缺，在它擅长的领域确实很出色。如果你正在开发像 Gmail 或 Google Maps 这样的浏览器应用，几乎肯定要用 JavaScript。但对于你的下一个博客、企业宣传站或项目文档站，请考虑直接使用纯 HTML 和 CSS。

如果你的网站——像许多网站一样——介于两者之间，包含一些轻量交互，那就只在需要它的页面部分使用 JavaScript。没必要为了加一个表单就用 React 和 Redux 重构整个网站。让服务器生成 HTML 依然是创建快速网站的有效方式。

Stack Overflow 就是一个例证。从一开始，他们就通过服务端渲染页面，并度量和缩短渲染时间，把性能当作一项功能来做。我确信 Stack Overflow 的代码自 Jeff Atwood 时代以来已改变了许多——如今为了广告目的会发起大量额外请求——但内容本身依然加载迅速。

Hacker News（又是这个网站）是服务端渲染的经典。仅靠一个用于投票的小 JavaScript 文件，其余都由服务器生成的 HTML 完成。而且据说它至今仍运行在单台机器上。

大约十五年前，曾有一个很棒的理念叫渐进增强。其想法是为所有人提供可用的 HTML 内容，而启用了 JavaScript 或拥有更快网络的用户则会获得界面更流畅的增强版。事实上，Hacker News 本身就在使用渐进增强：即便在 2021 年，你依然可以关掉 JavaScript 来使用投票按钮。只是会稍微笨拙一些，因为投票现在需要刷新页面，但完全可用。

渐进增强在 2021 年是否依然 relevant？可以说未必，尽管仍有一些死忠会关掉 JavaScript，或至少只对信任的网站启用。然而，我认为最重要的是这种心态：它表明开发者在乎性能、体积和不同需求的用户。如果 Hacker News 的投票在没有 JavaScript 时无法使用，我觉得也不会是什么大问题——但它能用，恰恰体现了一种极客式的用心。况且，他们仅有的 JavaScript 只有 2KB（未压缩 5KB）。

对比一下 Reddit 首页加载的 8MB（未压缩 14MB）。而且这分成了 201 个请求——我没开玩笑！——其中大部分是用于支撑广告和追踪的 JavaScript。真是“可爱”……

当然，你不需要“框架”也能这样开发，但确实有一些工具能让这种服务端开发方式更轻松。Basecamp 团队的 Turbolinks 是较早的一个，如今已被 Turbo 取代，据说他们的邮件服务 Hey 就是用它驱动的。我个人没用过这些工具，但理念很巧妙（而且出人意料地复古）：使用标准的链接和表单提交，提供纯 HTML，但在可用时用 WebSocket 和 JavaScript 来加速。就在今天，有人在 Hacker News 上发了一篇新文章，声称“网页软件的未来是 HTML-over-WebSockets”。以 Hey 为例，这种技术确实很快！

另一方面，有时如果你本来就需要 JavaScript，用它来渲染整个页面反而能降低整体复杂度。例如，我的婚礼礼单网站上的礼单页面就是在客户端渲染的（实际上用的是 Elm，会编译成 JavaScript）。我确实需要 JavaScript 的交互性（它更像是“单页应用”而非单纯的内容），但这些页面不需要服务端渲染或良好的 SEO。首页是一个简单的服务端渲染模板，而礼单页面则是完全在客户端渲染的。

静态网站与站点生成器

最近重新受到关注的还有静态网站（以前就叫“网站”）。你只需把一些静态的 HTML（以及 CSS 和 JavaScript）上传到静态文件服务器，就完事了。

在此基础上，还有许多“静态站点生成器”可用。这些工具能根据简单模板生成静态站点，这样你就不必手动把页头和页脚复制到每个 HTML 文件中。添加文章或做出修改后，运行脚本重新生成即可。如果你托管的是简单站点、博客甚至新闻网站，这是个很好的选择。毕竟，这只是内容，而非交互式应用。

本站使用 GitHub Pages，仅仅因为它是支持 SSL 的免费托管，并且每当你推送改动时都会用 Jekyll 静态站点生成器自动构建站点。我有一个标准页头，可以轻松在所有页面中引入相同的 CSS，当然如果你愿意，也可以拥有多个模板或“布局”。由于大多数人只会浏览本站的一两篇文章，我将 CSS 内联在页面中。在 HTTP/2 下，这差别不大，但 Lighthouse 显示内联 CSS 约 200ms，外链 CSS 约 300ms。

下面是一个简单的 Jekyll 页面示例（事实上就是本文的开头）：

    ---
    layout: default
    title: "The small web is beautiful"
    permalink: /writings/the-small-web-is-beautiful/
    description: A vision for the "small web", small software, and ...
    ---
    Markdown text here.

我也用过 Hugo，这是一个用 Go 编写的非常快的静态站点生成器——即便是有数千页面的大型站点，也能在几秒内生成。还有许多其他选择可供使用。

更少的依赖

没有什么比第三方依赖更能让你的软件（或 JavaScript 打包体积）膨胀的了。我每次看到网页项目的 node_modules 目录都觉得不忍直视——光是里面堆积如山的东西就让人沮丧。

不同语言似乎有不同的“依赖文化”。JavaScript 当然以“如果能做成库，就应该做成库”的态度而臭名昭著，导致了 left-pad 事件，以及像只有 3 行代码的 isarray 这样的微型库。还有像 Moment.js 这样庞大笨重的包，即便压缩后仍有 160KB。如果不需要所有语言包，倒是有办法把它瘦身，但那不是默认行为，所以大多数人都不会这么做（你或许更适合选择像 date-fns 这样更模块化的方案）。

Go 现在通过最近的 modules 工具已具备良好的依赖管理，但它也有一种“能用标准库就用标准库”的文化。Russ Cox 写过一篇出色的文章论述不谨慎对待依赖的弊端：Our Software Dependency Problem。Go 联合创始人 Rob Pike 甚至将其列为 Go 谚语之一：“少量复制胜过少量依赖。”你大概已经猜到，我喜欢这种极简的做法：除了减少故障点，它还能让程序更小。

Python、Ruby、Java 和 C# 似乎介于两者之间：人们也会使用相当数量的依赖，但据我观察，大家会更谨慎一些，不会像 node_modules 那样失控。诚然，这么比有点不公平，因为 Python（以及其他这些语言）的标准库本身就比 JavaScript 的要丰富得多。

网站 YouMightNotNeedjQuery.com 展示了许多你以为需要库才能完成的任务，其实只用原生 JavaScript 就能轻松实现。例如，在我的一个项目中，我用下面这样的函数通过原生的 XMLHttpRequest 发起 API 请求：

function postJson(url, data, callback) {
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function () {
        if (xhr.readyState === xhr.DONE) {
            callback(xhr.status, JSON.parse(xhr.responseText));
        }
    };
    xhr.open("POST", url, true);
    xhr.setRequestHeader("Content-Type", "application/json");
    xhr.send(JSON.stringify(data));
}

故事的寓意是：在添加依赖之前三思。你会让网站和程序更小巧、更可靠，之后你会感谢 Russ Cox 的。

轻量的统计

大多数网站所有者都想要某种统计工具，来了解有多少访客、来自何处。首选工具是 Google Analytics：它易于设置，界面也相当全面。但代价是：它会给页面增加可观的体积（19KB JavaScript，未压缩 46KB），并向 Google 发送大量用户数据供其收集。

最近，人们对更小、更注重隐私的统计系统再次产生了兴趣。就在今天早上，我在 Hacker News 上读到一篇获得高票的、颇具挑衅性的文章，叫作“Google Analytics: Stop feeding the beast”。

去年我曾为 LWN 写过两篇相关文章，所以这里就不多说了：

• Lightweight alternatives to Google Analytics：用轻量、开源且注重隐私的替代方案来取代它，具体是 GoatCounter 和 Plausible。
• More alternatives to Google Analytics：一些更重的替代方案，并简要介绍了基于日志的统计工具。

本站使用的是 GoatCounter，它既提供低价的托管服务（非商业用途免费），也可自行托管。我非常喜欢 Martin 在这方面的尝试，以及这个工具的小巧与简洁：没有花里胡哨的功能，只有大多数人想要的基本流量数据。

小而精的架构（而非微服务）

小网站对用户有好处，而小架构对开发者有好处。小而简单的代码库易于维护，相比庞大、蔓延、交互点众多的系统，bug 也会更少。

我认为“到处都是微服务”的风潮是个大问题。微服务或许在 Google 和 Amazon 被成功运用，但大多数公司并不需要那样构建。它们在代码、API 定义、网络、部署、服务器基础设施、监控、数据库事务——几乎系统的方方面面都引入了复杂性。为什么会这样？

• 代码：你会有大量小型仓库，可能使用不同语言，每个服务都必须有与其他服务通信的方式（JSON over HTTP、gRPC 等）。而在单体系统中，一切都用同一种语言（对小团队友好得多），调用其他模块只需一次函数调用，系统级的重构也相对容易（尤其是在 Go 或 Java 这样的静态类型语言中）。
• API 定义：当许多服务彼此通信时，你突然需要标准化的接口来规范它们如何交流。你会花大量时间搭建 gRPC 或 JSON schema 定义。而在单一代码库中，函数签名本身就是 API 定义。
• 网络：在微服务中，一次函数调用就是一次网络调用，你需要花时间搭建网络基础设施，考虑超时与重试，甚至设计服务间认证。而在单体系统中，你只在与数据库、云服务商和用户通信时才需要担心网络。
• 部署：在我曾工作过的一家公司，一旦开始采用微服务构建，突然就需要花哨的部署工具和专门的基础设施团队来管理一切。如果你只部署少数几个服务，需要的东西会少得多。
• 服务器基础设施：你很可能需要搭建新的基础设施——大量小型虚拟机，或基于 Kubernetes 的系统。Kubernetes 本身就是一个复杂的分布式应用（连 Google 都承认它过于复杂），要让它正常运行需要大量工作——或大量资金。
• 监控：为了调试问题，你需要像 Datadog 这样昂贵的分布式监控软件来了解发生了什么。当故障发生时，你会手忙脚乱地去判断是哪个服务出了问题、该通知哪个团队等等。相比之下，单体系统中一个简单的堆栈跟踪或单服务问题就清晰得多。
• 数据库事务：在微服务架构中，这类事务很难实现甚至不可能实现。你或许能通过设计来规避，但那同样不容易。而在单体中，只需键入 BEGIN ... COMMIT，或按你的数据库库所规定的写法即可。

这话已被说过多次，但微服务解决的是人的问题，而非技术问题。但要当心 康威定律：你的架构会模仿你的组织结构。反之亦然——你将不得不招聘和重组，使公司结构去匹配微服务所需的架构：大量工程师组成大量小团队，每个团队管理几个微服务。

这并不意味着微服务永远是错误的选择：在庞大的工程组织中，它们可能是必需的。然而，如果你在这样的公司工作，你很可能已经使用微服务多年了。如果你不是“Google 级别”的规模，在照搬他们的开发实践之前应该三思。

那替代方案是什么？“单体（monolith）”这个词名声不佳，但我赞同 Basecamp 的 David 所说的单体也可以很优雅。Basecamp 本身就是一个大型的单体应用，他们仅用十几名程序员就能维护它。David 很快指出，“Majestic Monolith 并不假装能提供一条通往成功的万无一失的架构之路”。你仍然需要思考、设计并编写高质量的代码。

值得庆幸的是，人们正在从盲目崇拜中回过神来。只需搜索“why not microservices”，你就能找到大量相关好文章。我最近读过的一篇来自 Tailscale：Modules, monoliths, and microservices。

那么我的建议是什么？

• 除非你的公司叫 Google 或 Amazon，否则从单体开始。
• 一旦开始出现问题，就去优化或重构痛点。
• 如果仍有问题，就买一台更大的服务器。
• 如果有具体的技术原因需要拆分，那就解决那个问题。
• 如果问题依然存在，就只把需要拆分的组件拆出来。你将有两个服务需要部署和监控，但这比全面转向微服务要简单得多。

好吧，这段关于微服务的吐槽比我原计划的要多，就这样吧。

说到反例，Stack Overflow 再次浮现在脑海。他们是网络上最繁忙的网站之一，却拥有相对简单的两层架构，并通过垂直扩展——换言之，用配备大量内存的大型服务器，而非数百台小服务器——来应对规模。他们拥有 9 台 Web 服务器和 4 台非常强悍的 SQL 服务器，外加几台用于标签引擎、Redis、Elasticsearch 和 HAProxy 的服务器。这种架构帮助他们获得了出色的性能，并得以用小团队进行开发。

我自己的副业 GiftyWeddings.com 流量很小，完全无法与 Stack Overflow 相比，但它在一台最小的 EC2 实例 t2.micro 上运行着 Go HTTP 服务和 SQLite。每月费用约 8 美元，而且我只需维护这一丁点基础设施。我使用 Ansible 部署——这个工具本身就是简单架构的好例子，归结起来就是“直接用 ssh”。

说到 SQLite，越来越多的开发者主张用 SQLite 来支撑网站。SQLite 的“when to use SQLite”页面写道：“任何日点击量少于 10 万的网站用 SQLite 都应该能良好运行。10 万次/天的数字是一个保守估计，并非硬性上限。SQLite 已被证明可以应对 10 倍于此的流量。”以下是其他一些 SQLite 的成功案例：

• Litestream 是一个为 SQLite 提供流式复制的开源工具。请阅读作者 Ben Johnson 的文章 Why I Built Litestream。
• Go 开发者 David Crawshaw 写过一篇关于他所称“单进程编程”（使用 Go 和 SQLite）的文章，可以用他的一句话概括：“1 台电脑能搞定的事，就别用 N 台”。他还创建了一个 Go SQLite 库，比其他驱动支持更多 SQLite 特有功能。
• Peewee ORM 的作者 Charles Leifer 写过一篇文章“Five reasons you should use SQLite in 2016”，到 2021 年依然非常 relevant。文章结尾写道：“我希望你能尝试一下 SQLite。不要相信那些关于它不适合生产环境、或不适合用于网页应用的 FUD。”
• Crave Cookie 的 Sam Eaton 用单台服务器和 SQLite 运营着一家月入 20 万美元的副业（厉害！）。请阅读他的 Indie Hackers 访谈。

总结

公司自会做公司该做的事，继续制作外观花哨、臃肿但“转化率”高的网站。也许你能在工作中产生一些影响，然后回家对另一半说“亲爱的，我把网络变小了”。或者，你只是在个人项目中专注于小网络。（免责声明：我大多属于后者——在日常工作中，我参与的 Juju 按大多数标准来看都不是小系统。）

无论如何，我认为“小网络”是一个富有吸引力的概念，也是一种富有吸引力的美学。不一定是视觉上的美，而是那种你亲手搭建、完全理解、并运行在单台服务器或静态文件主机上的感觉。

有数以千计优秀的小网站范例，也有数百种创建简单架构的方法——本文仅触及了我所热衷的其中几例。我很乐意听听你的想法和故事！欢迎到 Lobsters、Hacker News 或 programming Reddit 上留言评论。