Looks cool (I'm a big fan of Typst), but I do question the value of moving the data to yaml, rather than just building a set of Typst functions and styles (see example below).
To me, it's one of those things people often do because it _feels_ nice, but when you really think about it the benefits are often very small (and the costs are quite high). The most obvious benefit is that the yaml data can be parsed by other programs, but is anyone really going to do that?
For an example of what I mean, is [1] (plus all the supporting code) really a better DX than [2] (which is also simpler to implement and much easier to debug and modify)?
[1]
work:
# Can't use markup or code in most of these fields, even if I wanted to.
- organization: X Company
position: Senior Developer
url: https://example.com
location: Remote / New York, New York
startDate: 2021-08-01
endDate: "present"
highlights:
- "Any markup I use here needs to be `eval`ed, and I don't get syntax highlighting etc."
[2]
== Work Experience
#workinfo(
organization: "X Company",
position: "Senior Developer",
url: "https://example.com",
location: "Remote / New York, New York",
startDate: "2021-08-01",
endDate: "present",
highlights: (
[I don't need to use `eval` any more],
[etc...]),
)
#workinfo(etc...)
Yeah, I concur with the idea. I think that's also the set up for other templates as well. As for me, I went with YAML since I think there should be minimal markup to the data since it's a CV and nothing fancy like a webpage. I don't see myself using images or other custom styles/functions. Even if I did, I think the `eval()` would be enough for minimally styled text and/or the occasional italics or bold. I'm also looking into piping the data in YAML to LLMs to help suggest better phrasing of descriptions of various items and take advantage of better context and structure (function calling?).
Edit: Also, there was the benefit of JSON schema for validation, I guess.
I am using YAML myself to manage my CV in two different languages. Using a convention like "description(en): ..." the different translations are co-located making it easier to keep everything in sync.
Interesting example that I hadn't considered. But, since Typst is a programming language, there are lots of ways the same thing could be achieved directly in the language. E.g.:
// Change this to switch languages
#let selectedLang = "en"
#let lang(..arguments) = arguments.named().at(selectedLang)
#workinfo(
position: lang(en: "Senior Developer", es: "Señor Developer"),
etc...
)
So the biggest problem is to actually render your cv. For this I use https://ohmycv.app. Its a nice (free) editor, and you can write CSS for the styling, works great. I source control the markdown and CSS, i have multiple versions of the same CV, so I can change content while keeping the format the same.
May I ask how you did it? I went with Typst because I found Markdown to be too unstructured/limiting and didn't want to use LaTeX (hard to use data from external files: CSV, YAML, JSON, etc.) templates to compensate.
To me, it's one of those things people often do because it _feels_ nice, but when you really think about it the benefits are often very small (and the costs are quite high). The most obvious benefit is that the yaml data can be parsed by other programs, but is anyone really going to do that?
For an example of what I mean, is [1] (plus all the supporting code) really a better DX than [2] (which is also simpler to implement and much easier to debug and modify)?
[1]
[2]