用了2年Obsidian,Logseq以前也知道并试用过,当时只有web版,稳定性差就没关注了。不久前看了Randy Lu关于Logseq的视频分享,被吸引到了,于是试用了2周。这期间只用Logseq,没用Obsidian。

现在,想基于经验分析下二者的功能差异及未来的可能的迭代方向。需要说明的是,这不是一个教程,但如果你正在试用这两个软件,并在犹豫选择哪一个,本文或许能提供一些视角。

这两个软件共同主打的特点是:本地存储+文本文件。这对在意数据安全、数据可迁移性的用户(比如我)来讲,非常有吸引力。

它们的核心差异点有两个:

  1. Logseq强制使用大纲视图,Obsidian是自由格式的markdown文档
  2. Logseq没有文件夹结构,Obsidian有文件夹结构。

一、首先讲讲自由格式与强制大纲带来的影响

Logseq强制使用大纲视图,其实就是block优先,先有block,然后block组成page,并且block还有层级的关系。

Obsidian自由格式,就是page优先,当它想去支持block的时候,只能从段落出发,每一段是个block,段落间当然也没有层级关系。(官方文档介绍:前后有空行包围的东西就是block)。

从通用性来讲,Obsidian的自由格式,其实兼容Logseq大纲视图。网上有很多人分享二者共用一个库的方案,无一例外的都是以Logseq库为准,然后让Obsidian去兼容Logseq,充分佐证了这一点。

以block为例,前方讲Obsidian的block是基于段落的,但大纲带也是支持的,如下图所示。

Obsidian和Logseq对比
Obsidian大纲中的反向链接

相比Logseq的block,Obsidian的block有两个问题:

  • Logseq能直接在反向引用中编辑和操作(比如点击链接)内容,Obsidian则必须跳转到原文档才能编辑和操作。
  • Logseq的#标签和[[]]引用,都是作用于块的,通过query能直接查询到块,Obsidian通用dataview的query只能查询到page。

尤其是第2条,对task的管理非常重要。事实上,dataview社区已经在计划实现相关功能了。

再看看Logseq,因为是强制大纲,所以不适合写长文,有趣的是,Logseq社区呼声第二高的Feature Request就是支持长文写作

这个帖子对Logseq应该如何处理长文block给出的建议,就是Obsidian基于段落的方案。

按照这个畅想,Logseq支持定义page的类型,一类是大纲视图page,一类是长文视图page。

长远来看,Obsidian在自由格式上支持更友好的block是顺理成章的事,但Logseq在现有强约束的情况下去支持自由格式的长文,需要打破框架。不清楚Logseq团队是否会考虑支持长文(目前roadmap中还看不到),但这确实是我无法放弃Obsidian唯一的原因。

我个人比较期待二者最后殊途同归,Obsidian更好的支持block,Logseq打破框架支持长文写作。

二、再谈谈文件夹支持

这一点,同样体现了Obsidian对Logseq的兼容。

至于哪个更好,这个见仁见智,我倾向于Logseq简化文件夹的方式,减轻分类的压力。Logseq的页面支持层级,可以实现类似文件夹的功能。但需要注意,这是非常定制化的能力,离开了Logseq这样的关系就丢失了,所以,如果考虑数据的可迁移性,这个功能应该慎重使用。

三、我最终的选择

我希望在笔记软件中写长文,Logseq无法完全替代Obsidian,虽然Obsidian的大纲能力比Logseq弱但也完全够用,所以本着少折腾的原则,继续使用Obsidian。但在使用习惯上,会把Obsidian中的daily note大纲化。

哪天Logseq支持长文了,会考虑迁移。也许那一天,Obsidian的block能力也能与Logseq并驾齐驱了。

最后,本文使用Obsidian写成。

相关阅读

标签: obsidian, logseq, 笔记应用, 知识管理

已有 19 条评论

  1. Peng Peng

    写的挺深入的,正在用logseq的我准备去试试obsidian看看。
    有个问题是,logseq的#和[[]]只能找到页面啊,不能作用于块吧?

    1. 是的,logseq的块只有(())

  2. hun ojo hun ojo

    当长文章作为出入链显示在某页面的下方,想想就摇头。
    logseq显示模式还是略显简陋。

  3. hun ojo hun ojo

    logseq页面下方显示出入链,通常不会折叠。
    当一或几篇不怎么分块(block)的长文章作为出链显示在某页面的下方,那酸爽。。。
    当下logseq的显示模板,太简陋,使得zhangw

    1. 这个可以在edn配置文件中设置,反链显示几层关系。默认显示了匹配块的子节点,如果有大量并列的子节点,就会造成你讲的现象。解决上:
      1、可以考虑设置不显示子节点,或者
      2、有意识的避开写大量并列子节点,我用这个方法,如果有大量子节点,一般会再分组,弄成孙结点,不会在反链中呈现。
      这个部分Obsidian确实处理的巧妙一些,有三个选项:只显示标题、只显示匹配块、显示匹配块的上下文。并且这三个选项随时切换,不用在设置中写死。

  4. 重度使用一年多ob了,最近被朋友安利logseq还在入坑,摸索到了这篇文章
    作者把特点和问题都梳理得好清楚!而且最后选择的解决方法也一致哈哈,还是ob为主,思考怎么兼容logseq一起使用
    希望作者对ob未来会改进块体验的畅想会成真!我也是觉得,如果ob现在着手改进块引用,其实也没有无法解决的障碍。把代码隐藏显示(像callout、表格那样做成及时渲染);把块和页解除绑定、每个块有独一无二的标识码,就差不多可以了

    1. ob的客户端迭代明显慢下来了,块的支持还看不到希望。Notion的数据库功能,倒是看到一些插件朝这个方向努力。

  5. 本地通过Notes记录碎片,而后整理成wiki或blog,这是我个人习惯。

  6. 哈哈,一直在用onenote

    1. onenote感觉特别适合手写,无限画布。

  7. 虽然没用过,但是还是涨姿势了

  8. 我用了很多笔记软件,个人看法就是没有软件可以做到all in one,无论是logseq、Notion、hepta等等,都有独特的地方,还是对自己的知识体系匹配相对应合适的工具。

    1. 是的,所以用了两个星期后,回到Obsidian了。还是越简单越好,习惯第一、工具第二。

  9. 反正我是选用了Obsidian,也有些不满意的地方,但基本上符合我的要求了。
    你的博文用 Obsidian 写成能否一键发布?

    1. 我是写了一个python脚本,在命令行算是一键发布吧。主要实现了:

      1、本地图片自动上传图床,并替换为图床链接
      2、本地博文的双链引用,替换为博客的链接引用

      刚转移到Obsidian时,写了一篇分享 https://www.skyue.com/20082317.html

      这个东西应该也能插件化,但我不会javascript

  10. Unee Wang Unee Wang

    都用过,都在iOS上最早体验了试用版,logseg都是可以有限的支持iOS与其他平台同步,方案就是建一个快捷指令,我有写过,但是,我博客服务器到期,国内的还没有备案。
    希望logseg能往本地化的notion方向发展

    1. 我向开发者申请了logseq的iOS测试版,但收到testflight测试邮件大概要等一星期,真的好慢😓…...

      1. 我申请大概等了一周,试用了,完成度挺高,感觉正式版不远了。

    2. 感觉Obsidian已经有Notion的大部分功能了,table可以通过yaml属性结合dataview实现。
      现在只缺一个page层级的能力,但Obsidian是文件夹结构,不太可能增加页面层级能力。

添加新评论