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

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

Может тебе ещё лекцию про Spring Boot прочитать? Вот тебе сходу один из первых нагугленных примеров: https://www.bezkoder.com/spring-boot-rest-xml/

Я уже написал, в каких задачах применяется XML, совсем не удивительно видеть его в одном из основных энтерпрайз фреймворке. Но почему ты не хочешь бахнуть на нём какой-нибудь виджет погоды? И чтобы клиентский код в браузере парсил полей эдак 100, это же очень удобно, не то что поганый JSON.

Ты просил REST на XML и говорил, что это супер сложно и неудобно. Я показал тебе как легко и просто сделать REST на XML. Теперь ты решил подменить тезис и заговорил о клиентском коде. Почитай про AJAX и в частности про значение буквы X в этой аббревиатуре.

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

Это я TS процитировал, если что. Это не миллион вложенных функций, это просто события на компоненте, на которые вешаются обработчики. Всё, больше никакой «магии» — а по итогу 4 строки сплошного криптокода одних определений.

XML был рождён энтерпрайзом, чтобы гонять туда-сюда тысячи полей

XML накладно парсить. Как и любой текст. Потому ни для каких «тысяч полей» он на самом деле тоже не предназначен. Он предназначен для того, чтобы херак-херак — и в продакшен. Потом потенциально сделать хорошее решение вместо этого временного, вроде того же protobuf. С самого начала Protobuf подраузмевал наличие прокладки, как и XML, только в отличие от XML он еще и эффективен в передаче данных.

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

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

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

Не знаю, как там в жаве это делается, а на паскале я просто дергал функцию node.get_type() или что-то такое.

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

Не можешь. Ты не можешь в XML закомментировать атрибут, не всегда можешь закомментировать кусок текста, не можешь написать коммент-пояснение в конце строки. Еще ты соснешь со вложенными комментариями — потому я ненавижу XML-подобные шаблоны во Vue, которые хрен покомментируешь. В народе про такую ситуацию говорят «не можешь срать — не мучай жопу», XML с комментами смотрится как жираф с балалайкой. «Зато балалайка есть, а у вас нету».

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

Я тоже так умею: «Практически везде, где сейчас используют самолеты, можно использовать самокаты».

В JavaScript используется прототипное программирование, которое плохо сочетается в объектно-ориентированным программированием в Java. Именно поэтому

Именно поэтому Java не нужна. Java слила абсолютно все ниши, пора бы закопать, но она вечна, как кобол: новый софт на нем не пишут, но старого написали столько, что еще минимум одно поколение будет кормиться поддержкой.

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

Из топовых еще Go и питон.

Я почему-то не дождался простого XML аналога моего кода на JSON.

Java слила абсолютно все ниши

Надо передать это энтерпрайзу и андроиду, а то эти идиоты так и продолжают на ней писать, потому что есть много взрослых библиотек и фреймворков. Считают там свои риски при выборе технологии, вот же тупые, да?

Там 5 стрелочек, а остальное требует рефакторинга с применением ООП. Т.е. мне ещё надо доказывать, почему это говнокод?

Я показал тебе как легко и просто сделать REST на XML

На бэкенде. По твоему мнению, в проектах есть только бэк и только на Java? Кстати, JSON на Java такой же удобный.

Надо передать это энтерпрайзу и андроиду, а то эти идиоты так и продолжают на ней писать, потому что есть много взрослых библиотек и фреймворков. Считают там свои риски при выборе технологии, вот же тупые, да?

А что дроид? Они по итогу тихонько перекатываются в сторону крестов и Flutter. Так-то андроидная жава — это восьмерка (2014 год).

А в «энтерпрайзе» и на коболе пишут, и на VBA, и ничо.

Там 5 стрелочек, а остальное требует рефакторинга с применением ООП. Т.е. мне ещё надо доказывать, почему это говнокод?

Это официальный релизный код Vue 3.

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

