Интервью с Дугласом Крокфордом - создателем JSON

TypeScript не нужен Статическая и сильная типизация не нужна.

Если не знать кто это сказал, то можно подумать, что это слова очередного говнокодера. После TS ощущения от JS немного неприятные

Господа, давайте я вам вместо Дугласа поясню, что он хотел сказать. Прежде всего стоит понять очень важную вещь: никому никогда не были нужны статические проверки типов сами по себе. Статические проверки типов нужны только как один из инструментов проверки корректности логики. Всё.

Проблема в том, что дизайн JS не дает возможности для достаточно продвинутого вывода типов, потому автоматом TypeScript может проверить вам примерно ничего. Да, есть неплохая инициатива по писанию определений типов для популярных библиотек — это может помочь, но ровно для этих библиотек. Если вы пишете собственную библиотеку — вы снова в дерьме. Аналогичные сорцы со всеми определениями на TypeScript весят намного больше, чем код на JS. А простота чтения — это тоже очень важный фактор для проверки корректности кода.

Когда же вы всё с ног до головы утыкали определениями типов и раздули размер сорцов в три раза, то вы внезапно упираетесь в проблему: выразительных инструментов TypeScript по прежнему даже близко недостаточно для того, чтобы исчерпывающе проверить статическую корректность кода. TypeScript ловит эдак треть всех багов, ту самую треть, которая бы и так была найдена при первом же тестировании, а вот с более сложной логикой он сделать ничего не может.

Позиция же Крокфорда заключается в том, что сложная логика в JS — это самая мякотка, когда у меня функции возвращающие функции возвращающие функции. И именно в этом месте TypeScript не может помочь почти ничем, кроме самых-самых примитивных вызовов. TypeScript очень хорошо подходит для тупой прямолинейной нудной логики, которая пишется чуть ли не копипастой. То есть, примерно в том стиле, в котором он пишется в Java, где уже давно широко распространена машинная генерация и анализ кода. А скоро пойдут в массы всякие Copilot, которые и вовсе будет писать подобный код вместо программиста. Является ли это «преимуществом языка»? Конечно нет — это просто костыли под убогостью этого языка, попытка сильно позже наделить язык теми качествами разработки, которые должны были быть в языке с самого начала, а именно — возможность сосредоточиться на творческом аспекте программирования и оставить рутину компьютеру.

Да. Особенно мне нравиться связка TS + webStorm. В паре они отлично так дополняют друг друга и упрощяют разработку.

Да. Особенно мне нравиться связка TS + webStorm. В паре они отлично так дополняют друг друга и упрощяют разработку

Мимо последний проект на JS у меня с настроенными определениями TypeScript, но я с трудом вспоминаю, когда в последний раз они мне были реально полезны. Хоть и вспоминаю. Ради этих пары раз заморачиваться с TS для меня нет смысла.

Аналогичные сорцы со всеми определениями на TypeScript весят намного больше, чем код на JS

Разве это проблема?

TypeScript ловит эдак всех багов, ту самую треть, которая бы и так была найдена при первом же тестировании, а вот с более сложной логикой он сделать ничего не может.

Так эму это и не нужно. Он спасёт тебя оп простых ошибок типа if (number === string) и подскажет, что сравнение некорректно. А JS ты можешь такую глупую ошибку искать долго.

когда у меня функции возвращающие функции возвращающие функции

По-моему это просто говнокод))) Никогда такого не встречал на фронте, хотя проекты были разные.

Не знаю. У меня впечатление абсолютно противоположное. Единственно что меня бесят подобные вещи: React.HTMLAttributes, например. Такое сходу фиг пропишешь.

Он спасёт тебя от простых ошибок типа if (number === string) и подскажет, что сравнение некорректно. А JS ты можешь такую глупую ошибку искать долго

