Why & Why NOT Typst

Why & Why NOT Typst

在 Typst 非官方中文 QQ 群 里，紙夜发了一个所见即所得的工具，引发了大伙对于相关议题的讨论。我碰巧先前觉得应该多练练英语于是强迫自己读了许多自己感兴趣的 Reddit 帖子，其中就包括在 r/LaTeX 里的诸多关于 Typst 的讨论。想来应该总结写一点东西，记录下来给以后的自己看。

万物起源

什么是 Typst？既然写到这里了，就大概提一句：大约是一个 LaTeX 替代品，更加现代容易上手，又非常像 Markdown。

至于紙夜发了什么，是一个类似 LyX 的，能修改源代码又能看见实时预览的工具，主要的应用场景是平板等小屏幕，这些设备不方便同时打开两个窗口，无法用传统的方式预览。紙夜自己半开玩笑地说这与官方的 Web App 有竞争关系，有群友又发散到不要被国内无良公司抄了去，笔者则对后者表达了不同的意见：以现在 Typst 的状态来说，有资本入场带来更多曝光量反而不一定是坏事。然后谈到 Overleaf 的付费，话题就转到了 Typst 与 LaTeX 的对比这个老生常谈的问题上。

编译速度之争

Typst 目前来说最大的特点，就是其编译速度，相比于 LaTeX 一篇稍带些格式的文档就需要十几秒的编译时间来说，Typst 仅需要毫秒级别的时间即可完成（在增量编译的基础上），而这就赋予了 Typst 一项对于现在的 LaTeX 而言几乎不可能有的能力：即时预览。

笔者对于 LaTeX 的工作原理不太了解，只知道它基于宏展开，这种情况应该比较难实现缓存和增量编译，也有一些现代化的重构尝试，但似乎都不太理想，也不知道可见的未来是否有大神改善这一局面，因此这里说的是“现在的 LaTeX”。

Overleaf 上收费的资源主要就是编译时间，而这对于 Typst 来说几乎不是问题，充分利用了现代计算机的大内存和多核 CPU，即使是非常复杂且大型的文档在一秒内完成全量编译也不是什么太困难的事。这一项区别对于绝大部分两个软件都略有接触的用户来说绝对是印象深刻的，群友也将其称为“杀招”。

有 LaTeX 经验的用户应该知道将文档分章节，只将正在编写的部分放进文档，这样预览速度能够大大提升，使其勉强达到“即时”的效果。诚然，简单的文档这样做并没有太多问题，但稍有追求一些的用户就会将文档中的数据图表等从 

matplotlib
生成的位图换成 
TikZ
 等能有看起来与正文更加一致的风格的工具，在这种情况下，两三张实际数据图就能使编译时间膨胀到数秒；这时又会有人提出可以提前编译好相应的 PDF 或者 SVG 然后以整体图片的形式插入，这样就能避免编译时间过长的问题。如此的“问题-解决方案”的循环应该是熟悉 LaTeX 的用户们都经历过的，但事情本该如此吗？

用户在很多情况下其实没有即时预览的刚需，而这一点称为“杀招”的具体原因，则是这些用户在做“内容之外”的工作，例如调整表格尺寸比例，通常来说只有这些工作才需要即时预览其显示效果。若仅仅是内容的编辑，稍有使用经验的用户就不需要编译就能大致在脑海中预览其结果。这在 LaTeX 资深用户看来是没有用正确的方法完成这个任务，即没有把排版和内容分开。那这是谁的问题呢？或者说，Typst 与 LaTeX 在这样的场景下，谁更“好”呢？

Do Things Right

在浏览 Reddit 时，我看到许多用户留言说，LaTeX 写起来并不困难，若是遇到了不可理解的报错，或者是效果不尽人意，大抵是写代码的人没有搞对。很多讨论集中在“语义化”（semantic）上，许多 LaTeX 用户称 LaTeX 里也有大量语义化的处理方式，而没有这样做就常常会带来不如预期的排版效果，或者在宏展开的过程中遭遇不可理喻的错误。这或多或少是有些为了辩护而辩护的意思，毕竟大家用 LaTeX 完全是因为其“排版效果精致”（当然，相较于 Word 等所见即所得的工具确实很正确，至少对于源代码有完全的控制），但绝大部分用户（如这部分发言的用户所说）并不能将这一美妙的工具用对（do things right），那么这是否也意味着工具本身并没有很好地创造这个让大家都能正确使用的条件呢？

同样的，关于编译速度，前面也提到了许多提高编译速度的技巧（例如分文件分章节等），在这之外还有用 snippet 降低键盘使用压力，用 Makefile 自动化编译等诸多可以算得上是“资深 LaTeX 用户才知道”的小技巧。

Rust 与 llvm：通过设计取胜

再谈 Typst 设计

对于 do things right，群友也有疑问：我们知道 Typst 里面怎么 do things right 吗？

总集篇

在与群友的讨论中，我就认为应当写一篇 Why & Why NOT Typst，然后挂在中文社区的导航里，在讨论结束后我随着思绪记下了这篇并没有太多含金量的博客，最终把较总结性的结论如下罗列，然后也会放进（TODO：链接待补充）

Why Typst

  1. 易学易上手，简单编程需求和现代语言设计相通

  2. 编译速度快，可以很方便地即时预览

  3. 语义化设计明确，有内置的各类排版模型

Why NOT Typst

  1. 尚在开发阶段，可能存在较大的 API 变动（Breaking Change）

  2. 生态不成熟，遇到问题通常没有完善的解决方案