protobuf, msgpack, без нативной поддержки но от этого они преимуществ не теряют

тот-же YAML например. Но не scv.txt же

это какая-то непонятная агрессия, очевидно, что сделали это не очень прошаренные люди и скорее всего из-за простоты своей, но хейтишь ты их не за некачественное решение а за то что они не похожи на всех

Json стандарт для веба уже так давно, что я искренне удивлен что кто-то еще не в курсе

как раз-таки за некачественное решение

ну что ты, кроме тебя все балбесы, просто тебе по роду деятельности не приходилось сталкиваться с минусами json, и платить баблом за них конечно не приходилось

с удовльствием полушаю о минусах json в контексте веба

У csv есть свои преимущества. Например, его можно считывать и парсить построчно, а значит, передавать в нем очень большие массивы.

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

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

браузеру ресурсозатратно декодировать нативными средствами json чем бог знает каким велосипедом написаным под каждый конкретный случай csv?

так как по исходному коду не спарсить, он пустой только ссылка на JS файл

и много тут таких поклонников csv?

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

и много тут таких поклонников csv?

ой да не смешите, есть такая штука как кэширование

хаха, все понятно)

последний аргумент?

Как только здесь не обозвали Comma Separated Value (CSV)...

ты несешь ахинею, я не знаю что тебе на нее ответить. правда. извини.

тут нет поклонников csv, тут есть поклонники опыта и здравого смысла, а не задорной категоричности недальновидной

Здравый смысл подсказывает, что не нужно оптимизировать без необходимости. Тем более, что вряд ли именно на том сайте будут гонять мегабайтные json'ы.

Немного данных, действительно, лучше передавать в JSON. Банально удобнее. Если данных много, настолько, что парсинг json начинает тормозить, надо думать и оптимизировать. Тут уже есть смысл заморочиться с тем же csv

"поклонник здравого смысла": в том что они сделали "нет смысла"

>Немного данных, действительно, лучше передавать в JSON. Банально удобнее. О чём и речь. Так-то можно 100500 дополнительных условий привести, но мы же рассматриваем конкретный случай.

>Немного данных, действительно, лучше передавать в JSON. Банально удобнее. О чём и речь. Так-то можно 100500 дополнительных условий привести, но мы же рассматриваем конкретный случай.

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

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

Скорость выката изменений влияет Куча инструментов завязана на json, пока они под CSV будут говнокод подгонять, пройдет время Больше, чем при нормальной разработке

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

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

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

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

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

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

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

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

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

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

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

начни с HTTP

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

могу ошибаться, но мне кажется, что основным потребителем расписаний общественного транспорта являются мобильные приложения, типа яндекс.транспорт и аналогов в них существенна разница не только в размере ответа (у клиентов плохой и дорогой мобильный инет), но и в ресурсах, затрачиваемых на парсинг ответа (меньше греется, дольше живёт) вполне вероятно, что в данном примере на сервере выбрали 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 и что-то мне подсказывает, что такой формат ответа тоже вряд ли всех устроит

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 делает код производительнее?

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

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

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

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

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

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

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