Now and then I see promising projects succumb to the suggestions or even demands of their users. I see them lose their essence just to please everyone instead of filtering out the unwanted features from similar projects.
From time to time, in this very forum, I come across suggestions that scare me. That’s why I wanted to know how averse to change The Typst project is.
I would like to know if there is any design philosophy or guideline to get an idea of what kind of features to expect from the project. For example, a project that aims for simplicity will pursue a simple core, while a project that aims for web integration will pursue compatibility with JS.
4 Likes
There is a list of three design principles that guide Typst, here.
I would say that the Typst team has so far been fairly conservative (if that is an appropriate word for describing a fairly modern piece of software) in accepting features and merging PRs that don’t align with their vision. A kinda infamous example was datetime.now(), which was rejected because it conflicts with incremental compilation. Another example imo is allowing PDFs as figures. This is completed now, but it was open for two years prior to that. People suggested solutions that would only work on PDF output, or only in the browser, but this was rejected despite quite vocal demand, since the compiler should work the same everywhere.
The closest I recall to a PR getting to merging before being postponed due to unanswered design questions was a constructor for dynamic modules. This was relatively easy to implement and also desired by many (including me) but after some more discussion turned out to potentially overlap with a more complex future feature. In other words: a feature with no current replacement was (for now) rejected to make sure that once a different more powerful feature was also part of the language, these two wouldn’t clash and make the language less clear overall.
Regarding web integration in particular: I think the goal of the Typst team is to generate clear semantic HTML; all JS integration would come from consuming that. Someone from the team would have to confirm the details, but I don’t think they would simply go by what is most demanded, without considering the design philosophy in detail.
9 Likes