Typst is easy to market as a faster, friendlier way to make PDFs, and the project's own open-source page gives you enough material to do exactly that: an open-source compiler, a CLI, a library embedding story, and outputs that range from PDFs to images and web pages.[2] That description is accurate, but it leaves out the part that decides whether Typst feels shallow or powerful in real use. The harder you push it, the less it behaves like a dressed-up markup language and the more it behaves like a contextual layout engine whose values only become meaningful once the compiler knows where things land.[1][2]

Laurenz Mädje's fifteen-minute Typst meetup talk is useful because it does not spend its time selling elegance in the abstract.[1] Recorded in Berlin on December 14, 2024 and published on the official Typst channel on December 20, it walks through a handful of edge cases that look playful on the surface and deeply architectural underneath.[1] The examples keep returning to the same lesson: Typst lets you program over rules, counters, and document locations, but it does so inside a layout-aware execution model rather than inside a simple top-to-bottom text pass.[1][3][4]

Image context: the lead image shows operators working at Monotype keyboards, an older physical version of the same problem Typst makes programmable: written instructions become page structure through a layout system. It is more immersive than a code screenshot or title slide, and it keeps the article grounded in the craft of making documents behave.[1][2]

Around 0:30, generated show rules reveal that styling is part of the language surface

The talk opens with a trick that looks decorative: generate set and show rules in a loop.[1] If you came to Typst expecting a one-way markup format, that example feels slightly cursed. If you came looking for a programmable document system, it feels like the correct opening move. The styling reference explains that Typst exposes set rules for styling defaults and show rules for transforming matching content.[3] What the talk adds is the operational implication: those rules are not merely static theme declarations sitting in a config file. They are part of a language surface you can generate and compose.[1][3]

That matters because it shifts the mental model away from "write text, then sprinkle presentation on top." A Typst document can construct style behavior from ordinary language features, which means presentation logic is not outside the program. It is one of the places where the program lives. My inference from the talk and the docs together is that Typst's real boundary is not between content and style in the usual word-processor sense. It is between content that can be transformed structurally and the later layout pass that determines how far those transformations can safely reach.[1][3][4]

Around 3:18, counters only make sense once you admit the page is part of the computation

The counter example is where Typst stops feeling like a nicer Markdown and starts feeling like a layout runtime.[1] Mädje shows a case where you want a weak page break and a page-counter reset to cooperate, and the lesson is subtle: the counter update only makes sense in relation to the page on which the surrounding content finally lands.[1] The docs make that constraint explicit from two sides. The counter reference describes counters as contextual values that can be displayed, stepped, updated, and finalized.[5] The context reference explains why: some expressions depend on location, styles, and surrounding state, so Typst delays their full meaning until the right document context exists.[4]

This is a stronger claim than "Typst supports page numbers." Lots of tools support page numbers. Typst exposes page numbering as one instance of a broader rule: document state is not fully knowable from raw source order alone.[4][5] Once you accept that, the behavior of counters becomes easier to predict. A reset is not just an integer assignment in a vacuum. It is a layout-sensitive operation that has to line up with where the engine ultimately places the content. That is why the talk's example feels revealing even if you never copy the exact code.[1]

Around 9:20, context plus measure shows that layout inspection is intentionally delayed

The most useful section in the middle of the talk is the one that uses context together with measure.[1] Here the lesson is not only that Typst can inspect width, but that it refuses to pretend width is available too early. The context documentation says contextual expressions can depend on things such as counters, state, location, and styles, and therefore may evaluate to different results in different places.[4] That same rule explains why measurement sits naturally inside a context block in the talk.[1][4]

This is a good design choice because document layout is not like templating a JSON file. Width is not a stable property of a source string; it depends on font metrics, active styles, and placement inside the page flow. Typst could hide that dependency behind magical convenience and make advanced behavior harder to reason about later. Instead, it exposes the dependency. The state reference reinforces the same worldview from another angle: persistent document state exists, but it is updated and observed through contextual operations that participate in the compiler's evaluation process.[6] In practical terms, Typst gives you real power to react to layout conditions while still forcing you to acknowledge that layout is itself a computation.[4][6]

Around 12:34, locate explains why Typst needs controlled introspection instead of one-pass certainty

The final stretch of the talk moves into locate, and this is where the compiler model comes fully into view.[1] The locate reference describes a function that lets you access an element's location, which in turn opens the door to page numbers, positions, and other document-aware logic.[7] That is already powerful. The more important part is the boundary around that power. Once a document can ask where something is, the compiler may need more than one pass to settle on a stable answer, because the act of querying layout can itself influence layout.[1][6][7]

Mädje treats that as a source of humor, but it is also the right place to take Typst seriously.[1] A document engine that allows introspection without convergence rules becomes unpredictable fast. Typst's approach is to make introspection available while keeping it contextual and bounded.[4][6][7] That is the reason the talk ends up clarifying more than six obscure facts. It gives you the right operational reading of the whole system. Typst is strongest when you treat it as a compiler that resolves document meaning through styled, located, page-aware evaluation, not as a plain text format that only happens to output polished pages.[1][2][4]

That is also why this video is a good onboarding artifact for technically minded users. If you only watch product demos, Typst can look like a cleaner authoring interface. If you watch this talk with the docs open, a deeper pattern emerges. Rules are programmable. Counters are contextual. Measurement is delayed until placement exists. Location queries are powerful precisely because the compiler refuses to fake one-pass certainty. Once that model clicks, many of Typst's stranger edges stop looking like quirks and start looking like the cost of giving documents a real execution model.[1][3][4][5][6][7]

Sources

1. Typst, "Six Things I Bet You Didn't Know About Typst" - Laurenz Mädje at a Typst Meetup, YouTube video (recorded December 14, 2024; published December 20, 2024).
2. Typst, "Open source at Typst" - compiler scope, CLI/library model, and output formats.
3. Typst Documentation, "Styling" - set rules, show rules, and transformation behavior.
4. Typst Documentation, "Context" - contextual expressions and location/style-dependent evaluation.
5. Typst Documentation, "Counter" - contextual counters, updates, display, and final values.
6. Typst Documentation, "State" - persistent document state and contextual updates.
7. Typst Documentation, "Locate" - location access for document elements and layout-aware introspection.