在2024年02月27日我写下这样的想法：
当前的数字花园（注：指旧的那个）是基于 Node.js 版本的 TiddlyWiki，从2023年1月31日启用至今，我高强度记录并不断整理。但是在这个过程中，我向许多站点学习，其中包含各种各样的引擎，从使用相同引擎的 TiddlyWiki 到 DokuWiki，从 Notion 到各种静态网站生成器，直到发现 Quartz，它的美丽一下击中了我。它与 Obsidian 和 GitHub 的完美结合与发布使我陷入沉思：离线本地写作，然后整理发布，这个流程既有博客时代的传统又有数字花园流行后的高效。
Node.js 版本的问题在于速度。因为机制所限，它的访问速度必然随着内容的增加而不断变慢。我深知自己的产出（不论有价值与否）不会使得那一天很快到来，但是这个机制带来的缓慢和 TiddlyWiki 本身的复杂性使我常常思考是否使用一个更加传统的容器承载我的输出。我已有一个博客遵循草稿 - 写作 - 修改 - 发布的传统流程多年，但是新的形态总是吸引人的。Quartz 本身是一个静态网站生成器，它最慢的过程在于发布这个操作；TiddlyWiki 随时线上修改，即时生效，但是每一次访问都躲不开几秒钟的强制延迟，以至于我在 LoadingScreen 中调侃“网站正在缓慢加载中”。换句话说，TiddlyWiki 面向作者，解决的是内容迭代问题，Quartz 面向读者，解决访问速度问题。后者的官方文档介绍的 hosting 方式之一是 Cloudflare，部署和更新均十分简易，速度很快，体验上是 Node.js TiddlyWiki 无法比拟的。
另外一方面是内容组织。TiddlyWiki 本质上是卡片笔记，一张张 Tiddler 集结成内容，组织和管理十分复杂又灵活，对于私人笔记而言是一个非常有效率的工具，但是作为一个公开的内容发布站点，这样的形式似乎不太能带来较好的体验。我热爱的那些大多数基于 TiddlyWiki 站点，除了内容本身吸引我以外，很大程度上还是因为我喜欢 TiddlyWiki 的本质和它带来的内容展现形式。对我成立，但对于大多数读者我想是不太成立的。因此我总有建立一个 Quartz 站点的想法（已经付诸实践，但未实际应用），也许能有更好的 longevity。
转念一想，我好像不小心陷入效率工具陷阱了。
现在一年过去，Node.js TiddlyWiki 加载慢的问题仍然没有想到好的解决方法，甚至有时我自己访问时也会被龟速折磨得烦躁不已。我目光继续投向 Quartz，发掘了不少优秀的站点，例如 Quartz 作者的 jzhao.xyz 和近期发现内容丰富又深刻的 The Quantum Garden。遇见后者是我想要真正建立 Quartz 站点的契机。
根据我以往的经验，迫使我自己走上这条路的方法，便是在旧的站点声明暂停更新，告诉几位朋友我要换站点了。提高他们的期待，自己自然会开始担心，然后开始推进。
我阅读过原来的数字花园 仿生猫不会梦见电子猫粮，两年出头的时间使用下来，其中可以算得上“知识”的内容占比少之又少，到了后期更多的是对于某个页面或列表的持续性更新，例如看过的影视剧、听过的音乐或书籍笔记，还有各种对调整样式和功能的记录。从这个角度出发，这个数字花园早已违背它创建时所要达到的定义/初衷：
- Topography over Timelines 拓扑结构优先而不是时间轴
- Continuous Growth 持续增长
- Imperfection & Learning in Public 非完美的、公开学习
- Playful, Personal, and Experimental 有趣的，个人的，实验性的
- Intercropping & Content Diversity 套作（混合耕作）和内容多样性
- Independent Ownership 独立所有权
我既坚定保留时间轴结构，也没有持续生长或公开学习，只做到了独立所有权，套作和内容多样性，个人和实验性，也许再加一点趣味。花园如今已杂草丛生，疏于修剪，对于自己和他人已经逐渐失去他的观赏性和意义。因此想要结束这个项目的想法越来越深。丢不下这个花园的主要理由还剩几个：
- TiddlyWiki 哲学的美妙；
- 沉没成本
- 方便记录
- 域名的强关联
- 存在一些数量的搜索引擎索引。
仔细想想，其实以上没有什么不能舍去的，有些可以转移，有些没有保留的意义，只需要那么一个契机，让我放下执念，走上新的航线罢了。
仿生猫会梦见电子猫粮吗？
仿生猫不会梦见电子猫粮。
仿生猫梦见电子猫粮。