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

ок ребята молодцы, все сделали красиво, и коментарии на индусском тоже веслые. Главное не делайте так-же

У protobuf свои плюсы, но иногда вносить его в проект не будет иметь смысл

да и минусы у него есть тоже

Твой пример с большими данными- случай сильно редкий в вебе. Смысл сайту перегонять гигабайты json а? Он не для того предназначен И тот же protobuf нечитаем, тогда как любая жсонка легко парсится, ибо это стандарт

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

У protobuf свои плюсы, но иногда вносить его в проект не будет иметь смысл

его отлаживать нереально, он мало кому очень нужен на самом деле. но смысл хейта не в плюсах и минусах) смысл в том что все что не json - признак мудака по мнению автора

расписание автобусов меняющееся раз в год это просто гиганская работа для сервера

я готов ребятам проставится на хостинг для воркера который будет это делать

расписание автобусов меняющееся раз в год это просто гиганская работа для сервера

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

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

как раз таки стали

его отлаживать нереально, он мало кому очень нужен на самом деле. но смысл хейта не в плюсах и минусах) смысл в том что все что не json - признак мудака по мнению автора

Почему нет? Если есть дефолтный выбор, который ничем не хуже, но они выбирают инструмент не лучше, но хуже на порядок

Мудаки не в плане люди плохие, но как специалисты

его отлаживать нереально, он мало кому очень нужен на самом деле. но смысл хейта не в плюсах и минусах) смысл в том что все что не json - признак мудака по мнению автора

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

Никто суп вилкой не ест, а если ест...

Никто суп вилкой не ест, а если ест...

вот когда Вам в кафе принесут суп с вилкой тогда и поговорим

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

я не поддерживаю авторов в выборе решения, но твой критерий говнокода (все то что не привычно и не нравится лично тебе) я уже уловил

я не поддерживаю авторов в выборе решения, но твой критерий говнокода (все то что не привычно и не нравится лично тебе) я уже уловил

это всего-лишь ваше мнение о моих критериях сделанное из одного единственного случая (csv не люблю не только я)

начни с HTTP

Этот подойдет? https://www.amazon.com/HTTP-Definitive-Guide-Guides/dp/1565925092

Почему нет? Если есть дефолтный выбор, который ничем не хуже, но они выбирают инструмент не лучше, но хуже на порядок

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

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

Экономия на спичках Там за день не так много трафика соберётся

Экономия на спичках Там за день не так много трафика соберётся

json обвязка для данных вполне может увеличивать размер ответа раза в два да, пускай это всё равно останутся спички но эти спички везде: немного насыпят на сервере при генерации ответа, немного добавят увеличением объёма траффика, ещё чуть-чуть сыпанут на клиенте - и вот уже целый коробок :) и ради чего? ладно бы было единообразие ответов всех систем мониторинга общественного транспорта но пока его нет, и для каждого города всё равно надо писать свой парсер в питере, например, отдаётся милый json http://transport.orgp.spb.ru/Portal/transport/map/stage?ROUTE=1087&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&SRS=EPSG%3A900913&BBOX=3372854.4664554,8394442.2729018,3382012.2339402,8398355.84875 и что-то мне подсказывает, что такой формат ответа тоже вряд ли всех устроит

json обвязка для данных вполне может увеличивать размер ответа раза в два да, пускай это всё равно останутся спички но эти спички везде: немного насыпят на сервере при генерации ответа, немного добавят увеличением объёма траффика, ещё чуть-чуть сыпанут на клиенте - и вот уже целый коробок :) и ради чего? ладно бы было единообразие ответов всех систем мониторинга общественного транспорта но пока его нет, и для каждого города всё равно надо писать свой парсер в питере, например, отдаётся милый json http://transport.orgp.spb.ru/Portal/transport/map/stage?ROUTE=1087&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&SRS=EPSG%3A900913&BBOX=3372854.4664554,8394442.2729018,3382012.2339402,8398355.84875 и что-то мне подсказывает, что такой формат ответа тоже вряд ли всех устроит

perfect

json обвязка для данных вполне может увеличивать размер ответа раза в два да, пускай это всё равно останутся спички но эти спички везде: немного насыпят на сервере при генерации ответа, немного добавят увеличением объёма траффика, ещё чуть-чуть сыпанут на клиенте - и вот уже целый коробок :) и ради чего? ладно бы было единообразие ответов всех систем мониторинга общественного транспорта но пока его нет, и для каждого города всё равно надо писать свой парсер в питере, например, отдаётся милый json http://transport.orgp.spb.ru/Portal/transport/map/stage?ROUTE=1087&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&SRS=EPSG%3A900913&BBOX=3372854.4664554,8394442.2729018,3382012.2339402,8398355.84875 и что-то мне подсказывает, что такой формат ответа тоже вряд ли всех устроит

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

