Comparison to alternatives

When to use CX

The decision tree. Top-to-bottom, first match wins:

• **You need one syntax for data and code** (config that is also a program, templates that are also data, a schema that is also a value). CX is the only format in this comparison that is homoiconic; pick CX.
• **You need content-addressable identity** across languages and platforms (cache keys, dedup, signed documents, distributed ledgers). The CX SHA-256 of canonical bytes is the most boring possible implementation; pick CX.
• **You round-trip between JSON / YAML / TOML / XML / Markdown** and lose information each time. CX is the superset that preserves all of them losslessly; pick CX.
• **Your workload is bulk analytical scan on tabular data** at terabyte scale, exchanged with the broader ecosystem (DuckDB / Spark / pandas). Use **Parquet** for storage, **Arrow** for in-memory, optionally with CX as the metadata / config layer.
• **Your workload is wire-format throughput between microservices** with a fixed schema, and you control both ends. Use **Protocol Buffers** or **MessagePack** — they will be smaller and faster on the wire than any text format.
• **You need a single-file human-edited config** with no programmability and no cross-system identity requirements. **TOML** (Cargo, pyproject) or **YAML** (Kubernetes, CI) are everywhere; the ecosystem advantage is real.
• **You need a typed, programmable config language** with a strong type system. **Dhall** or **Pkl** are good fits if the type-system rigor matters more than the homoiconic data-and-code unification.
• **Otherwise** (general data / config / interchange with mixed workloads, mid-size documents, multiple consumers in different languages): CX is the all-purpose default.

CX vs JSON

JSON is the universal interchange baseline. CX is a superset projection — anything that round-trips through JSON also round-trips through CX. The interesting comparisons are where CX has features JSON does not, and where JSON has ecosystem JSON does not.

**When to pick JSON instead of CX.** Your consumers are browser JavaScript, a CDN-served config endpoint, or any interface where you cannot install a CX parser. JSON remains the right wire-format choice for ubiquity alone.

**When to pick CX instead of JSON.** You want identity, schema, comments, mixed content, dates, or bytes without layering JSON Schema + JSON5 + base64 + custom date string conventions on top of JSON. CX gives you the whole stack in one syntax.

CX vs YAML

YAML optimises for human readability of multi-line strings and config-as-code. The cost is the famously large surface area (indentation sensitivity, tag system, anchor / alias / merge keys, the Norway problem).

**When to pick YAML.** Your config consumers are Kubernetes manifests, Ansible playbooks, GitHub Actions workflows, or any tool whose schema is in YAML. The ecosystem advantage is decisive.

**When to pick CX.** Anywhere you would have wanted YAML minus the indentation footguns, the Norway problem, and the lossy round-trip. The triple-quoted multiline string is as readable as YAML literal blocks without the indentation rules.

CX vs TOML

TOML's pitch is "obviously correct config for configuration files." It excels at flat key-value configs (Cargo.toml, pyproject.toml) and struggles with deep nesting.

**When to pick TOML.** Your config is flat — language toolchain manifests, Cargo dependencies, app configuration with two levels of nesting. TOML reads beautifully at that scale.

**When to pick CX.** Your config is genuinely hierarchical, you need cross-config identity, or the same documents will also be processed as data (e.g. shipped as configuration *and* hashed for a release manifest). CX scales up where TOML hits its ceiling.

CX vs XML

XML is CX's closest structural cousin — both are tree-shaped, both support attributes and mixed content, both have namespaces. The differences are syntactic density and the surrounding ecosystem (XSLT, XPath, XSD).

**When to pick XML.** You are working in publishing / document workflows (DITA, DocBook, SVG), or your consumers are XML-native (SOAP, XHTML, RDF/XML). The tooling depth is unmatched in those niches.

**When to pick CX.** You want the XML data model (attributes, mixed content, namespaces, XPath) without the syntactic verbosity, without XSD, and with code-as- data unification. CX is what XML would look like if designed today.

CX vs Protocol Buffers

Protobuf is the schema-first binary wire format for service-to-service traffic. It is the right tool when you control both ends, the schema rarely changes, and every byte on the wire matters.

**When to pick Protobuf.** You have a controlled RPC system, the schema is well-understood, and the bandwidth / CPU savings are real (mobile, embedded, hot-path services). Honest concession: Protobuf wins on wire throughput in the steady state.

**When to pick CX.** Your data is also config, also logs, also human-edited at the boundary, also stored on disk for later inspection. Protobuf loses to text formats outside the wire-only path.

CX vs MessagePack

MessagePack is "binary JSON" — schemaless, more compact than text JSON, slightly slower than protobuf because it carries kind tags.

**When to pick MessagePack.** You want JSON semantics on the wire without JSON wire size, and your data is flat / tabular / homogeneous. MessagePack is excellent at being "JSON minus the text.".

**When to pick CX.** Your data has shape — attributes, mixed content, namespaces, hierarchical structure that MessagePack would force into nested maps. data-bin covers the wire-size argument without giving up the shape.

CX vs Apache Pkl

Pkl is Apple's configuration language — declarative, strongly typed, programmable. The closest "config that is also code" peer to CX, with a different design centre.

**When to pick Pkl.** You want a strongly typed config language with class-oriented composition and your consumers are JSON / YAML output. Pkl's type system is richer than the CX schema language.

**When to pick CX.** The same documents are also data to be hashed, queried, transformed, or shipped as payloads. Pkl is config-first; CX is data-and-code by design.

