JSON или YAML — что выбрать, если это почти один формат

Начнём с факта, который снимает половину спора: YAML формально — надмножество JSON. Возьми валидный JSON-файл, скорми его YAML-парсеру — он его прочитает. То есть выбирать «JSON или YAML» — это не выбирать между враждующими лагерями. Это выбирать, кто будет читать файл чаще: программа или человек.

Вот одни и те же данные в обоих форматах:

{
  "name": "kodiq-app",
  "port": 3000,
  "features": ["feed", "lessons"]
}

name: kodiq-app
port: 3000
features:
  - feed
  - lessons

Смысл идентичный. Различия — в характере. Разберём их по критериям, которые реально влияют на жизнь.

Таблица: что важно новичку

| Критерий | JSON | YAML | |---|---|---| | Комментарии | ❌ нет вообще | ✅ # как здесь | | Строгость правил | ✅ жёсткие, сюрпризов нет | ⚠️ мягкие, есть сюрпризы | | Ошибки | Заметные: файл не парсится | Коварные: файл парсится, но не так | | Чувствительность к отступам | Нет (отступы — украшение) | Да (отступы — синтаксис) | | Кто обычно пишет | Программа | Человек | | Где встречается | API, обмен данными, ответы ИИ | Конфиги: CI/CD, docker-compose | | Шум в записи | Скобки, кавычки, запятые | Почти чистый текст |

Две строки таблицы стоит развернуть.

Комментарии — главный практический аргумент. В конфиге постоянно нужно пояснить: «не трогать до релиза», «ключ живёт в .env». JSON этого не умеет в принципе — в формате нет синтаксиса комментария. Для файла настроек это дисквалификация, и именно поэтому конфиги мира сошлись на YAML.

Характер ошибок — главный подвох. Ошибёшься в JSON — парсер откажется читать файл целиком, и ты сразу узнаешь (знакомое «Unexpected token» при парсинге — как раз оно). Ошибёшься в YAML — файл, скорее всего, прочитается, но со смыслом, которого ты не имел в виду: съехавший отступ тихо перевесил настройку в другую секцию, голое no стало false. JSON падает громко, YAML ошибается тихо — а тихая ошибка всегда дороже.

Кому что подойдёт

Вердикт простой, без «зависит»:

• Обмен данными между программами — JSON. API отвечают JSON'ом, структурированный вывод у моделей просят в JSON, данные хранят и пересылают в JSON. Здесь строгость — достоинство: никакой двусмысленности.
• Файлы настроек, которые правит человек, — YAML. Комментарии, никакого синтаксического шума, легко читать глазами. Цена — дисциплина отступов и кавычки вокруг «подозрительных» строк.
• Ты вообще не выбираешь чаще, чем думаешь. GitHub Actions требует YAML, package.json — JSON, API отвечает тем, чем отвечает. Реальный навык — не «выбрать правильный формат», а уверенно читать оба. Благо, как видно из примера выше, это один навык, а не два.

И маленький лайфхак на стыке: если YAML-файл капризничает, а причину не видно — попроси ИИ перевести его в JSON. Перевод мгновенно обнажает структуру: сразу видно, что куда вложено на самом деле.

А что с TOML и другими форматами?

Есть третий заметный формат — TOML (pyproject.toml в Python, Cargo.toml в Rust): задуман как «конфиг без сюрпризов YAML». Встретишь — не пугайся: та же идея «ключ = значение», читается с листа. Но за пределами своих экосистем он редок — для новичка приоритет: JSON и YAML.

Можно ли конвертировать один в другой?

Да, в обе стороны и без потерь для типовых случаев — структура данных у них общая (значения, списки, вложенные объекты). Любой ИИ-ассистент делает это по запросу «переведи в YAML/JSON» — удобно, чтобы поглядеть на файл «другими глазами».

Почему ИИ отвечает JSON, а не YAML?

Потому что ответ модели читает программа, а не человек, — а для программ JSON надёжнее: строгий синтаксис проще проверить, битый ответ виден сразу при парсинге. YAML с его тихими ошибками здесь был бы риском.