震惊！！！我以前折腾 R Markdown 的时候，喜欢把它几乎所有的功能都用在一个文档里，今看到 Frank Harrell 大人用 quarto 写博客 R Workflow 满足了写博客所有的想象，真想再搬一次家， Quarto 太符合技术写作的要求了！

Cloud2016 我要是能腾出几周时间把前年掉的 hugo-prose 链子接起来，要实现 Quarto 网站那些功能也不难。其实 Quarto 网站也正是借用了 hugo-prose 主题的一些功能（比如边栏的利用）。如果目的只是博客，我觉得可以不必搬家。单页面的功能上，Quarto 确实做了很多有助于技术写作的工作；但整站方面，它肯定是比不过 Hugo 这样的专业建站工具的，至少还会有很长一段路要走，还有很多轮子要重造。而且编译速度估计也几乎不可能赶上 Hugo。用 Quarto 的优势在于同一个功能很可能对任何输出格式都通用，但也不是所有功能对所有格式都有效，例如多个标签栏肯定就不能在 PDF 中用（PDF 不可交互点击）。若只考虑输出网站格式而不考虑其它格式，那么很多功能实现起来都只是几行 CSS 或 JS 的问题（就比如超宽图片），并没有它们看起来的那么难。就看你对技术写作的要求到底有多少了。我觉得用 Quarto 建网站的一个比较大的问题是网站主题样式的自定义空间相对较小，因为它抱紧了 Bootstrap 的大腿，样式的扩展性有限（改改颜色、调调字号什么的，而元素布局方面不太容易改）。用 Hugo 就不会受这个限制，可以从根基全盘重新定义模板，可定制性要强得多。所以在你决定搬家之前得想好了：Quarto 肯定会火的，到时候你再看自己的网站与其他八百人的网站看起来大同小异、辛辛苦苦搬家又把自己搬成了一个分母，会不会再次心生搬家的念头呢？我几周前写了一篇日志谈 R Markdown 用户要不要搬 Quarto 的问题，我的建议是所有人都可以尝试，但 xaringan 和 blogdown 用户可以考虑按兵不动，因为 Quarto 不大可能成为它们的超集，它们还会保留它们的独特性。

hugo-prose 的潜力很大，如果我需要一个对于技术排版需要比较多的网站，大概会以 hugo-prose 为基础进行魔改。有了 distill / radix 的前车之鉴，我对由 R Markdown 驱动的 SSG 框架基本保持怀疑态度：虽然解决了基本的建站问题，但是可定制性不高，需要填的坑太多。而且这种可定制性不仅仅受限于 Bootstrap，而是根植于模版机制和渲染流程。由 Hugo 这种 generic 框架驱动的就没有这些问题。 Quarto 的产品和营销策略我觉得倒是可以学习一下，比如如何在自己的平台上强推自己的框架：在安装包捆绑分发 binary、在 UI 上着重突出显示自己的内容、最小化显示第三方内容…… 😂

nan.xiao 从我使用的经验，我看好 VS Code ，只要它把无法复制 VSCode 预览窗口显示的文本的问题解决，我就以后都用它来写技术博客，换了后有一身轻松的感觉。 yihui 通用确实吸引我，因为我有一本技术笔记，还有好些技术博文，希望以后互相搬迁起来比较方便，也许未来某一天还可以写书，这样通用，特方便。对技术的要求，我仔细看了 Frank Harrell 这篇博客，完全满足了要求，即使未来发现不足的地方，那它也搞完了 99% 的活。对用户来说，只想用它把活干了，不想知道太多深度定制的活，以及怎么干的，因为用户想把大把精力放在博客内容上，特别是技术博客，有很多技术性的东西足够消磨我工作之余仅剩的精力。交互式点击类的活，网页上可以搞，PDF 可以弄成分栏对比或者干脆重写一段，反正应该不多。几年下来，我对网站样式没有多少要求，简洁，主题足够简单，我前段时间把博客搬到最普通的最原始的主题 hugo-lithium ，不太想折腾太多和网站相关的内容，精力有限，只想把博客内容做好。其实，我倒是觉得 Quarto 正是抓住了这些点，把常用的功能都做好，告诉用户怎么调用就好了，不需要用户自己去实现，尽管在忍着🥷们 nan.xiao yihui 看起来这有点 low。可作为一款产品，它设计之初就是为抓住大部分普通人而服务的。我暂时只是想把博客搬到 quarto 上，还没有既成事实，担心的点有以下几个：搬迁成本有多大？Rmd / md / Rmarkdown 三种格式源文档怎么搬过去？想坐等一些人的体验 Quarto 渲染站点性能怎么样？比 Hugo 慢的话，会慢到什么程度？ Quarto 发布 1.0 版本后，稳定性怎么样？这需要观望一下！

