LaTeX v.s. Typst: What is TeX Community's Future Plan? [closed]

Question

Recently I have become increasingly anxious about LaTeX being (possibly) surpassed by Typst due to its simplicity. This answer shows several edges of Typst over LaTeX.

I have been arguing with one of my classmates about why I still choose LaTeX over Typst:

• The typesetting quality of LaTeX is superior (though Typst is quickly catching up)
• I love TikZ, while there is no counterpart in Typst (actually there is now CeTZ)
• CJK support in Typst is poor, while XeLaTeX and LuaLaTeX handle CJK fonts well (I think they will fix this soon though)
• Maths in Typst is awful, LaTeX has already set the standard
• Actually, since I am used to LaTeX, I do not want to switch to Typst :-(

However, I have been stricken with some facts:

• Macros in LaTeX are not as convenient as actual programming, even though there is LaTeX3 to mitigate the issue.
• Compilation of LaTeX documents can be slow, compared to Typst using Rust.
• Easier syntax of Typst will make people more inclined to learn Typst instead of LaTeX. LaTeX has many packages (and some even conflict), which can be very confusing to learners.

I have seen some of the changes made within the LaTeX community, including tectonic rewriting LaTeX using Rust.

So what is the plan of the TeX community to keep TeX/LaTeX this beautiful language continue flourishing? I am eager to learn more and wish to contribute.

Answer 1

Well at first I would be rather wary about the "easy" and "fast" claim. 10 years ago I answered a question about how Word differs to LaTeX with

Yes, you can do most normal things without problem (and sometimes faster or easier) with Word. But what about slightly "unnormal things"?

typst is "modern" which is another word for young. When it started it couldn't even do rather normal things like footnotes, floats, bookmarks, double page layouts, form fields or PDF comments. And while some of them are now implemented they still lack many of the configuration options that exist in LaTeX or supporting packages. An current example is this discussion about how to get something as basic as a \pageref in typst: https://github.com/typst/typst/issues/2873.

It is easy to do easy things in an easy to learn syntax and I quite agree that # my chapter is a nice, short way to create a heading (but the LaTeX syntax \chapter{my chapter} isn't long either), but the question is what happens if you want more complicated things. Is there an intuitive syntax for an unnumbered section? How can you adapt the entry in the toc or the header? Is that built-in or does it require to find and copy ten or more lines of code like for the pageref in the issue quoted above? Will typst stay easy to use once it gets more mature and gets feature requests about more sophisticated document features?

At second I'm quite distressed that a "modern" system like typst doesn't support PDF accessibility features from the start on. Accessibility may not matter for private documents but anyone writing for some organization will have to consider this topic soon. The typst authors knew that and they knew that they need the structure data for a tagged PDF but nevertheless wrote their compiler so that it looses them: "Since the frames currently only contain locators and not a full reverse mapping to the document’s structure, the exporter cannot write this structure information." They claim that they are in a good position because there is quite a lot of semantic information available, but LaTeX has the semantic information available since 30 years and that doesn't make it easy to produce accessible, tagged PDF.

If I had considered to write a typesetting engine from scratch (which I wouldn't as I believe that large systems should be changed by evolution, not by tearing down and rebuilding -- you can't move all inhabitants of a city out while you redesign it from scratch), then I would have made sure that the core design considers accessibility from the start and not add that as an afterthought. That they missed this opportunity makes typst in my eyes very unmodern.

Answer 2

As someone who’s also writing a LaTeX replacement, I think that it would be a good thing for LaTeX to be superseded by something in the future. Programming in TeX macro language is a mess and a commitment to backwards compatibility means that progress is slow if not impossible (I still think that it was a gross mistake to fold LaTeX3 into an evolving LaTeX2e rather than take advantage of a major version number to break backwards compatibility.

My prediction is that LaTeX’s successor, should it ever arise, will retain the markup of LaTeX but eschew the macro-based programming model. Authors need to be able to transition with little friction. I don’t think anybody would mourn the death of the fragile LaTeX macro system. Just because TeX is Turing complete doesn’t mean that it’s the best way to do things or even a good way.

Things I would expect to see would be versioning of packages and document classes (or their equivalent) so that nobody will be surprised when CTAN updates a package three dependencies deep and their document no longer compiles. Also, there’s no reason in modern computing systems why multiple runs should be necessary to manage things like references and citations. A single application would be able to handle the capabilities of LaTeX, BibTeX, makeindex etc.

I also kind of feel that rather than writing, e.g.,

\documentclass{amsart}

the better approach might have been to do something like

\DocumentStructure{article}
\DocumentFormat{ams}

or better still:

\DocumentStructure{article:1.0}
\DocumentFormat{ams:ams:1.0}

where we have not only version numbers but namespaces as well so that there’s not that continual worry about crashing into each other’s file names.

Finally, I would propose that external dependencies to the document would be automatically downloaded if a local copy doesn‘t exist so that the core distribution no longer is quite so cetacean in size.

Answer 3

The greatest disadvantage of typst and I think a grave design mistake, is that is not compatible with LaTeX. What does one do with large volumes of existing documents, archives etc? Throwing everything away and starting from scratch? I have been using LaTeX since its inception, that is almost 40 years now! Milestones in improvements were the use of Laserjets (adapted quickly), pdfTeX, babel, now the l3 layer, LuaTeX, PGF/Tikz, BiblaTeX, microtype.

TeX/LaTeX's markup language, will endure and last, probably longer that many of the older generation that we are still using it. As anyone that read the Dragon book will tell you, is not easy to come up with a compiler that picks up commands and parameters from a sea of letters around it.

Can it get improved? Yes! Areas in my opinion that can be improved:

1. Automatic replacement of glyphs that are missing in fonts, similar to what web browsers and IDE do. This can be achieved currently with LuaTeX/LuaLaTeX with fallback fonts, but it gets painfully slow.
2. Programmable output routines. Defaults should be built into the TeX engine itself.
3. Many of the problems with conflicts in packages come from hyperef. A new mechanism should be designed, enabling authors to use links, easier, rather than depend on the package. The base classes, can be modified to incorporate this, so no need for hyperref to redefine all the sectioning and referencing commands. Incorporate this into the format.
4. Handling of Indic and east Asian documents, can be improved by contributing to haffbuz and LuaTeX. There should be no need to load a package to change a language.
5. Creation of virtual fonts can be improved.

To all those trying and developing different systems, thank you, competition is good and wish you good luck. I was looking the other day at some stats and noted that between the l3 and LuaTeX some 130,000 loc were added onto what is loaded in a run. the original TeX had some 20,000 loc. Maybe some efforts to improve the engines themselves to handle some of the areas that are problematic, will be easier and more useful than re-writing everything form scratch.

Answer 4

Without knowing concrete plans from the Latex community we can anticipate future development of both Latex and Typst to some degree, reusing 2 scientific findings.

This moves us away from a look at concrete plans or speculations to a sound more global view.

Law a requisite (minimum) variety (complexity)

This goes back to W.Ross Ashby, who is amongst the founding minds of cybernetics. He stated, partly in my words:

• to deal with complexity
• the regulator/controller has to be at least as complex;
• regulation fails with undercomplex regulators
• especially with noise (disturbances) involved.

Ashby's example

In his "Introduction to Cybernetics", 1956 he uses a temperature controller to illustrate his basic equation and considerations.

Basically it states:

• within a normal range of environmental temperature variation the controller works fine
• however, with very disturbed weather conditions it fails, as it simply can't compensate the change any longer.

See e.g. here (a simplified chapter), or here (Wikipedia on Variety) or here (in his book, cited above).

My illustration

Let's think of a simple railway. One track, one train, no problem. The train goes back and forth all day long.

Let's increase complexity (C+) step by step in response to ever increasing disturbances (D+).

D+: Put a second train on the same track. Now problems start, as they hinder each other. As a solution we need to increase complexity of the system.

C+: Let's introduce a time table, which regulates, which train goes where, when, how often etc. This may be fine for many situations.

D+: Riding both trains has become more popular, and people start being annoyed by having to change trains all the time, just to go from one end to the other.

C+: Let's add a rail switch, so both trains can pass each other. Let's adjust the time table.

And so on. We all know the state of complexity railway systems achieved by today, like:

• often having at least two tracks per direction
• having many tracks at or near certain stations
• offering a variety of trains
• using signals of all kinds
• providing many different kinds of railroad crossings
• having digital twins of "what's happening outside"
• etc.

Simplify, like economic controllers tend to do, and someone pays a price. (Dead end)

Invent, and get both: simpler AND complexer. (Innovation)

Where the later is a summary of the work of the inventor of (intention) "Innovation as a Science", Genrich Altshuller. (TRIZ, russian accronym, my translation by meaning: a practical Theory to Resolve Inventive Zituations)

What does this mean for Latex and Typst ?

We all know: Latex IS complex. Or in Ashby's view: it does cope with a lot of variety/disturbances. It matured to a high level of typesetting ... and still is, see here.

By its very development Typst still is in its so called infancy state. It started out with a certain concept in mind, offering a still limited number of typeset outcomes, and it will evolve further, as any technical system,

• from contradiction (roadblock, trade-off: this EXOR that)
• via a solution (system change, exact solution: this AND that)
• to contradiction (next roadblock).

As many people stated, Typst IS simpler, and is intended to be so. Which does translate into:

• Typst is less complex than Latex
• Latex can handle more disturbances/variety/requirements than Typst for now, and perhaps will so for a long time
• to catch up variety offered by Latex, the Typst ecosystem (syntax, compilers, packages, libraries etc.) has to become more complex, has to be able to absorb more requirements/variety

So in consequence it will probably:

• be easier to come up with Latex2Typst translators (getting rid of variety)
• be tough or almost impossible to come up with Typst2Latex translators (adding variety/complexity) (in contrast to just storing in a latex file format)

My conclusions and estimates (having been achieved future)

For the near future I expect Typst to be and to remain Yet Another Markup Language, while Latex will continue to support typesetting ...

Some links between the two (called translators above) will come and go.

There may turn out to be a useful (quite large) subset of Typst, which can be absorbed (provided) by Latex.

The opposite, at least conserving complexity from typesetting, probably will never reach a useable state.