Для этого есть линты еще. Как правило, очень быстро TS заканчивается с этими «number === string», когда перстает понимать, что там строка, что число, а что — вызов функции. И скатывается в «ехал эни через эни». Об этой убогости системы типов я и писал.

А JS ты можешь такую глупую ошибку искать долго

Веришь-нет — делаю явные преобразования типов и вызов функций у конкретных классов, вроде «[].map.call(...)».

По-моему это просто говнокод))) Никогда такого не встречал на фронте, хотя проекты были разные

Получается, на Angular/React/Vue ты не писал? Только примитивный JS на пару запросов и прямолинейный разбор ответа? В любом мало-мальски сложном проекте ты неизбежно скатишься либо в простыни копипасты, либо тоже самое, но в машинно-генерированном виде, внезапно, через функции и их композицию.

функции возвращающие функции возвращающие функции
в этом месте TypeScript не может помочь почти ничем

Ну как ничем? Он мешает такое говно делать.

функции возвращающие функции возвращающие функции
в этом месте TypeScript не может помочь почти ничем

Ну как ничем? Он мешает такое говно делать

Бинго!

Будто что-то плохое.

Perl умер из-за невменяемой гибкости, JS на плаву тянут только браузеры.

Perl умер из-за невменяемой гибкости, JS на плаву тянут только браузеры

Питон, наверное, так строг и аскетичен, что аж убил перл с лиспом?

Ну, по крайней мере, заставляет писать просто и читаемо.

Вебмакака.

Забавный, кстати, эффект: стоит вытащить какого-нибудь (любого!) идиота в публичное поле, так тут же находится куча народу с пиететом к нему. Очень удобно: и на «авторитета», если что, сослаться можно будет, и собственное ЧСВ потешить (кто тут на нас с Васей?), и главное – думать не надо.

Я не про это. Я про то, что не обязательно каждой переменной присваивать тип или каждой функции.

При присвоении значения в момент инициализации нет, не обязательно, тип функции тоже автоматически определяется (но желательно явно указывать, чтобы точно знать, что ты именно его возвращаешь). Но если ты позволяешь себе использовать any и опускать тип функции, то это уже плохо пахнет.

Разве тот же webStorm проверяет типы? Вроде нет.

Когда ты код пишешь, разве ты сам не смотришь, какой тип здесь ожидается (у любой IDE есть возможность отобразить подсказку с описанием).

От прочитанного в этом треде у меня сложилось впечатление, что люди просто не думают/не смотрят что пишут и не тестируют свой код, а потом катят бочки на ЯП.

Очень удобно: и на «авторитета», если что, сослаться можно будет, и собственное ЧСВ потешить (кто тут на нас с Васей?), и главное – думать не надо

И, судя по всему, работает %)

Ну, по крайней мере, заставляет писать просто и читаемо

И потому на guthub и просто в закрытых проектах от дата сасаентистов столько нечитаемой и неработающей лапши? Конкретно их, наверное, он плохо заставляет.

Но если ты позволяешь себе использовать any и опускать тип функции, то это уже плохо пахнет

Если тип функции занимает больше, чем остальное объявление функции, то это пахнет говном. А это любая нетривиальная функция, между прочим.

Пахнут говном длинные типы функции.

Старый пердун, а тоже по половых мутантах плачет.

откуда берется столько упоротых людей, которые считают, что JS — это объектно-ориентированный ЯП

Оттуда, что ООП это и есть «функциональный язык с динамическими объектами».

Оттуда, что ООП это и есть «функциональный язык с динамическими объектами»

Ну разве что если брать определение ООП по Алану Кею, согласно которому, к слову, C++ и Java сами по себе не является ООП языками.

Думаю, это из-за jupyter notebook-ов. Там можно понаписать лапши.

Писать большие системы на динамиически типизированном языке - это ад, потому как трудно заметить ошибку и линтеры с этим тоже плохо справляются, в результате все баги вылавливаются в рантайме. Те, кто работал с крупными проектами на JS или питоне, неизменно выли. Кроме того, с технической точки зрения это оверхед на прослойку, что не везде приемлемо.