我目前主要用 Quarto 做学习笔记和数据分析的小项目, 体验非常好. 作为产品, 它的优点可以这么概括: 默认配置抓得很好. 我就是用它的默认配置, 几乎不需要怎么调试. 简洁美观. 本能地想用它做笔记. 跨语言. 比 Jupyter 更像 Python Markdown. 不过我目前都是用它 book 的配置, 没写过博客.

被大家说得好想试试，但还是把好奇心强压了下去……

Cloud2016 对技术的要求，我仔细看了 Frank Harrell 这篇博客，完全满足了要求，即使未来发现不足的地方，那它也搞完了 99% 的活。可以具体讲讲你的技术要求吗？哪些是你需要的 99% 的功能？我看到的有：左侧固定位置的目录（随滚动自动高亮相应章节）、左右边栏内容、超宽内容（包括图片）、可折叠的内容（包括代码块）、标签页、Hypothes.is 标注。还有哪些是你需要的？ Cloud2016 对用户来说，只想用它把活干了，不想知道太多深度定制的活，以及怎么干的，因为用户想把大把精力放在博客内容上是的，理论上是这样，谁都不想折腾，不过我那篇日志里引了一幅图，我觉得还是看穿了不少人的内心的： https://rakhim.org/honestly-undefined/19/ 那就是，我们总是嘴上说不折腾，但一旦看到了折腾的可能性，就很容易把新的灯泡放到嘴里，然后分享这种激动和喜悦，所以那幅图说的是博客写的多的人，基本上都不追工具，而追工具的人，博客数量相对少、而且很多博客的话题还是关于博客工具如何使用的，而不是写他们初心的内容。Quarto 肯定不是终点，软件一般都是各领风骚三五年（Quarto 领二十年应该没问题）；若下一轮风骚再来了，我们确定会不继续折腾吗？前些天当我在隔壁看到 @lijin 说“ 应该可以让我很多年都不会想换网站皮肤了 ”我就一乐，并且开始掐表，因为我感觉我很少看到能忍住不换皮肤的人，我自己都觉得难忍，我想看看这次是不是遇到了一位神仙（五年内不换即可封神），毕竟人类的新鲜感都是难以持续的，惊鸿一般只能存在于一瞥中，瞥完还是一只肥大雁。 “只想把活干了、把精力放在内容上”让我想到这位老大： http://www.paulgraham.com 说实话这网站我看着非常费眼（字太小、页面太窄），但还是挡不住我看，因为他几乎纯凭纯文本把活干了。当然这不是典型的“技术性博客”（主人是技术出身），因为很少见到代码，他只是用内容表达了他的思想。对你的博客来说，内容相当棒，我个人觉得其实只缺一样功能，就是目录，因为你有一种把天地掏空的写作风格，写得相当全面，就不可避免会写得超级长，读者容易在里面迷失方向，不知道读到哪里了。要是能加个目录，我觉得会减轻不少读者的压力。我不懂游戏，但我上大学时看宿舍里的人打魔兽世界，屏幕左下角总是有一幅战场缩略图作导航，我觉得你的文章就缺这么个东西。 Cloud2016 尽管在忍着🥷们 nan.xiao yihui 看起来这有点 low。并没有……这个词好像不太可能从我嘴里出来吧，年少轻狂时也许会这样评判别人，但现在肯定不会了（反而非常反感用这个词评判别人）。 Cloud2016 搬迁成本有多大？应该不大，Quarto 兼容 Rmd，不需要对内容作任何修改。但有可能代码需要重新跑一遍，我不太确定。 Cloud2016 Quarto 渲染站点性能怎么样？比 Hugo 慢的话，会慢到什么程度？它默认应该不会渲染全站，而是只渲染当前文件，已经渲染过的旧文件都不会重新渲染，所以速度应该不会太慢。尤其是对小网站，速度可以不用考虑，与 Hugo相比可能也就是 1 秒跟 10 秒的区别。你可以自己测一下。 Cloud2016 Quarto 发布 1.0 版本后，稳定性怎么样？七月开 RStudio 会议会正式出柜出道，也就意味着理论上稳定性是值得依赖了。