Похоже, что главный твой аргумент - это: «я этого не знаю, значит этим никто не пользуется, значит это никому не нужно». XPath решает не какую-то, тобой придуманную, проблему в XML, а задачу поиска данных в большой структуре данных. Тем же самым пытается заниматься и JsonPath. Ты конечно же можешь делать то же самое ручным обходом дерева объектов, но это явно непрофессиональный путь.

Не можешь. Ты не можешь в XML закомментировать атрибут, не всегда можешь закомментировать кусок текста, не можешь написать коммент-пояснение в конце строки. Еще ты соснешь со вложенными комментариями — потому я ненавижу XML-подобные шаблоны во Vue, которые хрен покомментируешь. В народе про такую ситуацию говорят «не можешь срать — не мучай жопу», XML с комментами смотрится как жираф с балалайкой. «Зато балалайка есть, а у вас нету».

То, что нужно закомментировать в XML прекрасно комментируется. Например вместо комментирования аттрибута люди дублируют строку с тагом, одну комментируют, а вторую редактируют. В твоём любимом JSON нельзя комментировать ничего от слова совсем, а JSON5 не взлетел.

Именно поэтому Java не нужна. Java слила абсолютно все ниши, пора бы закопать, но она вечна, как кобол: новый софт на нем не пишут, но старого написали столько, что еще минимум одно поколение будет кормиться поддержкой.

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

Из топовых еще Go и питон.

Что из топовых, к чему ты это сказал? Да, там есть поддержка JSON, равно как и поддержка XML. И что?

Я почему-то не дождался простого XML аналога моего кода на JSON.

Твоего кода я вообще не видел. Я не фронтэндер, почитай про AJAX сам.

Чем это оправдывает говнокод? Фреймворки им поголовно страдают. У Fastify тоже есть страшные декларации, потому что TS прикручивается по остаточному принципу. Джаваскриптеры пишут так же, как привыкли на JS, нужно больше свитчеров с нормальных языков.

На бэкенде. По твоему мнению, в проектах есть только бэк и только на Java? Кстати, JSON на Java такой же удобный.

У вас в браузере есть встроенная поддержка XML и XSLT. Можешь трансформировать первый в HTML и инжектить куда требуется. Можешь просто читать XML в виде XMLDocument и искать в нём данные при помощи XPath.

И кстати, JSON на Java гораздо неудобнее XML на Java, в силу своей изначальной ущербности и недоделанности, как на уровне спецификаций, так и на уровне реализаций.

Можешь трансформировать первый в HTML и инжектить куда требуется. Можешь просто читать XML в виде XMLDocument и искать в нём данные при помощи XPath.

Всё верно: в браузере XML применяется для подобных задач. А JSON применяется для обмена небольшим количеством данных, которые обрабатываются в JS и потому сериализация/десериализация удобнее. Ещё пруф, с небольшими примерами.

Применение XML для всех задач сериализации/десериализации влечёт следующие последствия:

• Избыточный код, а значит, увеличение времени на разработку и тестирование;
• Увеличение трафика, ввиду многословного синтаксиса XML;
• Снижение производительности;
• Затруднения с некоторыми технологиями, например - Web Storage, из-за многословности XML и большим расходом ресурсов на его обработку.

JSON на Java гораздо неудобнее XML на Java

Пример на спринге это опровеграет. Вообще никаких лишних обвязок. А из-за того, что JSON прост, можно ещё вот так.

Таким образом, приходим к выводам:

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

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

Дуглас не доволен множеством нововведений в JS и он пользуется только подмножеством языка, как всегда и декларировал. Ему не нравится реализация Promise и он считает сахар async/await лишним.

Налицо ретроградство и нежелание изучать новое.

Чтобы стать крутым нужно постоянно учиться

Хм.

Всё верно: в браузере XML применяется для подобных задач. А JSON применяется для обмена небольшим количеством данных, которые обрабатываются в JS и потому сериализация/десериализация удобнее.

