How do their APIs compare?

Based on what's in the retrieved context, these two projects have quite different "APIs" because they serve different purposes — RON is a data serialization format/library, Typst is a document compiler with a scripting language — but I can compare what's visible.

ron-rs/ron: serialization/deserialization API

RON's public surface is built around Serde's data model, exposing conventional to_string/from_str-style entry points plus configurable serializers:

• Serialization config: ser::mod.rs shows a PrettyConfig-driven serializer with toggles like compact_maps, number_suffixes, compact_ranges, extensions, and escape_strings, plus indentation control via start_indent [src/ser/mod.rs:L518-L557]. Tests exercise the writer-based API (check_to_string_writer) for structs, newtypes, and tuple structs [src/ser/tests.rs:L40-L50].
• Deserialization: works through a Value enum (e.g., Value::Map, Value::String) for dynamic/untyped access, as seen in the indexmap ordering test that parses into Value and indexes via map.keys() [tests/129_indexmap.rs:L6-L77].
• Error handling: a structured Error/SpannedError API with span info (Position { line, col }) for precise diagnostics, and human-readable messages generated via helpers like Error::invalid_length, Error::unknown_variant, Error::NoSuchEnumVariant, Error::NoSuchStructField [src/error.rs:L609-L648]. Errors carry structured context (expected/found values, outer type names) rather than just strings.
• Extension-driven features: e.g., the base64 example shows #[serde]-style structs deserializing byte strings from either b"..." literals or base64-encoded regular strings depending on config [examples/base64.rs:L103-L147].

This is a fairly narrow, Serde-idiomatic API surface: config structs, a Value type for dynamic access, and rich structured errors — all synchronous and string/writer based.

typst/typst: compiler + IDE support API

Typst's exposed APIs are broader and layered:

• Core evaluation/world API: things like typst::World, typst::compile::<PagedDocument>, and Value (its scripting value type, distinct from RON's Value) drive compilation, as shown in the tooltip test harness [crates/typst-ide/src/tooltip.rs:L303-L342].
• IDE-support API (typst-ide crate): a set of functions built for editor tooling — analyze_expr, analyze_import, autocomplete, definition, jump_from_click, tooltip, deref_target, named_items — all re-exported from [crates/typst-ide/src/lib.rs:L1-L24]. This is a much richer surface than RON's, oriented around interactive analysis of source positions (cursors, spans) rather than just parse/serialize.
• Value/scope introspection: Typst's Value type supports .scope(), dictionary/content field iteration, and module scopes, used e.g. in a bounded breadth-first Searcher that walks Value::Dict, Value::Content, and Value::Module to find matching sub-values [crates/typst-ide/src/utils.rs:L200-L296].
• CLI-facing API surface: e.g., typst-cli's query command builds an equivalent eval expression from selector/field arguments, showing how CLI subcommands map onto the scripting API (query(...), .map, .first) [crates/typst-cli/src/query.rs:L127-L161].
• Element/function API with rich diagnostics: the #[elem] macro-based API (e.g., html.elem) exposes typed constructors with doc comments describing valid usage [crates/typst-html/src/format.rs:L174-L204], and errors like disallowed_field_call_error produce targeted hints depending on whether the value was a dictionary, named-argument struct, or content element [crates/typst-eval/src/call.rs:L341-L403].

Summary of the contrast