Typst Musings


Albert Krewinkel


March 24, 2023

Typst, the new writing tool, was open sourced a couple of days ago. This is right up my alley of course, and I have a couple of thoughts on it, which I share here.

What is it?

Typst is a writing tool that’s described as a LaTeX alternative: it takes plain-text markup as input and can produce nice looking PDFs from that. The open-sourcing of the code created a lot of excitement and interest, with the GitHub repository getting starred over 9,000 times in just a few days.

The tool comes with fresh and interesting ideas, impressive technology, and a good bit of hype—so let’s take a closer look.

How does it work?

Typst is written in Rust, a comparatively low-level programming language that fixes many shortcomings of other languages operating in the same domain. One interesting feature of Rust that Typst makes use of is compilation to web assembly, which allows us to run Rust programs in the browser. This is how Typst can do the blazing fast PDF generation in the browser!

Of course this only works if it is Rust all the way down, which has important consequences. My first thought when I looked at the code was that it suffered from some serious nih syndrome: basically the whole stack is built on libraries written by the Typst team, even when high-qualitify open source libraries were available and could have been used with Rust.

But, while nih still seems relevant here and there, the majority of libraries make sense when viewed through the lens of wasm-compilation. My understanding is that it’s not always easy to compile C libraries to wasm. And with a complex system like Typst, it is often essential to have full control over the underlying libraries. So I think most choices are quite reasonable.

Personal opinions

This wouldn’t be a proper “old man shakes fist at the clouds” tech blog post if it didn’t come with a number of “I see room for improvements” comments. Here we go.


One of my main concerns is the scripting language: It seems well designed, but I’m not convinced that it was necessary to create a completely new language. I actually believe that something like Lua, which is established1 but flexlible, would have worked well here. But what’s more is that, if we accept that it was necessary to have a custom language, I would have preferred one that isn’t Turing complete, i.e., one where we can be sure that document rendering will terminate. Something like Dhall.

As it currently stands we can neither reuse pre-existing code, nor do we have a guarantee that the document will stop evaluating at some point. It feels like a missed opportunity.


Notebooks are a great tool to improve reproducibility in science writing. The code for analyses is collocated with the descriptive text in a single place. The data is closely linked to the final tables and graphics. It is one of the great features of Quarto, Jupyter, Org, Stencila, Mathematica, and so on, which makes them well suited for scientific writing in fields like medicine, psychology, and the natural sciences.

This could be an issue for Typst, but I believe that it won’t be a problem when Typst is used in combination with other tools. John MacFarlane (of CommonMark and pandoc fame) has started work on a Typst pandoc writer, which will convert existing Markdown documents to Typst, and could enable the use of Typst as PDF generator while still writing Markdown and Python code in Quarto.

Accessibility and metadata

It’s good practice to make PDFs accessible, which requires adding semantic information to a PDF instead of “just” placing characters on a page. Accessibility is even a legal requirement for government-issued documents in many countries. There are standards like PDF/A-1a and PDF/UA that ensure people with disabilities can access the information contained in the PDF. This is currently not supperted in Typst. LaTeX is still trying to catch up there, too, while ConTeXt and speedata are doing well, for example.


I believe Typst will succeed, but not as a full-fledged writing tool. The greatest value I see is in the responsive, interactive, and even collaborative styling of PDFs. That feature is truly unique and sets Typst appart from all other software out there. The tool obviously has the potential to reach the critical mass of contributors to become a sustainable open source project, and the tech choices help to attract more developers. Last but not least, the app is shiny, works well, and makes people want to use it.

At the same time, I believe that the Typst writing app won’t take hold in scientific writing. Most of the current enthusiasm is contained to technical circles, and scientists don’t have strong reasons to switch yet. To the contrary, journals expect paper submissions to be done in Word or LaTeX, not PDF. This won’t change anytime soon. Typst will have to insert itself into the current publishing landscape, and that’s not a trivial task.

For example, SciFlow and Overleaf already exist, cover most of the market needs, have a solid headstart, and – this is the important part – are well aligned with the needs of science publishers. Any new tool has to compete with them. Also, let’s not forget all the other tools that I mentioned above.

Regardless, I’m optimistic that Typst can carve out its own business niche to occupy. For example, hardly any of my points above matter in print publishing. An indie book publisher that allows authors to use Typst for layouting would be amazing.

I hope that the Typst team’s hard work will pay off, and I will continue to follow their progress with great interest.


Heart-felt thanks to @maegul@hachyderm.io for the insightful feedback on an earlier version of this post, and to Ilona Silverwood for her skillful editing. This post became much better thanks to their input.


An earlier version listed Authorea as an authoring tool, but the platform has shifted focus since I last looked at it, so I’ve removed it.


  1. I consider Lua to be the language of publishing tools. It fuels pandoc, Quarto, ConTeXt, LuaLaTeX, speedata, SILE, and probably a few more.↩︎