То есть вместо code reuse вы держите сразу два парсера и кучу библиотек. Тот код, который ты привёл в пример, мог бы быть таким же коротким, дёргающим стандартную функцию, возвращающую XMLDocument, на которую ты мог бы запускать тривиальнейший XPath, скажем /root/key, вместо json['key'].

Пример на спринге это опровеграет.

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

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

Вот тебе другая статья на эту тему: https://codepunk.io/xml-vs-json-why-json-sucks/

Похоже, что главный твой аргумент - это: «я этого не знаю, значит этим никто не пользуется, значит это никому не нужно»

Всё просто: найди второго человека, который пользуется (или хотя бы знает про) JsonPath на LOR-е. А вот нет таких. Ты переходишь на личности, но «личностей» тебе тут может ответить много, и все скажут примерно одно и то же.

Тем же самым пытается заниматься и JsonPath

Да, я занимаюсь тем же самым без необходимости в пятом-десятом ad-hoc языке, как это принято в среде XML.

Ты конечно же можешь делать то же самое ручным обходом дерева объектов, но это явно непрофессиональный путь

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

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

Ты траллишь, да? То есть, когда нужно лепить лапшу из XML — это нормально, это грамотный подход, а когда это же нужно делать для JSON — это никуда не годится, кто же так делает.

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

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

Ну назови мне значимый проект последних 6 лет, написанный на жаве? Естественно, «в значимые» я не включаю приложения для просмотра картинок на андроиде, написанные очередным школьником. С тех пор, как Go и нода вошли в мейнстрим, они сожрали большую часть ниш Java на бэкэнде, а вебсайты на JS сожрали фронтендовую часть. Со стороны винды поджимает C#, который умеет эффективно работать и на сервере, и на клиенте, и при этом развивается побыстрее, чем Java.

Что из топовых, к чему ты это сказал? Да, там есть поддержка JSON, равно как и поддержка XML. И что?

К тому, что XML для этих языков настолько же «чужероден», как JSON. Твой тезис был «JSON был придуман джаваскриптизёрами для удобства самих джаваскриптизёров и точка!» — но это не так. И показателен тот факт, что ты не понимаешь, что синтаксис в JSON не играет никакой роли, он просто случайно был слизан с JS, но с таким же успехом мог быть взят с питона, PHP, или R. К слову о чужеродности:

dynamic stuff = JsonConvert.DeserializeObject(
    "{ 'Name': 'Jon Smith', 'Address': { 'City': 'New York', 'State': 'NY' }, 'Age': 42 }");

string name = stuff.Name;
string address = stuff.Address.City;

Всё просто: найди второго человека, который пользуется (или хотя бы знает про) JsonPath на LOR-е.

Да, сейчас позвоню Макскому и договорюсь о проведении срочного опроса. Я этим JsonPath специально не интересовался, а узнал о нём по работе, причём уже у нескольких работодателей. То, что тебе, быть может в силу твоей фронтэндости, не приходилось слышать об этой технологии не означает, что она малоизвестна.

Ты переходишь на личности, но «личностей» тебе тут может ответить много, и все скажут примерно одно и то же.

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

Да, я занимаюсь тем же самым без необходимости в пятом-десятом ad-hoc языке, как это принято в среде XML.

И как ты это делаешь?

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

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

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

Ты траллишь, да? То есть, когда нужно лепить лапшу из XML — это нормально, это грамотный подход, а когда это же нужно делать для JSON — это никуда не годится, кто же так делает.

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

<root>
	<!--<a	href="http://www.linux.org.ru" enabled="true">-->
	<a	href="http://www.opennet.ru" enabled="true">
		Click me now
	</a>
</root>

<root>
	<a	href="http://www.linux.org.ru" enabled="true">
	<!--<a	href="http://www.opennet.ru" enabled="true">-->
		Click me now
	</a>
</root>