Абстракции того же TS, слизанные с других языков, как и статическая типизация и вообще вся архитектура вместе с синтаксисом в первую очередь нужны людям для удобства понимания, для ограничения их возможности нагадить, это снижает количество багов из-за человеческого фактора, делает код читаемым и поддерживаемым. В маленьких программах это избыточно, но в больших - необходимо.

Технически возможно писать сразу на машинном коде. Зачем вообще какие-то там высокоуровневые языки?

Вот до чего технозадротство доводит - возомнил о себе, что знает за всю отрасль, а все кругом идиоты. Ещё одно доказательство того, как важно изучать гуманитарные науки и качать софт-скиллы.

А ТСу советую заняться реальной разработкой, чтобы лет через 5-10 осознать написанное.

Проблема в том, что дизайн JS не дает возможности для достаточно продвинутого вывода типов, потому автоматом TypeScript может проверить вам примерно ничего. Да, есть неплохая инициатива по писанию определений типов для популярных библиотек — это может помочь, но ровно для этих библиотек. Если вы пишете собственную библиотеку — вы снова в дерьме. Аналогичные сорцы со всеми определениями на TypeScript весят намного больше, чем код на JS. А простота чтения — это тоже очень важный фактор для проверки корректности кода.

Я, конечно, понимаю, что от ЛОРовских дилетантов глупо ожидать даже поверхностного знания языка, про который они орут «нинужна!!!». Но прежде чем писать столь откровенный тупняк и 4.2, тебе стоило бы как минимум ознакомится хотя бы со статьями на википедии про Typescript и статическую типизацию.

Это не так. Абстракции TS нужны человеку, чтобы спокойно использовать паттерны. Например, использование интерфейса гарантирует совпадение структуры у его реализаций. А теперь представь всё то же самое на JS, когда 10 классов должны иметь одинаковую структуру и в этих классах ещё объекты других классов, которые тоже якобы соблюдают какие-то договорённости. Догадываешься, что будет? Каждый раз у кодеров будет стресс при любых изменениях, они будут ползать по всему коду и психовать, а потом кто-нибудь внесёт баг и команда будет месяц его разгребать. Не говоря уже о том, что такой код хрень поймёшь - это надо будет городить кривые костыли, оставлять гору комментов, делать высокое покрытие тестами, иначе совсем в говно скатится.

Также TS значительно лучше линтится и редактор выдаёт подсказки. В проектах всегда говнокод, но на TS его можно разобрать благодаря редактору, на JS же он становится неподдерживаемым.

Многие вещи в ИТ делаются не из технических соображений, чтобы быть хорошим кодером надо интересоватся не только ИТ.

А это вообще какой-то лютый треш. TS это препроцессор, он «компилирует» TS код в JS код, отбрасывая всю TS часть. Выглядит это так же читабельно и вес такой же, какой был бы, если писать на чистом JS. Тулзы по сборке генерируют мапы для дебаггинга, но если жадный - просто отключи. И, естественно, TS ловит ошибки, кривой код просто не «скомпилируется» из-за внутренних проверок. Проверки можно обойти, используя any и прочее говнище - TS в какой-то мере позволяет писать как на JS, но это проблема говнокодеров, а не TS.

TS позволяет писать качественный и современный код, настраивая нужную версию для компиляции - так можно поддерживать древние версии браузеров и ноды, а потом без издержек сразу перейти на новые.

TS, благодаря декларации типов, помогает ориентироваться в коде. Это великолепно при работе с фреймворками и библиотеками: по JS версиям подсказок нет - нужно лезть в код, а TS решает эту проблему. Плохая/отсутствующая документация неистребима, поэтому частичное спасение в статической типизации.