yihui 还有哪些是你需要的？暂时还想到三个，尽管我知道这些功能可以自己仿照、网上找材料尽力去实现，但是对大部分用户来说，太难了，对我也很难。有的表格比较宽一点，是否也能像超宽图片那样，突破正文的宽度？是否可以加一些注意、提示、警告之类的 block？是否可以支持 utteranc.es ？是否可以支持分栏，比如双栏？是否可以支持某篇博客根据需要加载数学公式？是否可以支持自包含的模式，一个篇文章一个大 HTML ？类似 Frank Harrell 大人的 R Workflow 文章是否可以支持 PNG 图片优化压缩？是否可以在参考文献后支持附录？我倾向于让每一篇博客独立起来管理，让博主们一心往前创作，一旦写完就不用担心新博客还和旧博客有任何技术上的交叉影响，甚至包括图片。比如，我之前想把博客图片全放在一个全局位置，后来，下定决心一定要随博文一起，不用 Github 图床是因为我想以后复用起来方便，也怕万一 Github 不让用了找不回来了，还有墙的问题，出现问题可以一股脑全搬去新图床。是否可以支持到这样一种程度，就是像 Quarto 那样，还有个帮助文档，基于某个博客主题（比如 blogdown 书里介绍的 hugo-lithium ），把这些功能的使用详细介绍一下，用户只需要照着弄就好了。Hugo 主题其实不需要太多，感兴趣有能力的人自个定制去，咱们是否可以提供一款主题，这款主题能覆盖 99% 常用功能，并且持续打磨以提高用户体验。至于怎么做的可以在高级定制篇里介绍，属于可选项。若能从零开始介绍如何制作一个这样的博客主题，就更好了！这样，小白、菜鸟、忍者等用户都覆盖了。我曾苦口婆心劝 @yuanfan 学习一下以 Rmd 格式给统计之都主站投稿，她那些饱含交互图形的文章最适合了，她坚决不干，说是 blogdown 太复杂了，太难了。我原想自己动手弄一两篇 Rmd 格式文章，后面大家可以照葫芦画瓢，目前看来，还有不少困难。我前段时间简单尝试了 Quarto 有种立马被吸引了的感觉，它好像吸收了 R Markdown 很多精华，很多用户常用的功能都打磨得很好，解决了很多痛点。比如 Quarto 会支持多种格式的幻灯片 HTML/pdf，通用性就是解决一大痛点，一套语法适用很多种输出，Pandoc 加一堆 lua 外挂（以及 TS / JS）实现用户常用功能。还支持那些博客写得多的人，方便他们写书。这样喜欢折腾主题，博客写得少的；时间不富裕，博客写一般多的；有恒心持续写博客，写很多的人；他们都有自己的出口。所以，我也相信 Quarto 这款产品将来肯定是会流行起来的，至少在 R 圈！最后，关于我的博客，确实文章很长，有好处也有坏处，可能我首先是满足自己需要，尽管博客网站对外公开，但首先还是面向自己，满足自己。目录确实是想要加的，Rmd 渲染出 md 格式加不了， Rmarkdown 渲染出 markdown 能加， Rmd 渲染出 HTML 能加，一篇文章想要加个目录竟然和源文档的格式有关系！从用户视角，这就有痛点。另外希望最好支持一种方式就是 Rmd 渲染出 HTML，当然可以支持 md （只要用户自愿放弃一些功能），希望把各种支持怼到一种格式上。技术写作方面，总结起来，是我最喜欢的一句话： Do one thing, and do it well! Quarto 潜力巨大！可能上面言语中有不妥的地方，冒犯之处还请见谅！