json обвязка для данных вполне может увеличивать размер ответа раза в два да, пускай это всё равно останутся спички но эти спички везде: немного насыпят на сервере при генерации ответа, немного добавят увеличением объёма траффика, ещё чуть-чуть сыпанут на клиенте - и вот уже целый коробок :) и ради чего? ладно бы было единообразие ответов всех систем мониторинга общественного транспорта но пока его нет, и для каждого города всё равно надо писать свой парсер в питере, например, отдаётся милый json http://transport.orgp.spb.ru/Portal/transport/map/stage?ROUTE=1087&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&SRS=EPSG%3A900913&BBOX=3372854.4664554,8394442.2729018,3382012.2339402,8398355.84875 и что-то мне подсказывает, что такой формат ответа тоже вряд ли всех устроит

У Яндекс недвижимости отдается XML, к которому есть документация (что в случае с Яндексом делает работу в XML стандартом) То же самое можно сделать и у транспорта И буду удивлен, если этих решений не существует

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

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

кстати, любопытно, но не знаю ни одного сайта куда бы отдавался csv, и это было реально нужно

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

Гугл, Фейсбук, Твиттер Вы их апи сами не видели? И то, что Гугл много где протобаф применяет тоже не слышали?

У Яндекс недвижимости отдается XML, к которому есть документация (что в случае с Яндексом делает работу в XML стандартом) То же самое можно сделать и у транспорта И буду удивлен, если этих решений не существует

каких именно решений? я думаю, в каждом городе своё решение

Гугл, Фейсбук, Твиттер Вы их апи сами не видели? И то, что Гугл много где протобаф применяет тоже не слышали?

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

каких именно решений? я думаю, в каждом городе своё решение

Загуглите Яндекс недвижимость api)

каких именно решений? я думаю, в каждом городе своё решение

В каждом городе свой сервис по продаже? Гоните?)

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

ну двайте слать txt

Загуглите Яндекс недвижимость api)

загуглите трансорт петербурга, транспорт москвы, казани...

Гугл, Фейсбук, Твиттер Вы их апи сами не видели? И то, что Гугл много где протобаф применяет тоже не слышали?

Думаю, Попов об этом и говорит, что не Джсоном единым.

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

Протобаф используется во в внутреннем апи, не видном наружу

загуглите трансорт петербурга, транспорт москвы, казани...

Вы понимаете разницу между движимостью и недвижимостью?

Думаю, Попов об этом и говорит, что не Джсоном единым.

А где я говорил, что только json?

В каждом городе свой сервис по продаже? Гоните?)

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

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

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

Вы уже поискали то, что я вас попросил?

Вы уже поискали то, что я вас попросил?

нет речь же изначально шла о транспорте зачем мне искать недвижимость?

нет речь же изначально шла о транспорте зачем мне искать недвижимость?

Забейте, нет смысла продолжать разговор

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

Он говорит, что json не оптимален Я говорю, что жсон стандарт, а для скорости нужно использовать решения, для этого созданные Он продолжает

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

Если нужно и на спичках экономить, то CSV тут явно не лидер

Все начиналось так: - "смотрите, расписание на сайт приходит в csv" - "а почему это плохо?" мне кажется уже объяснили почему в данном случае плохо раз этак десяток

Если нужно и на спичках экономить, то CSV тут явно не лидер

текстовый формат не может быть лидером, никак

Все начиналось так: - "смотрите, расписание на сайт приходит в csv" - "а почему это плохо?" мне кажется уже объяснили почему в данном случае плохо раз этак десяток

Именно!

текстовый формат не может быть лидером, никак

Именно!

Но он же спорит

А в каком стандарте прописан json как транспорт?

А в каком стандарте прописан json как транспорт?

Json не транспорт

ну формат

Все начиналось так: - "смотрите, расписание на сайт приходит в csv" - "а почему это плохо?" мне кажется уже объяснили почему в данном случае плохо раз этак десяток

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