Подозреваю что, как всегда, «критики» не пользуются «критикуемой» технологией и вообще понятия не имеют, как она работает. Это дерьмо весьма типично для рунета.

Война форматов - такая война. Был и есть XML, для которого уже всё есть: схемы в двух форматах DTD и XSD, поиск по XPath, трансформация в XSLT, даже язык звпросов XQuery. Всё это хорошо поддерживается массой библиотек, в том числе в стандартной библиотеке Java. Есть сразу три архитектуры обработки XML: DOM, SAX, StAX. В самом XML есть пространства имён, исключающие коллизии в названиях тагов. Есть возможность писать комментарии. В общем нормальная такая работающая инфраструктура.

Но тут повылазили альтернативно одарённые и началось. Вначале придумали этот ваш JSON, для которого до сих пор нет схемы (есть лишь 9-я версия черновика, который всё никак не допишут), нет нормальных аналогов XPath и XSLT. JsonPath имеет массу ограничений, по сравнению со своим XML аналогом. Всякого рода JsonLogic, JSONata и прочее - откровенный недоделанный хлам. Поддержика JSON и всего что вокруг него неполная, то есть даже откровенно менее функциональные технологии зачастую реализованы не полностью - с ещё меньшим функционалом, чем в их откровенно скудных спецификациях. Поддержки комментариев в JSON нет.

Затем кому-то показалось, что этого мало и был придуман Yaml. В котором всё ещё хуже, но его пихают во все эти кубернетисы, свагеры и прочее непотребство.

А все претензии к XML сводятся к тому, что кто-то не умеет читать, а зодно и думать говолой - не понимает, что основной читатель XML - программа.

В интервью он поясняет о том, что XML никогда и не был человекочитаемым. И именно уродство XML заставило его разработать JSON.

Он там какой-то бред несёт о том, что во времена засилия XML ответ сервера был непонятен и нужно было посылать ещё какой-то запрос, а JSON якобы позволяет этого не делать, а сразу получить данные. Это откровенное враньё. Всё, что позволяет JSON, позволяет и XML. Но XML позволяет даже больше. То есть описанная им проблема, если и была, то вовсе не в XML формате передачи данных.

В итоге получилось бы то, чем сейчас является JSON5.

О боже, ещё один JSON. Думаю, что его постигнет судьба RPM5.

Комментарии есть в JSON5.

А поддержка JSON5 в разных ЯП уже есть? Она полная и стабильная? Есть нормальные схемы, есть полноценные аналоги DOM, XPath и XSLT? А мультистроковый текст без этого уродского обратного слеша в конце строки он поддерживает?

Идея для стартапа — специальные линеечки для подсчета пробелов, для продвинутых ямл-девелоперов.

:-)))

красивый, человекочитаемый XML

Это сарказм? XML ужасен. В нём ещё зачем-то два вида вложенности что создаёт путаницу.

Вот до чего технозадротство доводит - возомнил о себе, что знает за всю отрасль, а все кругом идиоты. Ещё одно доказательство того, как важно изучать гуманитарные науки и качать софт-скиллы

Ты знаешь, последнее впечатление, которое он на меня мог произвести — это «я знаю всю отрасль». Он же даже близко не сказал «так, всем быстро отказываться от TypeScript». Его формулировка была, дословно (36:50):

«Мне это не нужно. Я могу писать хороший жаваскрипт код и без него. Есть утверждение сообщества сильных типизаторов, что невозможно писать хорошие большие программы без типизации. Это просто не правда. Я не хочу сказать, что они ужасные лжецы...».

Мне это не нужно — какие вопросы? Тебе нужно? Ты и пользуйся.

А это вообще какой-то лютый треш. TS это препроцессор, он «компилирует» TS код в JS код, отбрасывая всю TS часть. Выглядит это так же читабельно и вес такой же, какой был бы, если писать на чистом JS

