STXT frente a JSON

JSON hace su trabajo con una gramática mínima, un solo modelo de datos y parsers en todas partes; es la lengua franca de las APIs. La comparación solo tiene sentido en el punto donde los dos se solapan — un fichero que una persona tiene que escribir y mantener a mano —, porque ese es el trabajo que JSON nunca prometió hacer.

El mismo contenido, dos veces

La ficha de un artículo en JSON:

{
	"article": {
		"title": "Modern Software Architecture",
		"published": "2026-09-01",
		"tags": ["software", "architecture"],
		"summary": "A survey of monoliths and microservices.\nSecond line, with \"quotes\"."
	}
}

Y en STXT:

Article: Modern Software Architecture
	Published: 2026-09-01
	Tag: software
	Tag: architecture
	Summary >>
		A survey of monoliths and microservices.
		Second line, with "quotes".

Qué los separa al escribir a mano

Cada diferencia de abajo es una decisión deliberada de JSON que sirve a la serialización, y estorba a la autoría:

• Todo va entrecomillado y delimitado. Claves y cadenas entre comillas, objetos entre llaves, elementos entre comas — y la coma tras el último elemento es un error de sintaxis. En STXT la estructura es la indentación y un nombre termina en :.
• Sin comentarios. La exclusión es intencionada en JSON; en un fichero mantenido a mano es lo primero que se echa de menos. STXT tiene comentarios con #, y las herramientas los conservan al formatear.
• Un texto es una línea. Los saltos se escriben \n, las comillas se escapan, y un párrafo se convierte en una sola cadena con escapes. En STXT un bloque >> contiene el texto literal, tan largo como haga falta.
• Sin esquemas en el lenguaje. JSON Schema existe, pero es una especificación aparte, escrita en el propio JSON, con vocabulario propio de composición y referencias. La capa de plantillas de STXT forma parte del lenguaje y se lee como el documento que describe.

De STXT a JSON

STXT no compite con JSON como formato de intercambio: lo adopta. STXT ha elegido JSON como representación de su árbol lógico, porque representar una estructura de datos que van a consumir programas es exactamente el trabajo para el que JSON está diseñado. STXT-TREE-SPEC define esa representación canónica para todo documento válido — un array de nodos raíz con name, canonicalName, namespace, y value más children, o lines —, idéntica en todas las implementaciones. El comando stxt describe fichero.stxt la imprime, y las tres bibliotecas la exponen en su API, así que todo lo que venga detrás esperando JSON sigue funcionando. La fuente queda legible; la serialización queda mecánica.

Cuándo usar cada uno

Usa JSON para lo que intercambian las máquinas: cargas de API, estado serializado, artefactos generados que nadie edita. Su ubicuidad es la característica, y STXT no intenta sustituirlo ahí.

Escribe STXT cuando hay una persona en alguno de los dos extremos del fichero: documentos, configuración, registros corporativos, contenido que alimenta un pipeline — y deja que las herramientas emitan el árbol canónico donde se espere JSON. El caso de uso de IA y LLMs enseña esa ruta de punta a punta: documentos generados legibles, validados, consumidos como JSON.

Para ver el lenguaje, empieza por el tutorial o abre los ejemplos en el playground; la versión de un párrafo de esta página está en la FAQ.