logseq 支持 publish功能, 可以把用户的本地笔记打包成一组 css/html/js 的静态网站
理论上来讲用户可以把这些文件丢到 S3 或者 Cloudflare 里，得到一个博客
听上去使用该功能快速搭建博客很有吸引力
但在深度使用 logseq 两年，并使用publish发布博客大概两个月后，我觉得 logseq 非常不适合做 blog
这篇文章里简单讲讲我的看法
为什么要搭建 blog
撰写 blog 的目的多种多样，例如
- 分享有意思的知识
- 打造个人影响力
- 为某些服务或产品打广告
- ... 为了满足以上目的，除了易用外我们对博客系统可能还有哪些需求？
- 能够被公开访问
- 能够被推广
- 能够显示多样的内容，比如
code，图表甚至于一些可以交互的小组件 - 方便查看被访问情况 目前来看，logseq 生成的网站仅能够支持“能被公开访问”这一点，其他的点做的都很不好
技术视角下为什么 Logseq 不适合写 blog
-
渲染方式
- logseq 不适合写博客的根本技术原因是选择了CSR这一技术方案
- CSR 导致生成的网站访问性能很差，SEO 很难
-
给不熟悉前端生态的朋友贴一个前端渲染方式概要
- 对于 Blog 来讲， SSG 和 SSR 都比较适合，而使用CSR做博客是非常非常坏的主意
-
访问性能差
- CSR 的特性决定了，在 JS 加载、执行完成之前，用户什么有意义的内容也看不到（白屏）。
- logseq 生成的网站至少要在加载一个大约 3MB 的 js 文件后，用户才有可能看到有意义的内容
- 感兴趣的朋友可以
F12按开开发者工具，在禁用缓存的情况下刷新一下当前页面，感受一下加载延迟 - 如果一个博客需要好几秒甚至数十秒才能加载完毕，可能会失去很多读者
-
SEO
- 在CSR网站上做 SEO 相当困难
- 搜索引擎无法有效索引 CSR 的内容，不支持 JS 的爬虫只能看到CSR网站中的空白页面
- 少部分爬虫，比如 google 的爬虫，会解析 CSR 网页，但是会显著降低 CSR 网页的权重
- 另外，
meta-tag是 SEO 中比较重要的部分 但是 Logseq 并没有提供控制导出页面meta-tag的方法 - 如果不能被搜索引擎有效收录，那写博客
被看到这个需求就比较难被满足 -
分享
- 缺少对
meta-tag控制的能力也导致 logseg 博客无法在社交媒体上被渲染成好看的卡片 - 此外 logseq 的 URL 在有中文的时候，又长又丑，缺少使用拼音做 path 的能力
- 综上，logseq 博客中的文章很难被漂亮的分享
-
-
功能扩展
- publish 后的网站不支持使用 logseq 插件系统，因而能展示的内容大大受限
- 比如在安装了某个插件后，logseq 客户端可以直接把#mermaid 代码渲染成图片，如下图所示
- mermaid code block below:
flowchart TB A --\> C A --\> D B --\> C B --\> D ``` -  -  - 但是由于这个插件不能运行在浏览器中，因此在发布后的页面中看不到渲染完的
mermaid图表 - 再比如通过插件功能，我可以在本地客户端获得一个好用的目录, 固定在页面右上角。
但是我无法在发布后的博客中增加这个功能
- 目前我们可以在 logseq 的初始文档中手动插入一些脚本来实现额外的功能 （比如本页面最下方的基于 giscus 的评论系统，本站的 google analyticals 集成等等） 但是对于一些复杂的需求，我们没有任何简单的办法扩展 logseq 发布后的网站。
- 我在此列出了几个我很想要，但我想不到怎么做到 logseq 里的需求
- 目录
- i18n（发布文章的双语版本）
- 发布部分公开的文章（比如一篇文章只有拿到了特殊的链接才能访问）
- 显示文章的预计阅读时长
- 自定义文章的 URL（或者对中文 page 支持拼音 URL）
产品视角下为什么 Logseq 不适合写 blog
整体来讲，我认为 logseq 最适合用来记录 一句~几段 这种长度的文字 一句话记录：捕捉在工作 or 学习中的一些灵感
- > 跑题：解决这一需求的另外一个产品是#Flomo 笔记，但我觉得他和 Logseq 的使用场景很不一样 中等长度文字记录：将一些零散的笔记碎片整理成初具雏形的文字段落。
- > 我认为 logseq 恰恰就是在这个场景下非常出彩。双链、插件、page embed 等 logseq 提供的种种功能都能很好的帮助我解决碎片化想法的整理过程。 长文本记录：对于处理博客这种相对较长的文字，我认为 logseq 并不是特别合适的工具
- 实际上我觉得 notion、affine 等等等基于 block 抽象的编辑器都不太适合写长文。 这是一种直观的感觉（或者偏见），maybe 是因为我认为长文的分段需要依靠逻辑，额外增加的 block 维度拆分会有一些心智负担。
Logseq 博客还有救吗
写这篇博客前，我已在尝试改进 logseq 的 publish 功能，比如下面的 PR 支持了用户在 config.edn 中进行 publish 配置，注入脚本或定义生成网站的全局 meta-tag
- feat: make published html scripts configurable by CNLHC · Pull Request #11149 · logseq/logseq (github.com) 进一步思考和阅读 logseq 代码后，我得出的结论是：logseq publish 做博客没救了 第一，有关渲染方式
- SSR 和#SSG 对博客比较重要
- 目前整个 logseq 都是 CSR 范式写的，代码中充斥着直接对 DOM API 的访问
- 即使 logseq 的核心代码可以整理成 SSR 的范式，但是在 cljs 生态下实现一个生产可用的 SSR 难上加难。
cljs生态下并没有成熟的 SSR、SSG 解决方案，logseq 使用的rum（clojure 中对 react 的封装）仅支持最基本的 SSR，处于一个刚刚能跑的状态。 第二，有关功能拓展 - 目前来看 logseq 团队似乎并没有支持将插件 publish 出去的计划，看情况未来也不会有 第三，有关产品设计思路
- logseq 的定位是高质量的个人知识管理工具
- 提高 publish 网站的质量似乎并不是 logseq 开发团队的高优先级任务 但是用 logseq 的内容做博客也许还有救 一些插件在试图绕过 logseq 的 runtime，直接把 markdown 文件渲染成静态网页（比如sawhney17/logseq-schrodinger) 考虑到 logseq 在 markdown 文件中引入了相当多的非标准语法，而且最近 logseq 团队也在推进 databse verison 功能，对 markdown 格式的支持可能还会有变，现阶段我认为用这种方式实现比较好的用户体验的难度也不低。