В JSON нет возможности комментировать в принципе. В XML есть возможность написать XSLT код трансформации XML и внутри этого кода использовать комментарии. В JSON есть свои аналоги для трансформации (JsonLogic, JSONata), но писать там комментарии точно так же нельзя, что делает их ещё более ущербными.

Ну назови мне значимый проект последних 6 лет, написанный на жаве? Естественно, «в значимые» я не включаю приложения для просмотра картинок на андроиде, написанные очередным школьником. С тех пор, как Go и нода вошли в мейнстрим, они сожрали большую часть ниш Java на бэкэнде, а вебсайты на JS сожрали фронтендовую часть. Со стороны винды поджимает C#, который умеет эффективно работать и на сервере, и на клиенте, и при этом развивается побыстрее, чем Java.

Бэкэнд всё ещё пишится преимущественно на Java. .NET и C# не сумели потеснить Java и особой популярностью не пользуются. Например у моего нынешнего работодателя происходит вытеснение дотнета джавой. Названия проектов тебе ничего не скажут, потому что это не приложения для конечного пользователя, которые ты можешь установить себе на глупофон или на локалхост.

Да, в последнии 2 - 3 года наметилась тенденция снижения популярности Java. Но до состояния «Java сливает» ещё довольно далеко, даже в новых проектах.

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

На основании чего ты это утверждаешь? История создания JSON говорит об обратном.

И показателен тот факт, что ты не понимаешь, что синтаксис в JSON не играет никакой роли, он просто случайно был слизан с JS, но с таким же успехом мог быть взят с питона, PHP, или R.

Проблема не в синтаксисе как в таковом, а в его ограниченности и ограниченности окружающих JSON технологий. Например отсутствие комментариев. Некоторые пользователи JSON пытаются имитировать то, что в XML есть из коробки. Например встречается имитации атрибутов, через поля, называющиеся с префиксом @. Например ObjectMapper в Jackson Databind под Java использует @class. Попытки сделать в JSON аналоги того, что есть XML говорят о том, что JSON и его инфраструктура всё ещё весьма ущербны.

Дуглас не доволен множеством нововведений в JS и он пользуется только подмножеством языка, как всегда и декларировал. Ему не нравится реализация Promise и он считает сахар async/await лишним.

Налицо ретроградство и нежелание изучать новое

Два из трех жаваскриптеров на рынке пишет с линтером, единственное назначение которого — бить по рукам программиста, использующего опасные фичи языка. Но нет, на LOR-е знают, что нужно пользоваться всеми фичами, они хорошие.

Вот обзор хороших фич ES6 от Дугласа:
https://www.youtube.com/watch?v=XFTOG895C7c#t=17m50s
А вот в том же видео обзор плохих:
https://www.youtube.com/watch?v=XFTOG895C7c#t=23m55s

С лямбд, кстати, у меня жопа погорела знатно, потому что у них абсолютно невменяемый синтаксис возврата объектов. Ну и как я уже писал в соседнем треде
Safely iterating over WeakKeyDictionary and WeakValueDictionary (комментарий)
классы ни в коем случае нельзя использовать:
https://www.youtube.com/watch?v=XFTOG895C7c#t=26m30s

А вот про то, какие глобальные приемы-подмножества он применяет в своем коде:
https://www.youtube.com/watch?v=XFTOG895C7c#t=27m40s

Если же ты до сих пор считаешь, что он — старый пердун, потому что не применяет приемы писания JS из бложика 20-летней HR-ки — то извиняй.

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

Зачем же тащить эти опасные фичи языка в языке? Не проще ли изменить сам язык или перейти на другой язык? Хотя нет, дай догадаюсь, ведь тогда придётся продвигать его во все браузеры, переучивать толпы фронтэндеров и ждать, когда это станет достаточно популярным.