CX vs Dhall

Dhall is the typed-config purist's pick — total, non-Turing-complete, with a sound type system and normalised import semantics.

**When to pick Dhall.** You want totality, soundness, and a small surface area as design goals; you are willing to pay for the steeper learning curve. Dhall is the right tool for safety-critical config.

**When to pick CX.** You want the content-addressed identity, the schema-validated config, and the programmable updates of Dhall — plus the ability to carry rich data (mixed content, columnar tables, dates, bytes) in the same syntax. Dhall is config; CX is config + data + code.

CX vs Parquet

Parquet is the columnar storage standard for analytical workloads — terabyte-scale scans, predicate pushdown, compression. CX is not Parquet's competitor; CXCol is, and Parquet is CX's export target.

**When to pick Parquet.** Your data is large, tabular, queried by external tools (Spark / Athena / BigQuery / DuckDB), and stored on object storage. Parquet is the lingua franca.

**When to pick CXCol.** Your data is tabular but the producers and consumers are CX-native (pipelines, in- memory analytical jobs, services that ship columnar payloads). When you need to interchange with the broader ecosystem, export to Parquet.

CX vs Arrow

Arrow is the in-memory columnar standard. Like MessagePack, it is not a CX competitor — it is a layer CX integrates with.

**When to pick Arrow.** You are doing pure analytics — no document semantics, no identity requirements, no schema as a value. Arrow is the right cross-engine in-memory layout.

**When to pick CXCol over Arrow.** You want Arrow's column-orientation plus CX's document semantics (mixed content rows, hierarchical headers, namespaced columns, hash-stable identity). Use the bridge — they share memory zero-copy.

Summary table

At a glance, the headline trade-offs for each alternative. **Pick CX** is the column that matters most for an evaluator question.

**The honest summary.** CX wins on **unification**: data + code + schema + identity in one syntax. It loses on **ecosystem maturity** — JSON, YAML, and Protobuf all have decades of library / editor / CDN depth. The question for an evaluator is whether the unification value exceeds the ecosystem-depth gap for your specific workload. For workloads in §13.1's "otherwise" bucket, the answer in 2026 is increasingly yes; for the niches above the "otherwise" line, pick the specialist.

If you have a workload that does not match any row of this table or §13.1's decision tree, file an issue at https://github.com/cx-home/cx — the comparison is maintained as a living document; new alternatives and new use-case scenarios are added as the ecosystem evolves.

At-a-glance feature matrix

One-screen feature matrix across CX, JSON, YAML, TOML, and XML. The per-format children (§13.2-§13.11) carry the depth; this matrix is the spreadsheet view.

| Feature | CX | JSON | YAML | TOML | XML | |---|---|---|---|---|---| | Syntax weight | brackets, no closing tags | curly braces + brackets | indent-significant | tables + key=val | open + close tags | | Strong types | ✅ int / float / bool / null / sized / decimal / bigint / date / datetime / bytes / atom | ❌ number only | partial (auto-detect) | ✅ int / float / bool / datetime | partial (xs:type) | | Comments | ✅ block and line | ❌ | ✅ # … | ✅ # … | ✅ | | Mixed content | ✅ first-class | ❌ | ❌ | ❌ | ✅ first-class | | Multiple top-level docs | ✅ no wrapper required | ❌ requires array | ✅ via --- separator | ❌ single document | partial | | Attribute / element distinction | ✅ explicit | ❌ flat keys | ❌ flat keys | ❌ flat keys | ✅ explicit | | Type fidelity through round-trip | ✅ via CXCol | ❌ int↔float coerced | partial | ✅ preserved | partial | | Tabular data efficiency | ✅ `:table` block, columnar binary | ❌ verbose array-of-objects | ❌ verbose | partial (array of tables) | ❌ verbose | | Streaming parser | ✅ pull-based handle API | partial | ❌ usually whole-file | ❌ | ✅ SAX | | Built-in query language | ✅ CXPath value kind, all 12 XPath 3.1 axes | ❌ third-party (jq) | ❌ third-party (yq) | ❌ | ✅ XPath 1.0 / XQuery | | Pure-functional transform | ✅ `[?modify]` focus + 11 actions, structural sharing | ❌ | ❌ | ❌ | partial (XSLT) | | Pattern-match dispatch | ✅ `[?match]` heterogeneous arms | ❌ | ❌ | ❌ | ❌ | | Module system | ✅ `[?def]` / `[?lib]` / cx.lock SRI | ❌ | ❌ | ❌ | partial (XInclude) |

Conversion-loss matrix

Lossless conversion means the data round-trips without semantic loss; presentation details (comments, whitespace, attribute order) may be normalized. The table below is the honest accounting of what survives, what gets normalized, and what is genuinely lossy.

Presentation-layer differences — comments (only XML and CX preserve them; JSON has none; YAML and TOML lose them through most parsers), whitespace (normalised to the target conventions), attribute order (emission may pick a canonical order), anchor names (canonical form renumbers them). These all show up as identical hashes via cx hash because the hash operates on strict-canonical bytes, where presentation is stripped.

When CX wins

CX is the right pick for typed configuration, mixed content alongside structured data, lossless conversion across formats, cases where you need a stable canonical form for hashing or signing, and any pipeline where the query/transform layer (CXPath + [?match] + [?modify]) should live in the same syntax as the data.