Каким образом это противоречит хотя бы одном слову из моего сообщения? Я знаю какому, я специально его подбирал, чтобы у самого конченного дебилоида не возникло желания до него докопаться, но таки желающие нашлись. Видать, сильно тебе прищемило хвост. Я виноват в том, что ты слепой фанбой TS?

TS позволяет писать качественный и современный код, настраивая нужную версию для компиляции - так можно поддерживать древние версии браузеров и ноды, а потом без издержек сразу перейти на новые

TS ничего не позволяет полноценно проверять типы на Vue, кроме самых последних адаптированных под TS декораторов и функциональных компонентов. Ну то есть возможностей TS не хватает для подхватывания свойств, обработчиков событий, и миксинов, поскольку это всё динамичные фичи и конечная сигнатура компонента формируется в рантайме по достаточно сложным правилам. Абсолютно та же проблема актуальна для любого мало-мальски динамичного JS кода.

С реактом, судя по всему, подобная проблема:
Интервью с Дугласом Крокфордом - создателем JSON (комментарий)

Единственно что меня бесят подобные вещи: React.HTMLAttributes, например. Такое сходу фиг пропишешь

Был и есть XML, для которого уже всё есть: схемы в двух форматах DTD и XSD, поиск по XPath, трансформация в XSLT, даже язык звпросов XQuery

Вообще-то это и было претензией к XML — нужно изучить десять языков для работы с одним языком разметки. В противоположность этому время идет, а JSON не меняется и остается тем же простым языком, который можно освоить за час.

Поддержки комментариев в JSON нет

Чтобы добавить произвольную строку в JSON, не обязательно оформлять ее как комментарий.

Не нужно использовать JSON для ручных конфигов

Лорчую.

Он там какой-то бред несёт о том, что во времена засилия XML ответ сервера был непонятен и нужно было посылать ещё какой-то запрос, а JSON якобы позволяет этого не делать, а сразу получить данные. Это откровенное враньё

Чтобы дальше не продолжать этот испорченный телефон, вот дословная цитата (12:35):

Например, в то время, как я этим занимался, XML уже был повсеместным стандартом. Я просто посмотрел и сказал "это слишком сложно, не должно быть так сложно получить данные". Потому что модель с XML была такой: я посылаю запрос на сервер, и получаю "что-то", и теперь я должен посылать запросы к этому "чему-то", чтобы узнать, что оно знает. Я подумал "это просто смешно, почему нельзя просто получить ответ на мой вопрос, просто дать материал в форме, которая имеет смысл для моей программы?".

Он в чем-то неправ? Основа XML, тэги с содержимым, идет в разрез с устройством большинства данных в языках программирования. За исключением атрибутов XML, которые имеют серьезные ограничения. Какие фундаментальные структуры в ЯП? Массивы, записи, ассоциативные массивы, числа, строки. Какие фундаментальные структуры в XML? Массив из тэгов и текста, где каждый тэг в свою очередь может содержать массив из тэгов и текста. То есть, ассоциативный массив из повторяющихся ключей со сложным содержимым под каждым ключем. Какой ЯП вообще организовывает данные в таком виде? Я не знаю ни одного.

Забавно, что в том же духе я писал сообщение несколько месяцев назад, хотя в то время я еще не знал, кто такой Дуглас Крокфорд:
Универсальный текстовый формат (комментарий) (21.06.21 03:56:06)

программисту непросто сформировать-интерпретировать содержимое XML:
http://nothing-more.blogspot.com/2004/10/where-xml-goes-astray.html
...мы снова и снова приходим к одной и той же проблеме — XML сам по себе не предназначен для отображения данных, в нем нет простых и ассоциативных массивов, в нем есть мешающиеся под ногами пробелы (например, первым дочерним узлом в <obj> является текст с переводом строки и пробелами, а не <zero>)

Сколько работаю, никогда не видел, чтобы кто-то по своей воле использовал REST. Всегда генерируют WSDL и использовать Web Services