我不知道 yihui 有没有在公共场合做过调查，Hadley 之前在 twitter 上问大家长宽格式转化操作函数，应该取什么名字好？最后 pivot_wider() / pivot_longer() 胜出，我是觉得这个调查是非常成功的。关于 blogdown 产品，是否也可以罗列一个功能单子，收集一些大家的反馈？也许需要一个出口，让不同的声音发出来，这样产品会更好。以上都是个人愚见，仅供参考。

最后，关于「技术写作」这个产品，上面已将用户划分了三类喜欢折腾主题，博客写得少的时间有限，博客写得一般多的有恒心持续写，博客写得多的这三者前提都是做内容的，即使介绍怎么折腾主题的，介绍工具怎么使的，也有助于技术写作。还有一类没啥内容，或内容没啥价值的，也算上。四类人能促进技术写作生态发展壮大的就靠前面三类人。工具如何能帮助那些有价值有内容的输出的人更好地创作是工具最大的价值，写完了感觉是句废话，😮💨

原来湘云视角是这样的啊，哈哈，容我偷着乐一会先。你老早提过的那些，包括 Alison Presmanes Hill 的博客我也去翻过了，但是总觉得有些让我搞不懂的、很关键的地方被当做默认已知的常识一笔带过了，我也确实没看懂。

Frank Harrell 用 quarto 写博客

yihui

Cloud2016 把天地都掏空的写作风格挺好的，读者只需要收藏或记得一个页面，可以随时回来查阅。

上面 Cloud2016 的反馈极好，我需要更多的时间消化；目前来看，你的那些需求并不是很复杂，可以不必依赖 Quarto 实现的。等我有时间了会把掉的链子接起来。

Cloud2016

yihui 等我有时间了会把掉的链子接起来。

期待，那我就没有搬迁动力了，毕竟搬家要花不少时间 😄

Cloud2016

Cloud2016 3. 在主题 hugo-lithium 下，已经把 disqus 换成 utterances 评论系统，详见我的 repo，有需求的坛友可以照葫芦画瓢 😄 。

lijin

Cloud2016 已经把 disqus 换成 utterances 评论系统，详见我的 repo，有需求的坛友可以照葫芦画瓢

提上日程，抽空去抄一下 😄

yihui

lijin 对新起步或评论还不多的网站主人，我个人强烈建议早日弃用 Disqus，投奔 utterances 或者 giscus（我感觉这二者中后者在功能上更好一些，但相对新一些，所以我还不知稳定性到什么程度了）。Disqus 太笨重，会加载一大坨脚本和资源，还有一些视觉垃圾，就更不必说墙内用户无法用了。

Cloud2016

Cloud2016 6. Python 版 plotly 用起来，没有生成很多的本地 JS 文件（副产品），通过看渲染出来的 HTML 发现，里面是直接引用 CDN 上的 JS 库。一篇介绍 Python 版 plotly 的文章动画制作与 Plotly Python，还有其它方面，整体感觉 Python 版要比 R 版好太多了。

yihui

Cloud2016 这是我好几年前就跟厂里的人建议过的，但他们没有采纳。把所有 JS/CSS 文件本地化的好处显而易见，可以让用户在没有网络连接的情况下继续用这些包；坏处就是如果经常用 HTML Widgets 的话，就会生成大量冗余文件，浪费空间。其实 HTML Widgets 也不是不能用 CDN 资源，只是厂里带头选择了本地化，后来的作者们就都选择了这样做。

用 CDN 资源还有个问题，就是文档用自包含模式（self_contained = TRUE）时，Pandoc 得从 CDN 上下载一坨文件，这可能有点浪费时间和带宽。好几年前我同样跟 Pandoc 作者建议过增加一个选项，自包含模式时不下载 CDN 资源，但他也没有听。不过很多个版本后，他提供了一种曲折的方式支持这个功能，就是如果使用外部 CDN 资源，在 HTML 标签上加 external=1 属性即可让 Pandoc 跳过下载，如 <script src="https://example.org/foo.js" external=1></script>。但这个办法对用户没什么用，因为用户通常无法控制如何生成这些 HTML 代码，也就无法加个 external=1 的属性。

