关于 roam 类笔记应用的一些想法

最近接触了 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 和域名)上搭建一个实例,用于日常多端协作。在本机也搭建一个实例用于备份,远程主机和本机之间可以设置自动同步操作,这样无论在哪边进行了修改,都可以立即全量同步。
    • 可以对 / 有更多的想象力,既然支持了本地数据,那么是不是可以把原本属于系统的文件管理功能全部拿过来呢。比如 / 生成一个音乐仓库类型的对象,用于上传、管理你的所有音乐,并且 / 生成一个音乐播放列表的功能。反正数据都是在本地,调用是很方面的。现在的 / 的功能尽管丰富,但也很浅显啊。

转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 jaytp@qq.com