最近接触了 roam research，有了一些想法，就随便写一写。
- 我本人是一个比较喜欢记笔记的人，以前用纸笔，现在则是用电脑。我折腾过很多的笔记类应用，最初接触的是 OneNote，为知笔记，印象笔记这些，在线的则有博客园、CSDN。这些都可以理解文章式的，并且每个软件之间的内容格式(富文本)可能都还不是相通。后来流行了 markdown，这些应用也逐渐支持了 markdown，markdown 是通用的，都是纯文本，我可以通过程序一键批量处理；
- 博客类的后来喜欢折腾搭建自己的博客系统(同时也在更新博客园)，最早折腾过一段时间的 jekyll + github pages 形式的静态博客，后来又转为了 wordpress 用了很长一段时间，无意间又发现了基于 nodejs 的 ghost 博客系统，颜值特别高，用了很短一段时间后，但还是停不下折腾的心，自己写了一个简易的博客系统，很难看，参考了别人的样式，用了一段时间。
- 接下来遇到了 wiki 类软件，比如 mediawiki、tiddlywiki、dukuwiki，基于 nodejs 的 wiki.js 以及客户端的 zim，都尝试过，其中 mediawiki 用的最久。wiki 最吸引我的概念就是：积累沉淀、持续优化、链接引用，以及词条式，我想象着那种随着时间自己可以逐渐丰富起自己的 wiki 起来。用了一段时间之后，发现了几个问题很难解决，以 mediawiki 为例，①编辑完的内容比较零散，看不出结构来，因为 wiki 的思想就是词条式的，我以为我能通过关键的词条式记录把自己的笔记串联起来，实际上并没有。②沉淀的思想，换个角度就是不那么灵活，页面编辑有点死板，你必须持续的优化文章的结构。换句话说，如果你想在 wiki 上记录心情日记之类的比较碎的东西就很不适合了。wiki 总是给我一种可以不断积累完善自己，但又很死板不灵活的矛盾。当然 wiki 类的应用普遍有一个优点就是本地化数据存储，可以本机搭建环境，不论基于数据库、基于文件的都还不错。用 mediawiki 搭建自己的博客，以及日常的笔记之后，又折腾了 wiki.js，用它是因为可以用 markdown 写，也支持 wiki 的
[[]]链接。 - 后来买了 mbp，发现 mweb 这个 markdown 编辑器兼静态网站生成发布器，我把我的所有文章放到 mweb 中，然后应用一个模板就可以自动生成一个网站了，写了一个脚本自动打包上传到云服务器，省事多了。关于博客，用了它之后，至今就没再折腾过了。还是简单好啊，简单才能长久。mac 还有一个很好的记日记的应用 day one，用它也记过一段时间的日记。
- 至于笔记类的折腾，弃用 wiki.js 之后，我可能对别人开发的笔记类应用死心了吧，以上每折腾一遍几乎就要迁移一次数据，真的很累，我就仅用文件目录 + vscode 吧，简单明了，而且 vscode 搜索也很方便，markdown 预览插件也很给力，其实已经很好了，唯一的缺点就是不能所见即所得吧，得额外预览界面才行，唯二的缺点则是文件目录组织本身的缺点吧，文件内链接只能使用 markdown 的链接，比较原始，而各种应用呢，肯定会提供这个额外的功能。
- 去年不知道从哪接触到 notion 这个工具，功能异常丰富，异常简洁，所见即所得，直接就可以分享、引用，当时惊了我一下，立刻停止不住折腾的心，把很多数据又搬运到 notion，特别是折腾过它的 database 的功能。后来不知怎的，网络抽风了，于是就去寻找国产的有没有类似替代，还真的有，那就 wolai 了。除了没有 database 的功能，其他的功能都很好用，于是又把所有数据迁移到 wolai。现在我记录的主力工具就是 wolai。以为可以就此安心了。
- wolai 一切都已经很好了，在中文本地化上面已经很好了，wolai 对界面 ui 做的更加人性化，是从正常用户使用的角度去不断优化的。但我总是还是觉得有点不太对的感觉。在 wolai 上面，已经支持双向链接，但我依然从体验上感觉是文章层次的链接，块链接和块引用也有，但体验的不明显。我感觉，wolai 更适合也更容易创造出好看的页面，好看、结构清晰的笔记。还是那种富文本的笔记，或者说各种块组合搭建的笔记。很少产生知识联结这种感觉出来。直到我尝试了 roam research(以下简称 rr)，才明白那种感觉是什么了。
- rr 其实我早在接触 notion 的时候就知道了，但是一直没有尝试。最近尝试了之后，我才真切地感受到它与其他笔记应用的真正不同。也许是这类软件的最早的、也是最强的软件之一，后面我会把其他的类似的笔记应用归类于 roam like 应用。
- 下面就着重描述一下我用 rr 时的一些感受。①首先，最直观的感受就是，一切都是基于文本的，让人有一种大道至简的感觉。而它这个文本在 web 界面编辑时却是可见即可得的。当你在当前行编辑时，显示的都是纯文本，然后脱离当前行时，它立即就渲染成相应的样式，这个体验非常好。编辑时专注于文字内容，阅读时专注于信息本身，完全不需要 vscode 那种预览界面。当时客户端软件 typora 也能支持这种效果，或许做的更好，但是它仅仅是一个本地的 markdown 编辑器而已。②
[[]]与(())之类的块引用语法，以及#tag之类的标签语法，可以发现它们在编辑时也是都基于文本的，看起来特别清晰，这一点就是 wolai 中感觉不对劲的地方，在 wolai 里面也有页面应用和块引用，语法也是基本一致的，但是你却不能直接输入[[]]就能达到效果，必须要通过菜单去做，而且你看到的也是渲染后的页面，rr 中一切都是纯文本的好处一是清晰，二是可以复制，而且你很清楚你复制的是什么，在 wolai 中复制一段文本可能就带上了一些特殊的你看不见的标记。wolai 从用户体验角度出来，优化了很多显示和输入上的交互方式，提供了很多丰富的菜单，所以它的页面现在就比较有设计感，美观，但是对于我这种对记录、文字有洁癖的人来说，就感觉隔着一层，你不知道你记录的东西到底是什么。③ rr 中的引用在被引用页面也是可以编辑的，其实就是原来的被引用的页面。而 wolai 只是把被引用页面展示出来，还没有做到可以编辑的程度，这可能也与 wolai 发展的方向有关，它的主要竞品应该是 notion。并且被引用的页面里面也是纯文本风格，其实整个 rr ，无论哪个功能都是基于纯文本的，这我就很爽。当我复制导入导出的时候，可以最大限度地保留信息。④ rr 的块粒度细，很彻底，每个块点击都是页面，写起来让人逐渐放下了对于页面、段落的固有习惯，只需要记录即可。随时可以扩展、组合、拖动、引用。这种细节上的感觉很重要。 - 但是 rr 也不是没有缺点的，以上对比 wolai，说明了 rr 的特点，下面说一下目前的明显的缺点：①在线数据，安全性和隐私性的问题，笔记这种数据，掌握在别人的手里始终是不安全的，无论它们声称自己有多安全。② web 应用在无网络时无法使用的，数据并不是可以完整导出的，还是基于前一点，你的数据总是绑定在这个应用上面的，而这个应用又不受你的控制，无法预知的风险。③访问网络不稳定，收费比较贵。
- 国产的类似 roamedit，在功能上紧跟 rr，除了稳定性还差些，网络访问上会好一点。后来我发现了 logseq，这也是一个roam like 应用，它其他功能也是紧跟 rr，最大的不同在于它只是一个 web 应用，数据全部在本地，它通过读取本地数据，初始化到浏览器环境的内存数据库上，同样实现了 rr 的体验上的功能，并且数据还存在本地。它的数据格式是 markdown 或 org-roam，都是文件式的。文件有个好处就是以后 应用不在了，可以继续用 vscode 之类的编辑器继续编辑，其实就是我之前的
文件目录 + vscode形式的 web 应用版，即文件目录 + web app。理论上这已经很好了，logseq 我还没有深度体验，但是我预感很多功能可能并不能很好的实现的，因为 rr 中每个块都是独立的，引用时也很快速，但 logseq 可能就要加载整个文件才能得到某个块的信息，随着文件数量的增多，性能会下降。所以我还是倾向于后端用数据库存储。 - 还有一类软件是客户端软件(remnote、obsiden)，对于这一类，我总体是不看好的，客户端软件有很多制约，当然也有很多伪客户端(基于electron，本质上还是封装的网页)，客户端软件很难不把自己的精力放在处理各端具体细节上，以及为了统一而做一些折中。rr 带给我的 web 体验是极好的，我也觉得目前的 web 技术完全可以胜任笔记类的交互。
- 最后，说一说我的对于未来笔记类应用的想法吧。
- 我希望它是基于 web 的，这样可以最大限度的保持统一的体验。
- 我希望它是基于文本的，而一切的「对象」都是可以在类似
/的提示中出来，如果是一个文件对象，那么文本内容可能就是一个文件地址，如果是一个手绘图对象，那么可能就是一个手绘图的引用地址。 - 我希望它的后端是基于数据库的，目前来看rr 和 logseq 后端语言都是 Clojure，支持图数据库，这是一个值得学习的语言啊。
- 我希望它的数据可以完全存在本地，提供一个类似于 mamp 或者 lamp 这样完整环境包或者 docker 镜像，包含了所有应用环境和数据，一键安装即可使用，一键文件备份即可。设想在云服务器(拥有独立 ip 和域名)上搭建一个实例，用于日常多端协作。在本机也搭建一个实例用于备份，远程主机和本机之间可以设置自动同步操作，这样无论在哪边进行了修改，都可以立即全量同步。
- 可以对
/有更多的想象力，既然支持了本地数据，那么是不是可以把原本属于系统的文件管理功能全部拿过来呢。比如/生成一个音乐仓库类型的对象，用于上传、管理你的所有音乐，并且/生成一个音乐播放列表的功能。反正数据都是在本地，调用是很方面的。现在的/的功能尽管丰富，但也很浅显啊。