К слову, мой банк использует плагин от Acrobat Reader для того, чтобы перед окончанием выполнения некоторых операций на счету показать внутри страницы PDF с текстом условий и чуть ниже чекбокс для согласия с ними. Пока на чекбокс не нажмёшь, операцию завершить невозможно, а без текста PDF этот чекбокс вообще неактивен. В Firefox давно отказались от плагинов от Acrobat Reader и показывают PDF самостоятельно. Но вебмакаки из моего банка уже год не могут это осилить, потому что в Chrome это непотребство продолжает работать. Вот так со всем во фронтэнде - если что и работает, то именем китайской революции. Тонны динамически типизированного говнокода, километры варнингов в консоле по F12, совместимость вообще никакая и на каждый чих свой пакет в npm. Терпеть этот ваш фронтэнд не могу.

Да, сейчас позвоню Макскому и договорюсь о проведении срочного опроса. Я этим JsonPath специально не интересовался, а узнал о нём по работе, причём уже у нескольких работодателей. То, что тебе, быть может в силу твоей фронтэндости, не приходилось слышать об этой технологии не означает, что она малоизвестна

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

Да, я занимаюсь тем же самым без необходимости в пятом-десятом ad-hoc языке, как это принято в среде XML.

И как ты это делаешь?

Я уже писал — filter/map/reduce/forEach или просто доступ по ключам. Всё, этого достаточно для 99% случаев. Именно потому JSON укатал XML.

Нет, данные приходят в формате, который проще десериализовать в JavaScript Object, только и всего

А еще в питон, в Go, в C#. Это из тех, что я знаю.

Вне JavaScript аналог Object не прототайпный и чаще даже не динамически типизированный, что делает JSON просто ещё одним форматом

Прототипность не имеет здесь никакого отношения. Динамичность — да. Что JSON — это еще один формат, я писал с самого начала, Причем, далеко не единственный возможный и не самый оптимальный. Но, тем не менее, для передачи динамичных данных он выше XML на голову, а для статичных типов есть protobuf, который в статике выше XML на две головы. У XML просто нет ниш, его продолжают использовать по инерции.

В XML есть способы комментировать, пусть и без возможности комментирования отдельных аттрибутов:
В JSON нет возможности комментировать в принципе

[
    { "name": "a", "href": "http://www.opennet.ru", "enabled": true, text: "Click me now" }
]

Закомменчено:

[
    { "name": "a", "href": "http://www.opennet.ru", "__enabled__": true, text: "Click me now" }
]

По прежнему. ни способ JSON, ни способ XML рядом не валяются с настоящими комментариями исходных кодов, которые можно писать в конце строки, вставлять в любое месте текста, или комментировать всю строку. Комменты JSON так же убоги, как комменты XML, но даже перед всеми фактами ты продолжаешь рассказывать «говно не пахнет, если оно лежит у меня на голове».

Бэкэнд всё ещё пишится преимущественно на Java. .NET и C# не сумели потеснить Java и особой популярностью не пользуются. Например у моего нынешнего работодателя происходит вытеснение дотнета джавой

М-м-м, нет, не на джаве, но и не преимуещственно на ASP.NET:

https://insights.stackoverflow.com/survey/2021#most-popular-technologies-webf...

То, о чем я изначально говорил — это что Java вообще-то изначально доминировала в этой нише. Как правило, инерция в IT высока и потеснить популярное решение очень тяжело. Но если решение очень плохое, как Java, то потеснить его не составляет труда — потому в статистике Express (node.js) жуе несколько лет стабильно выше как ASP.NET, так и Spring:

https://insights.stackoverflow.com/survey/2019#technology-_-web-frameworks

А там уже сразу за шпрингом идут Django, Flask, Лававель, Рельсы — последние закрывают список популярных бэкэнд-платформ.

Потому речь идет не про «Java сливает», а про «Java давно слилась и потихоньку отживает своё».

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

На основании чего ты это утверждаешь? История создания JSON говорит об обратном

И я должен, следуя твоей логике, говорить, что XML чужд жаве потому, что Java плохо отрисовывает HTML страницы? Ты бредишь. JSON имеет так же мало отношения к JS, как XML имеет мало отношения к WWW.

