Por qué tantas herramientas usan archivos JSON (y cuándo conviene cambiar a TOML o YAML)

Por qué JSON ganó la batalla de los archivos de configuración

Un hilo reciente en textlog.cc reavivó un debate clásico entre desarrolladores: ¿por qué la mayoría de las herramientas modernas insisten en archivos de configuración en formato JSON, si YAML y TOML son más legibles y permiten comentarios? La respuesta corta la dio uno de los participantes: «json.loads hace que sea problema de otros». Y tiene razón.

JSON se convirtió en el estándar de facto porque cualquier lenguaje moderno trae un parser incluido o en su biblioteca estándar. No necesitas negociar dependencias, mantener un esquema propio ni preocuparte por inconsistencias entre versiones. Para un proyecto que quiere arrancar rápido, eso es oro.

¿Por qué los demás formatos no terminaron de desplazar a JSON?

Según el análisis de TechTarget sobre formatos de configuración, TOML es el formato preferido en el ecosistema Python y Rust, y lo usan sistemas como Cargo (el gestor de paquetes de Rust), pytest, mypy, containerd y AWS Serverless Application Model. YAML sigue siendo rey en infraestructura (Kubernetes, Docker Compose, Ansible). Y INI aún domina en herramientas de sistema como Git y systemd.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Entonces, ¿por qué no adoptarlos todos? Tres razones técnicas:

Portabilidad garantizada: un json.loads funciona igual en Python, JavaScript, Go o Rust sin agregar dependencias.
Esquema validable: JSON Schema es un estándar maduro y ampliamente soportado, lo que permite validar configuraciones de forma automática.
Sin ambigüedad: a diferencia de YAML, JSON no tiene el problema de los espacios vs. tabs, ni indentaciones que rompen el archivo silenciosamente.

Cuándo JSON no es la mejor opción

JSON falla en un punto que los participantes del hilo de textlog.cc criticaron con fuerza: no permite comentarios. Y en configuración, donde uno documenta por qué eligió cada valor, eso duele.

Ahí entran las alternativas:

TOML admite comentarios con #, tiene una sintaxis de clave-valor clara y es menos complejo que YAML, lo que lo hace «más predecible y menos propenso a cambios», según TechTarget.
YAML soporta comentarios, referencias (& y *) y es ideal para archivos que personas editarán a mano (CI/CD, manifests de Kubernetes).
INI sigue siendo válido para configuraciones simples a nivel sistema, con la ventaja de que la mayoría de los editores de texto lo manejan sin plugins.

Un punto que TechTarget destaca: el parsing de TOML es generalmente más rápido que el de YAML, pero más lento que el de JSON. Si tu servicio arranca miles de veces al día o procesaconfigsde gran tamaño, eso importa.

El problema real: la aversión a documentar

Más allá del formato, varios commenters en el hilo (incluido el usuario @ricky, veterano de SharePoint con 20+ años de experiencia) coincidieron en que el problema de fondo es cultural: muchos técnicos resisten documentar porque creen que les da seguridad laboral. La realidad, según su argumento, es la opuesta: sin documentación «se atascan en un proyecto» y bloquean su propia movilidad.

Un desarrollador en la conversación resumió bien la filosofía práctica: «Uso JSON para metadatos y configs de máquinas, YAML para humanos. Si un archivo lo va a leer una persona, necesita soportar anotaciones». Es una regla útil para cualquier founder armando un producto técnico.

Qué significa esto para tu startup

Si estás eligiendo el formato de configuración de tu próximo proyecto, no hay ganador universal: hay contexto. La regla práctica que repiten los senior engineers del hilo y la nota de TechTarget es elegir el formato que mejor se alinea con el ecosistema de tu lenguaje principal.

Acciones concretas que podés aplicar esta semana:

Audita tus archivos de configuración actuales: si tenés JSON en un proyecto donde humanos editan a mano (pipelines, configs de deploy), migra a YAML o TOML y vas a reducir tickets de soporte.
Si tu equipo es Python o Rust, movete a TOML: pytest, mypy y Cargo ya lo usan como estándar, así que sumás consistencia sin agregar complejidad.
Documentá el «por qué» en cada bloque de configuración: aunque el formato no soporte comentarios, agregá un README adjunto o un campo _comment (cuando el parser lo permita). El valor está en explicar decisiones, no solo valores.

La discusión del hilo original lo dejó claro: la batalla JSON vs. TOML vs. YAML no se gana con un solo formato. Se gana entendiendo quién lee el archivo, quién lo escribe y cada cuánto cambia.