Да, вроде этой прокладки. Потому что парсить сам XML тяжело. Что и требовалось доказать

Когда я писал софтину на XML, то одна из первых вещей, по которой я обратился к бэкэнду «а можно ответ в JSON присылать?». На что получил ответ «можно, но у нас уже везде XML».

Я не смотрел, претензии к резюмисту. Я б не удивился, если в оригинале оказалось полностью противоположное мнение.

Наговнокодил Vue, а виноват язык? Блестящая логика.

Вообще-то это и было претензией к XML — нужно изучить десять языков для работы с одним языком разметки.

В том-то и дело, что не обязательно. Да и учится всё это дополнительное довольно быстро.

В противоположность этому время идет, а JSON не меняется и остается тем же простым языком, который можно освоить за час.

XML тоже не меняется и его можно освоить за пол часа.

Чтобы добавить произвольную строку в JSON, не обязательно оформлять ее как комментарий.

А как её оформлять, как несуществующее поле?

Чтобы дальше не продолжать этот испорченный телефон, вот дословная цитата (12:35):

Например, в то время, как я этим занимался, XML уже был повсеместным стандартом. Я просто посмотрел и сказал "это слишком сложно, не должно быть так сложно получить данные". Потому что модель с XML была такой: я посылаю запрос на сервер, и получаю "что-то", и теперь я должен посылать запросы к этому "чему-то", чтобы узнать, что оно знает. Я подумал "это просто смешно, почему нельзя просто получить ответ на мой вопрос, просто дать материал в форме, которая имеет смысл для моей программы?".

Он в чем-то неправ?

В том, что совсем необязательно делать второй запрос к этому чему-то. Первоначальный ответ - это точно такие же данные, как и в случае ответа в формате JSON. Да, в JavaScript работать с JSON удобнее, но одним лишь JavaScript использование JSON не ограничивается. В итоге приходится пользоваться гораздо более примитивными и зачастую недоделанными аналогами всего того, что есть для XML: XPath, XSLT, XSD/DTD, XQuery.

Ещё XML позволяет работать с очень большими данными, например мне приходилось работать с XML-по несколько гигабайт каждый. Просто для XML есть несколько способов работы с ним, а не только полная загрузка в память в виде DOM объекта. Когда ты загружаешь JSON в виде JavaScript объект ты фактически создаёшь аналог DOM. Есть ли для JSON аналоги SAX StAX и на сколько они удобнее? А если не удобнее, то выходит нет у JSON и в этом никакого преимущества.

Кстати, почему JsonPath на столько примитивен? Почему там нет возможности идти назад в поиске, например в предикатах? Ведь нет никаких технически оправданных причин такому ограничению - JSON в JavaScript парсируется в объект - аналог DOM, который позволяет гулять по структуре данных в любую сторону.

Основа XML, тэги с содержимым, идет в разрез с устройством большинства данных в языках программирования. За исключением атрибутов XML, которые имеют серьезные ограничения. Какие фундаментальные структуры в ЯП? Массивы, записи, ассоциативные массивы, числа, строки. Какие фундаментальные структуры в XML? Массив из тэгов и текста, где каждый тэг в свою очередь может содержать массив из тэгов и текста. То есть, ассоциативный массив из повторяющихся ключей со сложным содержимым под каждым ключем. Какой ЯП вообще организовывает данные в таком виде? Я не знаю ни одного.

Причём тут вообще какой-то конкретный ЯП? XML - это формат хранения данных. Он не привязан к какому-то конкретному ЯП, как JSON, но позволяет хранить совершенно любые структуры.

Приведи пример JSON, для которого трудно придумать аналогичный XML.

Наговнокодил Vue, а виноват язык? Блестящая логика