Cloud2016

Cloud2016 再加一条，博客里，是否可以支持代码显示/隐藏。有全局或局部按钮控制。
我已找到相关材料 <details>，但能力有限，无法简化下来。下面是一个 demo，插入 Rmd 文稿里可用。

这个代码块干具体事情

```{r}
#| label: code
#| echo: false
head(iris)
```

这个代码块实现显示或隐藏代码效果

<details>
<summary> 点击显示或隐藏代码 </summary>
```{r}
#| ref.label: code
#| eval: false
#| echo: true
```
</details>

最初是逛人家博客coolbutuseless，然后查看其网页源码，最后，定位到有这么一个 HTML 元素

Cloud2016

@yihui 我对《地区分布图及其应用》文章提了一个 PR 默认隐藏一些绘图代码，我觉得这些代码默认隐藏起来没有影响，你看怎么样？实现方式上是否还有简化的可能？

yihui

Cloud2016 实现方式上有大大简化的可能。这种重复劳动可以用 JS 一口气实现。大概实现方式就是找到所有的 <pre>，然后创造 <details> 元素把它们装进去，类似这样：https://github.com/yihui/xaringan/issues/219

Cloud2016

@yihui Frank Harrell 又更新了他的这篇博客，添加了很多新的 Quarto 的新功能，blogdown 会支持用 quarto 来写博客吗？用 qmd 替代 Rmd，然后用上 Quarto 的各种功能。

Cloud2016

@yihui 刚又看到一个非常重要的 feature 就是如何制作双语博客，因为在 blogdown 世界里没有找到好的办法，她投奔 Quarto 了，写下一篇号召力极强的文章 Creating a blog with Quarto in 10 steps，看了让人跃跃欲试！

CyrusYip

Cloud2016 多语言功能这口锅得由 Hugo 主题来背。

Cloud2016

CyrusYip 为啥Hugo要背锅？感觉这个配置过程应该在blogdown这侧自动化起来呀！

CyrusYip

Cloud2016

因为 blogdown 背后的工具是 Hugo，Hugo 的多语言功能（同一个网站有多套语言）又得主题支持才行。举个例子：我之前用 even 主题的时候它就没有language selector（语言切换按钮），到 fcf2021 这个 commit 才加入这个功能。要是你用的主题没有 language selector，那 blogdown 也是爱莫能助。

不同的多语言主题配置写法也不一样，感觉很难自动化配置。我找了几个多语言主题的配置，写法都不太一样。

academic
LoveIt（很细致）
hugo-theme-jane
hugo-ivy（这个配置最特别，和官方配置方法不一样）

如果你要用 blogdown 弄多语言博客，建议选择示例网站有多语言的博客（例如：jane、LoveIt），然后抄官方配置来用。Hugo 主题目录有个 multilingual 标签，可以从这里找多语言主题。

blogdown 把 Hugo 封装得很好，用的时候都感觉不到 Hugo 的存在。但是要弄多语言这种复杂的配置的话，还是得了解它背后的 Hugo。

Cloud2016

CyrusYip 如此说来，多语言配置，要在 Hugo 主题这层弄，而且还需要了解 Hugo 本身，上层的 blogdown 对此无能为力，那看起来是个高级 feature !

yihui

Hugo 的多语言支持对我来说过于强大了。我的中英文博客几乎是独立的，我不需要某篇文章同时有中英文版本，所以我用了最原始的办法，就是中英文博客只是简单的两个文件夹。

Cloud2016

Cloud2016 8. 博客中支持附录，就是指定放参考文献的位置

# 参考文献

<div id="refs"></div>

# 附录

附录内容

Cloud2016

Cloud2016 6. 支持自包含的模式，在输出部分的 YAML 设置 self_contained: true 还可以修改代码的语法高亮等，详见帮助文档 ?blogdown::html_page

bibliography: refer.bib
output:
  blogdown::html_page:
    toc: true
    highlight: pygments
    self_contained: true
    template: null
link-citations: true

chmzs

Cloud2016 插入引文，用doi检索不到文章，是因为网络问题吗？

Cloud2016

chmzs 可以贴出你的 DOI 吗？