Зачем же тащить эти опасные фичи языка в языке? Не проще ли изменить сам язык или перейти на другой язык?

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

В Firefox давно отказались от плагинов от Acrobat Reader и показывают PDF самостоятельно. Но вебмакаки из моего банка уже год не могут это осилить, потому что в Chrome это непотребство продолжает работать. Вот так со всем во фронтэнде - если что и работает, то именем китайской революции. Тонны динамически типизированного говнокода, километры варнингов в консоле по F12, совместимость вообще никакая и на каждый чих свой пакет в npm. Терпеть этот ваш фронтэнд не могу

Отображаю PDF в браузерах, работает на FF и хроме, никаких ворнингов в консоли нет, использую линты TS. Что я делаю не так?

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

Так речь шла далеко не только о кодерах на JS. Например я на JS почти не пишу.

Я уже писал — filter/map/reduce/forEach или просто доступ по ключам. Всё, этого достаточно для 99% случаев. Именно потому JSON укатал XML.

Так просто это можно делать лишь в JS, где JSON нативно десериализуется в Object. Сколько ещё повторять, что разговор далеко не только про JS?

А еще в питон, в Go, в C#. Это из тех, что я знаю.

Там это не проще, потому что там это не нативно, а реализовано в виде библиотек. Как и в Java.

Прототипность не имеет здесь никакого отношения. Динамичность — да.

Разве возможность в рантайме добавлять в объект любое новое поле или функцию - не прототипность? Разве у вас в JS надо обязательно объявлять структуру данных перед её использованием?

Что JSON — это еще один формат, я писал с самого начала, Причем, далеко не единственный возможный и не самый оптимальный. Но, тем не менее, для передачи динамичных данных он выше XML на голову, а для статичных типов есть protobuf, который в статике выше XML на две головы. У XML просто нет ниш, его продолжают использовать по инерции.

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

[
   { "name": "a", "href": "http://www.opennet.ru", "enabled": true, text: "Click me now" }
]

Закомменчено:

[
   { "name": "a", "href": "http://www.opennet.ru", "__enabled__": true, text: "Click me now" }
]

Нет, это не комментарий, это нарушение схемы. В итоге у тебя либо десиреализация упадёт, либо валидация ещё до неё, если ты используешь JsonSchema. В JS это тебе создаст поле __enabled__ вместо enabled, но в статически типизированных ЯП это так не работает.

По прежнему. ни способ JSON, ни способ XML рядом не валяются с настоящими комментариями исходных кодов, которые можно писать в конце строки, вставлять в любое месте текста, или комментировать всю строку. Комменты JSON так же убоги, как комменты XML, но даже перед всеми фактами ты продолжаешь рассказывать «говно не пахнет, если оно лежит у меня на голове».

Зачем ты продолжаешь спорить с очевидным? В JSON нет комментариев от слова совсем. Любое другое утверждение по этому поводу есть ложь. Твой пример выше - не про комментарии и во многих случаях работать не будет. Комментарии XML может быть действительно немного хуже комментариев в C/C++/Java/C#, но всё таки гораздо лучше их отсутствия в JSON.

М-м-м, нет, не на джаве, но и не преимуещственно на ASP.NET:

Причём тут вообще ASP.NET, когда я сравнивал с C# ?

https://insights.stackoverflow.com/survey/2021#technology

Ну да, вебмакаки и node-исты чаще программируют гуглением, а не собственными мозгами.

То, о чем я изначально говорил — это что Java вообще-то изначально доминировала в этой нише. Как правило, инерция в IT высока и потеснить популярное решение очень тяжело. Но если решение очень плохое, как Java, то потеснить его не составляет труда — потому в статистике Express (node.js) жуе несколько лет стабильно выше как ASP.NET, так и Spring:

https://insights.stackoverflow.com/survey/2019#technology-_-web-frameworks

