Comments 35
При чем тут вообще JSON во всех приведенных проблемах? Давайте разберем заключение:
1-2 -- JSON вообще не при чем. В XML будут те-же проблемы. Да даже со стрингой.
3 -- проблемы большого объема данных, актуально для любого формата.
4 -- максимально капитанское объяснение, которое, опять таки, не проблема конкретно JSONа как формата данных. Не сжимает данные нынче только ленивый
5 -- альтернативы есть. Ну хорошо.
Подведя собственное "заключение" :а был ли при чем тут JSON?
1-2 — JSON вообще не при чем. В XML будут те-же проблемы. Да даже со стрингой.
JSON тут действительно ни при чем. В JSON нет никаких проблем с длинными целыми и датами, как и в XML (в котором их можно на лету сериализовать еще). Проблема в JS.
Возьмите любой нормальный язык, который поддерживает целые неограниченной длины — и все в порядке. Или (как протобуфы) — напишите свою библиотеку, которая будет на лету сериализовать в строки — и даже JS справится.
Но есть действительно серьезные проблемы с джейсоном, которых нет в XML:
ordered lists
ordered maps
sequences
attributes
И вот с ними джейсон не справится никак.
JSON тут действительно ни при чем. В JSON нет никаких проблем с длинными целыми и датами, как и в XML (в котором их можно на лету сериализовать еще). Проблема в JS.
Возьмите любой нормальный язык, который поддерживает целые неограниченной длины — и все в порядке. Или (как протобуфы) — напишите свою библиотеку, которая будет на лету сериализовать в строки — и даже JS справится.
Если ваша реализация отличается от спецификации, то не удивляйтесь потом сюрпризам во время работы.
спасибо за фидбек!
соглашусь, что подобные сложности (большие числа, даты, объёмные данные) могут возникать в любом текстовом формате, не только JSON. Однако JSON сегодня является стандартом для большинства веб-приложений на JavaScript/Node.js, поэтому именно в нём эти грабли встречаются чаще всего. Статья призвана показать, как обходить их в контексте JSON и когда стоит рассмотреть альтернативные форматы.
Правильно ли я понимаю, что вас смущает именно то, что в статье рассмотрены проблемы в контексте JSON (хотя они встречаются и в других форматах), и сам заголовок подаёт их как уникальные для JSON?
Комментатор прав в том, что, исходя из названия статьи, ожидаешь увидеть нечто другое. В статье же обсуждаются не скрытые ошибки/проблемы JSON (от слова "подвести"), а совершенно публичные и понятные свойства или ограничения формата. Поэтому название и содержание статьи несколько не коррелируют.
Это как написать в статье "jpeg. может вас подвести", что при стриминге видео не самая удачная идея пересылать отдельные кадры как jpeg-картинки, а лучше использовать специальный видео-формат с гораздо большим сжатием и другими фишками.
Конкретно JSON подводит так:
Многострочный текст вытягивается в строку. А при компактной сериализации (привет, ndjson) вообще всё вытягивается в одну гигантскую строку.
Экранирование экранирования крайне сложно поддерживать. Привет, конфиги vscode с регулярками в json.
Порядок ключей в объекте недетерминирован. Привет, костыли с массивами массивов для представления объектов.
Нет поддержки комментариев. Привет, костыли с написанием JS возвращающего JSON.
Ребята, я вас услышал! Спасибо за обратную связь!
Поправил заголовок в статье, описание к посту и оставил цитату, что данные проблемы не только для JSON, но так же есть и в других форматах.
Я, конечно, понимаю, что хочется вставить красивое изображение в пост. Но изображения от ИИ все же надо обрабатывать. Иначе создается ощущение, что писали наспех и лишь бы опубликовать.
Давайте вместе посмотрим на изображение. В центре "файл" JSON. А что внутри него? Скобочки, музыкальные ноты, дефисы (не говоря уже про надписи "JSON Pastlets" вокруг, чтобы это не значило). Чтобы исправить это потребуется примерно минут 5-10. Затереть эту глупость и вставить похожим шрифтом хотя бы что-то отдаленно напоминающее JSON, или вообще оставив пустой файлик. И это смотрелось бы гармоничнее. И статья выглядела бы более зрело.
+1
Неужели авторы постов не видят, как отвратительно выглядят эти изображения, что изображения с искажениями вызывают какое-то глубокое отторжение из разряда эффекта зловещей долины?
Хотел тут послушать подборку рождественских песен на нельзятубе - так весь ролик был сгенерирован ИИ. Какое-то время боролся с собой, старался не смотреть, только слушать (песни то классические, прекрасные), но не смог, переключил.
Решил отдохнуть от компьютера, вышел на улицу прогуляться - так даже на уличном баннере вставили на фон. Просто какая-то эпидемия. Или т.н. "контент мейкеры" считают что "да пофиг, они не заметят разницы". Ещё как замечаем! Омерзительная искажённая бездушность ИИ изображений и видео сразу бросается глаза - неужели у вас атрофировано чувство эстетики и вы сами этого не видите?
Администрация хабра, пожалуйста, добавьте в список причин при минусе поста пункт "использование ИИ изображений". Сейчас приходится выбирать "пост небрежно оформлен", но это не совсем то и не даёт автору полезной обратной связи.
Для экономии места и ускорения передачи больших JSON-ответов по HTTP в продакшене практически всегда включают gzip или brotli-сжатие
app.use(compression()); // Включаем сжатие
Только сжатие лучше перенести на уровень proxy-сервера, например, Nginx или Caddy.
спасибо за полезную информацию 👍
Не ,если брать json с картинки ,то проблемы будут точно !
Смысл от Tree если его нельзя минифаить?
Смысл от Tree если он не популярный и поддержка держится на одном смертном, который в любой момент может перестать поддерживать?
Смысл от Tree если есть множество зрелых форматов с большой поддержкой?
Смысл тянуть в кор малоизвестные, со слабой поддержкой библиотеки?
Смысл оскорблений?
Он неминифицированный компактней минифицированного JSON. Об этом есть в статье, которую вы, очевидно, не прочитали.
На моём счету лишь реализация на 2 языках и плагин к 1 IDE. Остальное реализовало комьюнити. Ссылки есть в статье, которую вы, очевидно, не прочитали.
Есть много кривых форматов, которые требуют "большой поддержки". К счастью, Tree не из таких. Об этом есть в статье, которую вы, очевидно, не прочитали.
Смысл делать хорошо, когда можно делать как все? Ну не знаю.. надо спросить у остальных.
Это не оскорбление, а экспертное заключение.
А по $mol_time вы чего не проехались? Я жду столь же обстоятельного разноса.
Всегда или только когда мы не уходим дальше пары вложенности? Даже хак с табуляцией вместо пробелов не сработал. Вы же знаете почему многие выбирают пробелы вместо табов? Как раз из-за вашего пункта про читаемость. Табы везде по разному рендерятся.
Скрытый текст
Я перешел в репы в вашей статьи, у вас там больше контрибьюта, чем в 2 языках и одной IDE. (Возможно вы забыли в гите замаскироваться при коммите).
Вы видимо живете в своём обособленном мире, раз для вас уровень поддержки внешних зависимостей не является одним из критериев выбора.
Вы на вопрос не ответили. Тянуть в кор - использовать как основу и зацикливаться на технологии, а не использовать её где-то один раз для "потыкать, работает, пусть будет".
Был один персонаж, он делил людей на тварей дрожащих и право имеющих. Ознакомьтесь, чтобы не повторить судьбу.
Я устал читать вашу статью про Tree, там воды, надменности и бахвальства больше, чем полезной информации. Уж другие не хочется изучать.
В tree представлении табов обычно получается меньше, чем в json. Взять первый попавшийся реальный JSON. Он весит 157 КБ до минификации и 131 КБ после, а tree представление сразу 133 КБ. В зипе же это 9.56 КБ, 8.13 КБ и 8.14 КБ, соответственно. Незначительный выигрыш минифицированного JSON тут объясняется особенностью данных - тут почти нет экранирования.
Ага, ещё один редактор не посчитал.
Библиотека на 600 строчек не требует "большой поддержки". Даже если вас что-то не устроит - вы её легко перепишете за пол дня с нуля.
Я без понятия зачем говнокодить как все, когда можно этого не делать. Это вы мне скажите зачем.
Плохая аналогия подобна котёнку с дверцей.
Вторая вам понравится - влезет в один тикток.
Мы вроде про формат говорим, а не про библиотеку.
У меня складывается стойкое ощущение, что вы работаете только в своей экосистеме и не работаете в реальном мире. Вообщем какая-то оторванность от реальности.
Аналогия верная, вы сами назначили себя экспертом, сами решили что имеете право выносить решение "проф непригодность" будто судья.
А что там в формате поддерживать? За 9 лет ничего в нём не поменялось. Ну разве что появилось года 4 назад возможность описывать подсвету синтаксиса для своих DSL-ей прямо на Tree:
Формат это же не только описать спецификацию =)
Если вы думаете, что для успеха достаточно представить/выпустить идею/технологию, то это не так. Поддержка не менее важна. Как самого формата, так и экосистемы.
Библиотека на 600 строчек не требует "большой поддержки". Даже если вас что-то не устроит - вы её легко перепишете за пол дня с нуля.
Данные высказывания довольно инфантильны =)
"Мои труды читать надо!" (c) профессор Выбегалло.
Если у вас много однотипных объектов, рассмотрите формат NDJSON (Newline-Delimited JSON). Каждая строка - отдельный JSON-объект:
Хм. В первые слышу об этом формате. В подобных случаях обычно используется формат JSONL.
Отличная статья, спасибо 🧑💻
Нужно поддерживать
.proto-схему и генерировать код.
Это не минус, а плюс, так как позволяет не только документировать схему, но так же генерировать значительную часть кода и метаданные для СУБД.
Для JSON в этих целях используется Swagger.
Для JSON используется JSON Schema.
А OpenAPI (который раньше и назывался Swagger) описывает не просто JSON, а API, причём там тело запроса/ответа не обязано быть в JSON, как и само описание спецификации.
Кстати, сравните:
{
"servers": [
{
"url": "https://development.gigantic-server.com/v1",
"description": "Development server"
},
{
"url": "https://staging.gigantic-server.com/v1",
"description": "Staging server"
},
{
"url": "https://api.gigantic-server.com/v1",
"description": "Production server"
}
]
}servers:
- url: "https://development.gigantic-server.com/v1"
description: "Development server"
- url: "https://staging.gigantic-server.com/v1"
description: "Staging server"
- url: "https://api.gigantic-server.com/v1"
description: "Production server"server
url \https://development.gigantic-server.com/v1
description \Development server
server
url \https://staging.gigantic-server.com/v1
description \Staging server
server
url \https://api.gigantic-server.com/v1
description \Production server
Не понял к чему это? И так понятно, что схему proto бессмысленно сравнивать с JSON Schema. Поэтому я и указал Swagger, так как он позволяет описывать целиком API, как и proto.
Хорошая статья, спасибо за выполненную работу
Почему текстовые форматы не идеальны в разработке: пример на JSON