Why I moved from LaTeX to Typst

and where LaTeX is still relevant

Trivia: Typst 0.15 was released while writing this blog post!

There are myriads of documentation formats. At least I have encountered plain text (.txt), reStructuredText, Markdown, AsciiDoctor, mandoc, DOCX, Apple Pages, Google Docs, and LaTeX over the last year for different purposes. The first five are usually used for technical documentation related to programming like the FreeBSD handbook or source code documentation. The next three are for school stuff such as collaborating on a project report or writing English essays. I find that different formats and software have their own strengths, so it’s obvious why I use so many formats for writing: there is no such thing as the best format in writing.

But LaTeX is different. So far, there hasn’t been any competitor that is appealing enough to replace LaTeX. Although LaTeX is very inconvenient, no alternatives could overcome its ecosystem. But finally I discovered something that can be its replacement: Typst.

Pain Points of LaTeX

So what’s wrong with LaTeX, a de-facto standard format for writing technical reports, papers, and dissertations? Here are the issues:

• Slow compilation, no incremental build

• Intermediate files like .aux during compilation that make my workspace dirty

• Difficult to learn

• Compilation log issues (hard to interpret, notorious “Underfull \hbox”)

• Needs too many delimiters, thus worsening readability

The first two are obvious; I don’t think I need to explain them. For the third point: LaTeX is definitely harder than simple languages like Markdown or reStructuredText and WYSIWYG editors like Microsoft Word. But still, it’s unnecessarily complicated, and Typst solves the problem. We’ll visit that point again later.

Now let’s take a look at the last two points.

Abstruse compilation log

While working on my BSDCan paper, I got the following error message:

Underfull \hbox (badness 10000) in paragraph at lines 308--314
\OT1/pcr/m/n/10 hmp_state.total_capacity \OT1/ptm/m/n/10 dur-ing ini-tial-iza-tion
/Users/minsoochoo/Documents/BSDCan 2026 - HMP/hmp.tex:318: Missing $ inserted.
<inserted text> 
                $

What was the issue? Here’s what I had in line 318:

Each score is a single scalar value: each CPU exposes exactly two
scores, indexed by \texttt{enum score_type}:

Yes, I forgot a delimiter \ between “score” and the following underscore. If you were experienced in LaTeX, you would’ve noticed it easily. If not, you might have wondered why it triggered that error message. The point is that the error message was kinda useless here to see what triggered it.

But that’s just part of the problem. The whole log I got from the compiler was 497 lines long, and most of them were “Underfull \hbox” warnings. That warning is very annoying because it’s not an issue most of the time but takes up a huge part of the log, making identifying issues way harder.

Needs too many delimiters

This is part of my BSDCan paper in LaTeX:

Providers register themselves at \texttt{SI\_SUB\_SMP} via two parallel
macros: \texttt{HMP\_CAPACITY\_PROVIDER\_DECLARE} and
\texttt{HMP\_SCORE\_PROVIDER\_DECLARE}.  Each hooks a \texttt{SYSINIT}
handler that calls the corresponding registration routine
(\texttt{hmp\_capacity\_provider\_register()} or
\texttt{hmp\_score\_provider\_register()}) and ...

In programming, underscores are used frequently, mainly due to namespacing. Whenever I introduce new functions or variables in my papers, I need to use delimiters so the compiler doesn’t spit out incomprehensible error messages. Now you would ask, “Why not just live with it?” The fact is that my eyes hurt even with a paper of seven pages in length. One day, I’ll need to write a thesis or longer papers. These delimiters make my eyes tired during proofreading, and as you may know, writers do proofreading multiple times (I repeated proofreading and revising more than seven times for that BSDCan paper).

I don’t have that issue with Typst. In Typst, I simply write:

Providers register themselves at `SI_SUB_SMP` via two parallel
macros: `HMP_CAPACITY_PROVIDER_DECLARE` and
`HMP_SCORE_PROVIDER_DECLARE`. Each hooks a `SYSINIT`
handler that calls the corresponding registration routine
(`hmp_capacity_provider_register()` or
`hmp_score_provider_register()`) and

How simple is that, right?

Another advantage of not having delimiters for underscores is that copy-pasting from source code requires less work. And again, if I miss one delimiter, the compiler will complain in a way I can’t understand.

So why Typst?

Remember I said LaTeX is hard to learn? It’s because many developers these days learn Markdown as their first documentation language since it’s widespread in the OSS world. And when they encounter LaTeX, it feels like learning a new language without any connection to the ones you already know. Analogy here: an Anglophone is likely to learn French more easily than CJK languages.

Typst doesn’t share the same grammar as Markdown, but at least it’s similar. Let’s see some examples:

// Typst
# Heading 1
## Heading 2
### Heading 3
*Bold*
_Italic_
`Monospace`

// ... while in LaTeX,
\section{Heading 1}
\subsection{Heading 2}
\paragraph{Heading 3}
\textbf{Bold}
\textit{Italic}
\texttt{Monospace}

I admit that LaTeX is more consistent: every command starts with a backslash. But if you are coming from Markdown, you would admit that Typst is easier to start with. As a university student who does OS development as a hobby, I don't have time to learn a documentation language that completely differs from the ones that I already know. As a student in a STEM field and as a developer attending many conferences, I would definitely need to learn one of them. And considering my time constraints, it's obvious why I chose it over mastering LaTeX.

Another minor thing: I found that Typst’s VSCode extension is better than the VSCode LaTeX Workshop extension. Unlike the LaTeX extension, the Typst extension doesn't compile the source into a PDF until I trigger it manually, but it shows a PDF preview instead. Thanks to Typst's superior compilation speed, the latency between save and update on the preview tab is better, too. And finally, the Typst extension automatically scrolls the PDF preview when I put my cursor on different parts of the document, and when I click a part in the preview, the cursor in the editor window automatically moves to the equivalent point (although this doesn't work well when macros are involved).

Where would I still use LaTeX?

But Typst cannot replace LaTeX completely. LaTeX already has a rich ecosystem, and many journals provide templates in LaTeX and only accept papers in LaTeX. Even arXiv only accepts LaTeX, although there is an ongoing effort to accept Typst as well (PDF is also accepted, but it has too many downsides compared to LaTeX).

Take my BSDCan paper as an example. Because it’s a conference paper, I’m going to submit a PDF generated from the LaTeX version. Typst’s charged-ieee template still has some minor style issues. They don’t stand out, but when I put it side by side with other articles from the original IEEE template, it stands out too much. Also, the lack of a \thanks{} command made me hesitate to make a switch.

So I’ll use LaTeX when I have to, like I’m forced to use Google Docs when collaborating with my friends for university projects.

What I’ll use Typst for

I'll use Typst for anything else. I already converted my résumé to Typst. Originally it was in the famous Jake’s Resume LaTeX template, but I converted it to a similar Typst template called basic-resume. It's not a 1:1 equivalent, and I still like the original styling, but the convenience of Typst surpasses that minor styling issue. So I'll stick with that template until a 1:1 equivalent comes out.

Lastly, I thank the Typst developers for creating such a wonderful language.