Ты бы поинтересовался, что ли, о каком Spring там речь и какой именно Spring сравнивают с чисто фронтэндовскими технологиями. Такими как jQuery, React и Angular. Подскажу - речь вовсе не о бэкэндовском Spring, а о Spring MVC, который к бэкэнду имеет весьма опосредованное отношение. Ты бы ещё JavaServer Faces (JSF), в качестве бэкэнд технологии, вспомнил.

Потому речь идет не про «Java сливает», а про «Java давно слилась и потихоньку отживает своё».

Не на бэкэнде. Может быть лет через 5 - 10 она там таки сольёт, но этого пока не произошло.

И я должен, следуя твоей логике, говорить, что XML чужд жаве потому, что Java плохо отрисовывает HTML страницы? Ты бредишь. JSON имеет так же мало отношения к JS, как XML имеет мало отношения к WWW.

XML не чужд джаве прежде всего потому, что там есть его полная поддержка прямо в стандартной библиотеке. Для отрисовки HTML страниц в джаве есть JSP, но они потеряли свою популярность, потому что типичный веб макака не умеет в JSP, JSTL и в Java. Вебмакака любит node.js или что-то типа jhipster (всё на том же node.js) который умеет генерировать тонны говнокода на незнакомой джаве технологически недоразвитым вебмакакам.

XML имеет прямое и непосредственное отношение к WWW. Одной из задумок было отделить данные от способа их представления и вместо каши всего этого вмести (внутри HTML) передавать отдельно XML и XSLT, трансформирующиеся в конечный HTML на стороне браузера. Но вебмакаки повели эволюцию WWW по другому пути. XML и HTML происходят от одного предка - SGML и вся эта троица является ML - markup languages. Заявление об отсутствии связи между XML и WWW может делать лишь человек, не понимающий о чём он говорит.

Пишет мне человек, который никак не может выкинуть мусор по имени Java.

Зачем мне выкидывать то, что хорошо меня кормит?

Причем, там-то точно никакой браузер не заставляет давиться говном — это делают сугубо добровольно.

Ты так говоришь, как будто менеджеры моих работодателей слёзно просят уйти, наконец, с джавы, а я их посылаю матом и продожаю писать бэкэнд только на ней, как ни в чём не бывало :-))

Отображаю PDF в браузерах, работает на FF и хроме, никаких ворнингов в консоли нет, использую линты TS. Что я делаю не так?

Это не ты делаешь что-то не так, а вебмакаки из моего банка никак не осилят актуальные технологии.

Так просто это можно делать лишь в JS, где JSON нативно десериализуется в Object. Сколько ещё повторять, что разговор далеко не только про JS?

Да, я уже догадался, что ты пишешь только за Java, и все твои фразы могут быть интерпретированы как «мне неудобно на Java работать с JSON». А теперь смотри, как это делается на C#:

var tmpResult = JObject.Parse(File.ReadAllText(FileName));
var resultObject = tmpResult["SetNavRecords"].Values("OfflineVerkaufspreis").Values<JObject>()                                   
            .Where(n => n["Location_Code"].Value<string>() == "MH");

Это реализация трансдьюсеров по-шарповски.

Там это не проще, потому что там это не нативно, а реализовано в виде библиотек. Как и в Java

Ну типа всё оно когда-то было реализовано в виде библиотек. Позже что-то стало стандартной библиотекой, что-то стало встроено в язык — какая к черту разница?

Разве возможность в рантайме добавлять в объект любое новое поле или функцию - не прототипность?

Нет, это динамичность. Прототипы — это когда один объект наследует атрибуты другого объекта.

Не в инерции тут дело, а в наличии нормальной и стабильной инфраструктуры вокруг XML, которой нет вокруг JSON или которая гораздо хуже

«Нет, я не старый утёнок — просто, первый инструмент, который я освоил, оказался объективно наилучшим возможным решением».

Ты просто не видишь дальше JS и поэтому делаешь такие громогласные заявления

Ну я ХЗ, ты в мой профиль смотреть пробовал?