"JSON - текстовый формат, полностью независимый от языка реализации, но он использует соглашения, знакомые программистам C-подобных языков, таких как C, C++, C#, Java, JavaScript, Perl, Python и многих других. Эти свойства делают JSON идеальным языком обмена данными."

JSON такой же формат передачи данных, как и остальные. JSON так же "удобно" собирать/разбирать в не-Java* языках, как и любой другой (xml, csv, protobuf и вот это вот всё). Для JSника удобней на сервера заюзать JSON - факт.

С тем же успехом можно аргументировать, что кавычка в строке в JSON сломает парсинг.

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

для тех кто в танке: в браузере js, туда надо присылать json бай дефолт. Все отальное - для оптимизаций если есть такая потребность. csv не надо прислыать никогда

ну формат

Загуглить?:)

для тех кто в танке: в браузере js, туда надо присылать json бай дефолт. Все отальное - для оптимизаций если есть такая потребность. csv не надо прислыать никогда

Где это зафиксированно? Аргументацию, пожалуйста.

Где это зафиксированно? Аргументацию, пожалуйста.

ну а головой подумать

Напомните, как называется объект, с помощью которого запрашиваются традиционно данные в браузере

ну а головой подумать

А вот дерзить не надо. Тут не детский сад, когда в случае отсутствия аргументов, можно швырнуть говном.

Где это зафиксированно? Аргументацию, пожалуйста.

это же очевидно, Карл. Браузер тебе предоставляет метод для парсинга json. Смотрите, я и ссылочку вам приготовил https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse

Вы тут джейсон за многословность ругаете, а в том же дотнете стандартом для WCF является SOAP (XML с весьма многословными именами атрибутов и узлов). И вроде ситуация меняться не собирается. ИМХО, всякому инструменту есть своё применение. Безусловно, изначально нет смысла тащить на фронт CSV или протобуфы — но так ровно до тех пор, пока ты действительно не уверен на 100% в необходимости этого. В JS поддерживать джейсоновские апи проще и дешевле — как для бизнеса, так и для разработчиков. В том же дотнете для сервисов (не для общения с фронтом!) я бы брал только XML — это стандарт де-факто, взаимодействие через него отлажено, покрыто тестами и проверено годами использования, пусть он и куда более многословный и тяжелый в сравнении с JSON или чем-то другим. Мне кажется, что вы упускаете момент сложности поддержки апи. Что будет, если из компании уйдет разработчик, который внедрил протобуф для фронта? Сколько месяцев искать ему адекватную замену? Насколько более сложной будет использование вашего апи сторонними консьюмерами? Какую цену они заплатят за внедрение?

для тех кто в танке: в браузере js, туда надо присылать json бай дефолт. Все отальное - для оптимизаций если есть такая потребность. csv не надо прислыать никогда

чисто тебе наподумать. бай дефолт в браузерах для xhr был всегда xml

ERROR: S client not available

чисто тебе наподумать. бай дефолт в браузерах для xhr был всегда xml

в седые времена

(впрочем, я таки соглашусь, что изначальный пример с CSV это боль и грусть, и так делать не стоит)

csv поддержки небыло никогда

Вы тут джейсон за многословность ругаете, а в том же дотнете стандартом для WCF является SOAP (XML с весьма многословными именами атрибутов и узлов). И вроде ситуация меняться не собирается. ИМХО, всякому инструменту есть своё применение. Безусловно, изначально нет смысла тащить на фронт CSV или протобуфы — но так ровно до тех пор, пока ты действительно не уверен на 100% в необходимости этого. В JS поддерживать джейсоновские апи проще и дешевле — как для бизнеса, так и для разработчиков. В том же дотнете для сервисов (не для общения с фронтом!) я бы брал только XML — это стандарт де-факто, взаимодействие через него отлажено, покрыто тестами и проверено годами использования, пусть он и куда более многословный и тяжелый в сравнении с JSON или чем-то другим. Мне кажется, что вы упускаете момент сложности поддержки апи. Что будет, если из компании уйдет разработчик, который внедрил протобуф для фронта? Сколько месяцев искать ему адекватную замену? Насколько более сложной будет использование вашего апи сторонними консьюмерами? Какую цену они заплатят за внедрение?

Вооо А теперь тем, кто оправдывает CSV заменить протобаф на первого в тексте и напомнить, что протобаф эффективнее

Ну ребят Тут не об XML речь идет