React, Angular, и так далее. Любая либа с достаточно динамичными структурами данных. Когда ты «наконец» получил простые и предсказуемые структуры, то внезапно выясняется, что они нахер не нужны и их можно сгенерить в 10 строчек на JS. И внезапно снова нужно что-то делать с аннотациями типов, которые теперь нужны еще сложнее. При том, что в том же Vue аннотация функции отправки события уже выглядит вот так:

declare type EmitFn<Options = ObjectEmitsOptions, Event extends keyof Options = keyof Options> = Options extends Array<infer V> ? (event: V, ...args: any[]) => void : {} extends Options ? (event: string, ...args: any[]) => void : UnionToIntersection<{
    [key in Event]: Options[key] extends (...args: infer Args) => any ? (event: key, ...args: Args) => void : (event: key, ...args: any[]) => void;
}[Event]>;

Это функция с двумя аргументами, для справки.

В том-то и дело, что не обязательно. Да и учится всё это дополнительное довольно быстро

«Довольно быстро»? JSON вообще учить не надо, он просто работает.

XML тоже не меняется и его можно освоить за пол часа

Прикольные истории, но мой опыт говорит, что это не так. Первое, что я сделал «выучив» XML — это наговнокодил разбор ответа, который сыпется при минимальном изменении формата ответа.

Чтобы добавить произвольную строку в JSON, не обязательно оформлять ее как комментарий.

А как её оформлять, как несуществующее поле?

Да, "__comment__": "Бла-бла-бла"

В том, что совсем необязательно делать второй запрос к этому чему-то. Первоначальный ответ - это точно такие же данные, как и в случае ответа в формате JSON. Да, в JavaScript работать с JSON удобнее, но одним лишь JavaScript использование JSON не ограничивается

Это не «точно такие же данные». JSON нельзя напрямую превратить в XML, и наоборот — кто-то вынужден будет пойти на жертвы и ограничения.

В итоге приходится пользоваться гораздо более примитивными и зачастую недоделанными аналогами всего того, что есть для XML: XPath, XSLT, XSD/DTD, XQuery

Я вот сколько работаю с JSON — мне ни разу не пришла в голову мысль «щас бы по XPath быстренько запрос сделать». Нет, я просто делаю filter/map/reduce — это покрывает 99% всех моих задач. Прикол здесь прежде всего в том, что таких сложных проблем с разбором ответа, как в XML, в JSON просто не наблюдается.

Ещё XML позволяет работать с очень большими данными, например мне приходилось работать с XML-по несколько гигабайт каждый

Я смотрю, у тебя особая хватка и богатый опыт натягивания сов на глобус. А ты уже придумал, что будешь делать при обрыве связи во время передачи твоего многогигабайтного XML? Мне интересно просто узнать, кто и как этот XML генерирует.

Кстати, почему JsonPath на столько примитивен?

Потому что он нахер никому не нужен. «А какая ж тут шморгалка?»

XML - это формат хранения данных. Он не привязан к какому-то конкретному ЯП, как JSON, но позволяет хранить совершенно любые структуры

XML — это язык разметки текста, который внезапно был переделан под хранение данных. JSON настолько же «привязан к языку», насколько XML привязан к веб-браузеру.

Приведи пример JSON, для которого трудно придумать аналогичный XML

Легко:

{"1": "One", "2": 2, "3": ["a", "b", "c"]}

Повторюсь, причём здесь TS? В других языках тоже можно на магии писать. TS не принуждает писать миллион вложенных функций, TS не запрещает спроектировать нормальную архитектуру.

У XML и у JSON разные области применения, сравнивать их так - не корректно. Нет расово верной технологии, есть технологии под задачи.

XML был рождён энтерпрайзом, чтобы гонять туда-сюда тысячи полей. Его валидация важна не только технически, но и организационно: если применить JSON, команды затрахаются договариватся о типе каждого поля, да и надёжность падает, ведь придётся прикручивать кастомную валидацию и стрессовать - а не поменяет ли тип очередной индус. С XML же такие проблемы в принципе не возникают: отдал пример файла, всем всё понятно.