Нет, это не комментарий, это нарушение схемы. В итоге у тебя либо десиреализация упадёт, либо валидация ещё до неё, если ты используешь JsonSchema

Вот именно что она не упадет. Потому что нет никакой схемы, внезапно. Никто не пользуется твоими JsonSchema и JsonPath.

В JS это тебе создаст поле __enabled__ вместо enabled, но в статически типизированных ЯП это так не работает

В паскале это прокатывало, в C# это прокатывает. Собственно, как я это делал в паскале:

c := content.Child[0];
valueField := c.Field['contragent_name'];
if Assigned(ValueField) and VarIsStr(ValueField.Value) then
    ...

Если таких чтений много, то их можно обернуть в единственную функцию.

В JSON нет комментариев от слова совсем

А формальное наличие комментариев в XML не дает ничего. Они так же убоги, как «несуществующие» комментарии JSON.

Причём тут вообще ASP.NET, когда я сравнивал с C# ?

А ты собрался бэк писать на голой жаве без шпринга, что ли?

Подскажу - речь вовсе не о бэкэндовском Spring, а о Spring MVC, который к бэкэнду имеет весьма опосредованное отношение

Я не вижу там Sprint MVC — я вижу там Spring, и голосовалю люди на Spring.

Пишет мне человек, который никак не может выкинуть мусор по имени Java

Зачем мне выкидывать то, что хорошо меня кормит?

А, ну так бы и сразу, я ж не спорю. Обычно я не пытаюсь даже с такими спорить, потому что техническая сторона вопроса их обычно волнует только «для галочки».

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

А как слёзно их уборщица и курьеры умоляют уйти от жавы — мне аж тяжело на душе становится просто от воображения этой картины.

Это не ты делаешь что-то не так, а вебмакаки из моего банка никак не осилят актуальные технологии

Ну вот им и рассказывай про недостатки их технологий — ты почему-то проецируешь проблемы конкретных разрабов на всю технологию. У JS есть много проблем, но совсем не тех, на которые ты указываешь.

А ты собрался бэк писать на голой жаве без шпринга, что ли?

Нет конечно. Вот только ASP.NET тобой упомянут совершенно не к месту.

Я не вижу там Sprint MVC — я вижу там Spring, и голосовалю люди на Spring.

Слово Spring там явно используется как общее понятие, а не как конкретная технология и сравнение идёт между фронтэндными технологиями. Но речь шла про бэкэнд и сравнивать Spring нужно не с jQuery и не с Angualar, а хотя бы с node.js

А, ну так бы и сразу, я ж не спорю. Обычно я не пытаюсь даже с такими спорить, потому что техническая сторона вопроса их обычно волнует только «для галочки».

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

А как слёзно их уборщица и курьеры умоляют уйти от жавы — мне аж тяжело на душе становится просто от воображения этой картины.

Вот, настоящий комик. Тебе нужно на стендапах выступать, будешь иметь большой успех.

Ну вот им и рассказывай про недостатки их технологий — ты почему-то проецируешь проблемы конкретных разрабов на всю технологию.

Ты не понял. Я лишь привёл пример уровня компетенции типичных фронтэндовых разрабов.

У JS есть много проблем, но совсем не тех, на которые ты указываешь.

То же самое могу сказать и про твоё мнение о Java.

Вы знаете, после очередного раунда любви с отбитым бэком я осознал, зачем нужен JSON. Когда ты отправляешь на сервер данные, сервер пропускает их через некий «шредер» и передает в другие сервисы или возвращает клиенту винегрет (нормальная практика среди PHP программистов), то в таком случае хотя бы есть шанс поднять исходный JSON, чтобы восстановить часть потерянных и искаженных данных. Собственно, XML так же в значительно степени разработан под эту задачу.

inb4: ну тесты же есть, сделай проверку запрос-ответа — тесты проходятся, потому что тесты подо все мелкие комбинации полей задолбишься писать.

Ты про async/await тоже вот прям только сейчас узнал?