Вы тут джейсон за многословность ругаете, а в том же дотнете стандартом для WCF является SOAP (XML с весьма многословными именами атрибутов и узлов). И вроде ситуация меняться не собирается. ИМХО, всякому инструменту есть своё применение. Безусловно, изначально нет смысла тащить на фронт CSV или протобуфы — но так ровно до тех пор, пока ты действительно не уверен на 100% в необходимости этого. В JS поддерживать джейсоновские апи проще и дешевле — как для бизнеса, так и для разработчиков. В том же дотнете для сервисов (не для общения с фронтом!) я бы брал только XML — это стандарт де-факто, взаимодействие через него отлажено, покрыто тестами и проверено годами использования, пусть он и куда более многословный и тяжелый в сравнении с JSON или чем-то другим. Мне кажется, что вы упускаете момент сложности поддержки апи. Что будет, если из компании уйдет разработчик, который внедрил протобуф для фронта? Сколько месяцев искать ему адекватную замену? Насколько более сложной будет использование вашего апи сторонними консьюмерами? Какую цену они заплатят за внедрение?

Спасибо за аргументированную позицию. Соглашусь с тем, что для любого инструмента - своё применение и свой применитель )

(самое задавное кстати что спор возник в группе по ноде, которым json близок как брат родной. вроде-бы)

На самом деле, поделюсь болью, потому что вопрос нестандартного для JS формата в апи это одна из проблем, которую мне придется скоро решать. Мы пишем систему заказа для аптек, и одними из консьюмеров нашего публичного апи является 1С. Джейсон он умеет понимать только с версии 8.3, а до этого — максимум это как раз-таки приснопамятный SOAP. Учитывая «удобство» работы с XML из JS, я пока что стараюсь всеми силами оттянуть момент реализации нашего API на SOAP — это займет просто до чертиков много времени, а команда не настолько велика, чтобы выделить отдельного человека для поддержки двух вариантов — и JSON, и SOAP.

(самое задавное кстати что спор возник в группе по ноде, которым json близок как брат родной. вроде-бы)

самое забавное что спор возник из-за того что ты слишком вольно именуешь говном все что тебе непривычно или кажется плохим

самое забавное что спор возник из-за того что ты слишком вольно именуешь говном все что тебе непривычно или кажется плохим

мне кажется вы переходите на личности, и повторяетесь. Пора уже потушить что там у вас пылает )

мне кажется вы переходите на личности, и повторяетесь. Пора уже потушить что там у вас пылает )

Всегда бы так на личности переходили

мне кажется вы переходите на личности, и повторяетесь. Пора уже потушить что там у вас пылает )

конечно, ведь это ты сказал что они мудаки. а не кто-то.

конечно, ведь это ты сказал что они мудаки. а не кто-то.

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

дальнешие выяснения отношений, если уж на то пошло, предлагаю перенести в лс

Привет всем, я тут на днях только node начал ковырять. Такой вопрос как деплоят приложения нодовские? Так и запускают через node <script> или вот например как в других язаках типо cgi юзают? Но потоковые сервера тут не решают, так что вопрос такой.

Ну для JSON и правда есть RFC, но это не STD, а значит и стандартом не является как таковым :)

Вот пруфы людям, которым захотят называть его стандартом: https://www.rfc-editor.org/standards

"Internet Standard" - стандарт, остальное - нет

то что его может парсить браузер стандартными методами не делает его стандартом де-факто?

Браузерное API для парсинга не делает не из какого формата стандарт для веба. Парсить оно может все что угодно

Там выше кажется ответили. Возможно, CSV был выбран потому, что изначально этот АПИ не предназначался для браузера. Возможно, это был формат обмена между каким-то частями каких-то систем.

Браузерное API для парсинга не делает не из какого формата стандарт для веба. Парсить оно может все что угодно

не согласен с вами. Может и уже умеет разные вещи

Мда... Веб - это только браузеры... Так что ли?

да хватит уже маняврировать

нет это не сигнал из петнтагона и не послание инопланетян

это был ответ от сервера для браузера, и работал с ним js

Понятно. Спасибо, что объянили.

Понятно. Спасибо, что объянили.

ничего личного, просто уже много раз об этом говорилось

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

Большое спасибо за ответ. А разве мобильная разработка не идет к React Native?

а часто вы используете в своем коде ООП? прототипы всякие.

ты их даже если явно не используешь, то косвенно всегда, т.к. в JS прототипное наследование и куда ты от него денешься то? а классы 2015+ это синтаксический сахар поверх прототипов же :)

Это синтетический сахар, всё осталось как прежде

химик однако :)