JSON был придуман джаваскриптизёрами для удобства сериализации, на нём удобно делать REST API, сохранять данные в кэш и так далее, он не предназначен для хранения большого объёма данных. Несколько гигабайт JSON - это бред, наводящий на мысли о профпригодности говнокодера.

«Довольно быстро»? JSON вообще учить не надо, он просто работает.

Как и XML, но речь шла о дополнительных технологиях вокруг. Аналоги XPath, XSLT, XSD и прочего, для JSON, необходимо учить не меньше времени.

Прикольные истории, но мой опыт говорит, что это не так. Первое, что я сделал «выучив» XML — это наговнокодил разбор ответа, который сыпется при минимальном изменении формата ответа.

Как в не JavaScript этого не делать, скажем в Java? Читать всё в Map<String, Object> и узнавать что же там за Object такой через рефлекшен?

Да, "__comment__": "Бла-бла-бла"

Зашибись. А теперь расскажи как мне быстро закомментировать кусок JSON-а, если я временно хочу попробовать без него и может быть позже захочу вернуться к первоначальной его версии. В XML я просто выделяю нужные кусок и жму в IDE Ctrl+/. Ты уже догадался как он их комментирует?

TypeScript не нужен

Согласен, ведь JS тоже не нужен.

JSON хорош тем, что он всегда останется таким, какой он есть. Но если бы Дуглас разрабатывал его сейчас, то он бы его еще больше упростил

YAML, никаких кавычек и скобочек.

У XML и у JSON разные области применения, сравнивать их так - не корректно.

Это неправда или полуправда. Практически везде, где сейчас используется JSON можно использовать XML.

Нет расово верной технологии, есть технологии под задачи.

В случае JavaScript кое кто решил, что JSON - расово верная технология (поскольку там она легко мапится в JavaScript Object) и все должны ей пользоваться. И вообще, фронтэндеры почему-то решили, что они могут диктовать бекэндерам как им передавать данные. В JavaScript используется прототипное программирование, которое плохо сочетается в объектно-ориентированным программированием в Java. Именно поэтому вебмакаки придумали node.js - у них мозги иначе просто не работают.

XML был рождён энтерпрайзом, чтобы гонять туда-сюда тысячи полей. Его валидация важна не только технически, но и организационно: если применить JSON, команды затрахаются договариватся о типе каждого поля, да и надёжность падает, ведь придётся прикручивать кастомную валидацию и стрессовать - а не поменяет ли тип очередной индус. С XML же такие проблемы в принципе не возникают: отдал пример файла, всем всё понятно.

Валидация необходима для базовой проверки корректности данных. Ещё раз, у вас в JS прототипное программиорование и динамическая типизация. Вы просто загоняете любой JSON мусор в Object и дальше с ним говнокодите. Белые же люди привыкли использовать строгую типизацию и когда приходит JSON, который не соответствует схеме, это означает, что его попросту невозможно десериализовать, кроме как в бесполезный Map<String, Object>. Именно поэтому и возникла необходимость в JsonSchema, которую всё никак не доведут до ума.

JSON был придуман джаваскриптизёрами для удобства сериализации, на нём удобно делать REST API, сохранять данные в кэш и так далее, он не предназначен для хранения большого объёма данных. Несколько гигабайт JSON - это бред, наводящий на мысли о профпригодности говнокодера.

JSON был придуман джаваскриптизёрами для удобства самих джаваскриптизёров и точка! Всё остальное, тобой перечисленное - обыкновенная блажь.

Что касается больших объёмов данных, которые я упомянул, речь шла о конфигурации оборудования мобильной связи.

YAML, никаких кавычек и скобочек.

YAML - это level up в JSON головного мозга. Ещё более идиотский формат данных.

гений ты наш непризнанный, напиши-ка REST API на XML, я хочу это видеть :)