[Мысли вслух] JSON и JavaScript
Хз.
А можешь назвать те языки, в которые сразу встроена сериализация/десериализация?
JavaScript предоставляет for/in, с его помощью легко можно написать сериализацию/десериализацию. А иначе можно много еще придумать, что можно было бы включить в язык, а не в библиотеки.
JavaScript предоставляет for/in, с его помощью легко можно написать сериализацию/десериализацию. А иначе можно много еще придумать, что можно было бы включить в язык, а не в библиотеки.
Не катит. JavaScript отлично сериализует свои внутренние объекты в строку. Но строка почему-то не JSON формата.
Спрашивается, почему?может потому что JavaScript (ECMAScript) появился раньше JSON?
можешь назвать те языки, в которые сразу встроена сериализация/десериализация?В .net сразу встроено аж три типа сериализации сразу, каждый удобен в своей области.
Мб-мб.
Я как-то проглядел что стандарт с 99 года на javascript висит
А вот года спецификации JSON что-то не знаю.
Я как-то проглядел что стандарт с 99 года на javascript висит
А вот года спецификации JSON что-то не знаю.
Да эт ясно. Тот же питон идет с модулем для (де)сериализации сразу. Но мы говорим про язык без богатой стандартной библиотеки. И уж тем более сравнивать JavaScript с .Net платформой...
Мб-мб.да точно, причём разница по времени появления драматическая - лет 5 как минимум.
А вот года спецификации JSON что-то не знаю.2006
> 2006
Да ладно?
Да ладно?
Гы
Если прочитать комментарии в скрипте по ссылке:
Если прочитать комментарии в скрипте по ссылке:
It is expected that these methods will formally become part of the
JavaScript Programming Language in the Fourth Edition of the
ECMAScript standard in 2007.
во-первых, сериализация предусмотрена в библиотеке
во-вторых, её нет в Compact Framework'е
во-вторых, её нет в Compact Framework'е
во-первых, сериализация предусмотрена в библиотекеэто что-то меняет? язык и библиотека в случае .net/c# неразрывны.
во-вторых, её нет в Compact Framework'енет двух из трех сериализаций, но есть третья — xml serialization. В целом, пофиг, т.к. можно считать, что сверху имелся ввиду нормальный .net
Да ладно?http://www.ietf.org/rfc/rfc4627.txt?number=4627 - я это имел ввиду. Датировано July 2006
Хех
Пользуйся wddx - типо универсальный сериализатор/десериализатор для кучи языков сразу...
JSON значительно более пригоден для AJAX: он легковеснее, чем WDDX, и с ним куда проще работать из JavaScript.
плюсык
давайте еще все подряд писать на XML нах!
ЗЫ Кстати, где-то было забавное сравнение XML и JSON по лаконичности. Внушало.
давайте еще все подряд писать на XML нах!
ЗЫ Кстати, где-то было забавное сравнение XML и JSON по лаконичности. Внушало.
давайте еще все подряд писать на XML нах!Давайте, не будет проблемы совместимости.
сравнение XML и JSON по лаконичностиА тебе-то какая разница, как оно там внутри устроено?
>Давайте, не будет проблемы совместимости.
Парсеры есть. Стандарт определен. Спецы - все множество js прогеров. В чем проблема, а?
>А тебе-то какая разница, как оно там внутри устроено?
Траффик. Cкорость работы парсера.
Парсеры есть. Стандарт определен. Спецы - все множество js прогеров. В чем проблема, а?
>А тебе-то какая разница, как оно там внутри устроено?
Траффик. Cкорость работы парсера.
Парсеры есть. Стандарт определен. Спецы - все множество js прогеров. В чем проблема, а?В том, что делать, если понадобится обмениватьсяданными с программой на каком-нибудь лиспе.
ТраффикНа каждый траффик найдётся свой компрессор.
Cкорость работы парсера.Парсер где запускается? Если на клиенте - вообще непонятно, в чём проблема, он работает доли секунды для не слишком объёмных данных (а для слишком объёмных - там уже, какой бы ты сериализатор не использовал, на закачку всего этого больше времени уйдёт). Если на сервере - тогда, чтобы говорить такие громкие слова, дай тесты, насколько одно работает быстрее другого.
В том, что делать, если понадобится обмениватьсяданными с программой на каком-нибудь лиспе.1, 2...
На каждый траффик найдётся свой компрессор.Хочешь сказать, что сжатый XML будет меньше сжатого JSON? =)
Парсер где запускается? Если на клиенте - вообще непонятно, в чём проблема, он работает доли секунды для не слишком объёмных данных (а для слишком объёмных - там уже, какой бы ты сериализатор не использовал, на закачку всего этого больше времени уйдёт).А если данные объемные, но не слишком?
А JSON парсить на JS вообще не надо.
Имхо, XML лучше JSON в AJAX только в одном случае - когда XML является XHTML'ем, который будет сразу после получения вставлен внутрь какого-то элемента (+ есть ещё вырожденные случаи, вроде Backbase). В остальных случаях JSON рулит.
1, 2...Ладно, не на лиспе.
Этот твой json есть для большего количества языков, чем wddx?
Реализовать его самому для нового языка - легче, чем wddx (если для языка уже есть xml-парсер)?
Хочешь сказать, что сжатый XML будет меньше сжатого JSON? =)Хочу сказать, что у меня такое ощущение, что для правильных компрессоров объём результата будет практически не зависеть от способа сериализации.
А что в этом такого?
А если данные объемные, но не слишком?То что?
А JSON парсить на JS вообще не надо.Его парсят за тебя телепаты?
Ладно, не на лиспе.Для используемых языков он есть. Неиспользуемые языки мы не рассматриваем.
Этот твой json есть для большего количества языков, чем wddx?
Реализовать его самому для нового языка - легче, чем wddx (если для языка уже есть xml-парсер)?
Хочу сказать, что у меня такое ощущение, что для правильных компрессоров объём результата будет практически не зависеть от способа сериализации.Не буду спорить, возможно, ты прав.
А что в этом такого?
То что?То они будут кушать мало трафика в JSON и много в XML (без компрессии).
Его парсят за тебя телепаты?Примерно так. JS-интерпретатор браузера.
Кстати, мне бы значительно больше понравилась задача написания парсера JSON, чем задача написания очередного SAX/DOM/pull XML-парсера.
Но это мои тараканы.
Но это мои тараканы.
Парсер где запускается? Если на клиенте - вообще непонятно, в чём проблема, он работает доли секунды для не слишком объёмных данных (а для слишком объёмных - там уже, какой бы ты сериализатор не использовал, на закачку всего этого больше времени уйдёт). Если на сервере - тогда, чтобы говорить такие громкие слова, дай тесты, насколько одно работает быстрее другого.
>holy dude on
Милейший друг мой! Я молвил громко, чтоб Вы услышали мой слабый глас и вняли бы ему!
Не будем, право, спорить о серверах ничтожных, так и быть (и так и будет! хотя избыточность (и следствие ему - все та же скорость обработки) XML не видна лишь слепцам, глаза которых бельмом обширным наделены!
Но распарсь мне, друже, XML и JSON (который, о чудо, не надо даже парсит!) на js и убедись в неверности своих суждений в треде данном хотя бы для js...
>holy dude off
ЗЫ И мы еще даже не начали спор о human readable. Может, поспорим?
gmail вроде JSON использует, верно? не знаю, для кого как, а для меня это самый серьёзный аргумент 
Что-то я не понял, тут, похоже, два основных аргумента:
1) Избыточность XML. Непонятно, чем она мешает, если сжать, никакой избыточности не будет.
2) То, что этот ваш JSON не надо парсить (точнее, "его парсит браузер" а wddx - надо. Какая коечному пользователю (т.е. программисту) разница, встроены средства парсинга сериализованных данных в браузер (кстати, для json, насколько я понял по первым постам этого треда, это не так или их надо подключать руками?
Насколько я понимаю устройство всего этого, wddx можно одним движением руки (точнее, написанием нужного xslt) превратить (точнее, не превратить, а представить в виде) в json. Значит, wddx как минимум не менее понятен человеку, чем этот ваш json.
1) Избыточность XML. Непонятно, чем она мешает, если сжать, никакой избыточности не будет.
2) То, что этот ваш JSON не надо парсить (точнее, "его парсит браузер" а wddx - надо. Какая коечному пользователю (т.е. программисту) разница, встроены средства парсинга сериализованных данных в браузер (кстати, для json, насколько я понял по первым постам этого треда, это не так или их надо подключать руками?
ЗЫ И мы еще даже не начали спор о human readable. Может, поспорим?Ну давай.
Насколько я понимаю устройство всего этого, wddx можно одним движением руки (точнее, написанием нужного xslt) превратить (точнее, не превратить, а представить в виде) в json. Значит, wddx как минимум не менее понятен человеку, чем этот ваш json.
Ну все, я понял, что мы с тобой, друг, с разных планет.
Заканчиваем этот бред.
Заканчиваем этот бред.
В общем, если тебе нравится пользоваться средством, к которому нужно с каждой стороны приделать по костылю (сжатие, парсинг, xslt чтобы с ним можно было нормально работать — на здоровье.
А теперь о насущном.
Мой браузер поддерживает два типа сжатия - gzip и deflate. Приведи мне JSON и соответствующий ему XML, который после сжатия gzip'ом или deflate'ом будет занимать хотя бы столько же, сколько JSON после сжатия. Я только что сделал около 10 попыток, самое лучшее, что у меня получилось — XML в 1.4 раза больше, чем JSON. Худшее — в 3.8 раз.
А теперь о насущном.
Мой браузер поддерживает два типа сжатия - gzip и deflate. Приведи мне JSON и соответствующий ему XML, который после сжатия gzip'ом или deflate'ом будет занимать хотя бы столько же, сколько JSON после сжатия. Я только что сделал около 10 попыток, самое лучшее, что у меня получилось — XML в 1.4 раза больше, чем JSON. Худшее — в 3.8 раз.
с каждой стороны приделать по костылю (сжатие, парсинг, xslt1) Если ты говоришь про то, какое сжатие поддерживается самим браузером, а не джаваскриптом - то сжатие костылем уже как-то сложно назвать, всё прозрачно и для пользователя и для программиста.
2) Парсинг - не костыль, парсинг для получения данных из какой-то строки нужен всегда. Отличие лишь в том, встроен парсинг этой строки в сам язык, или не встроен. В большинстве случаев (например, wddx и, судя по этому треду, json) - не встроен.
3) xslt - это если ты хочешь представить данные в каком-то другом виде. И вот тут я могу как раз сказать про json - потому что из xml (wddx) ты с помощью xslt можешь получить всё, что угодно. А вот к json - да, уже придётся приделывать костыли.
Я только что сделал около 10 попыток, самое лучшее, что у меня получилось — XML в 1.4 раза больше, чем JSON. Худшее — в 3.8 раз.А конкретные размеры?
При малом объёме данных - вполне возможно, что и в десять раз будет объём отличаться, но при малых объёмах размер не настолько критичен будет (какая разница, десять там байт или сто, если один пакет - килобайт).
При большом - думаю, wddx будет где-нибудь в 1.001 раз тяжелее этого твоего json. А может, меньше. У меня просто никаких json нет, чтобы это проверить.
А вообще, этот спор очень похож на спор о том, как писать числа в высокоуровневых языках и как ими обмениваться между приложениями. Можно представлять число как последовательность цифр, получить при этом полную совместимость и ту самую human-readable; а можно представлять число как последовательность бит в твоём личном формате, здесь и сейчас оно окажется на один процент быстрее и на один процент экономнее, а потом ты потратишь год, когда надо будет работать с другой архитектурой или большими числами или просто обмениваться данными с чужими программами.
1) Если ты говоришь про то, какое сжатие поддерживается самим браузером, а не джаваскриптом - то сжатие костылем уже как-то сложно назвать, всё прозрачно и для пользователя и для программиста.Прозрачно или непрозрачно, а это костыль. Сжатие, между прочим, ещё и какое-то время выполняется, хотя и довольно малое обычно, и осуществляет дополнительную нагрузку на процессор. Тем не менее, совершенно непонятно, зачем это время тратить, если можно не тратить.
2) Парсинг - не костыль, парсинг для получения данных из какой-то строки нужен всегда. Отличие лишь в том, встроен парсинг этой строки в сам язык, или не встроен. В большинстве случаев (например, wddx и, судя по этому треду, json) - не встроен.Конечно, но для JS он встроен в интерпретатор, и тебе вообще не надо знать, что есть какой-то парсинг. В случае с WDDX тебе придется что-то делать ручками (ещё и на JS, что медленно и я опять не понимаю, зачем что-то делать ручками, если можно этого не делать. Только для того, чтобы торжественно заявить "Я мегакрут, потому что использую XML!"?
3) xslt - это если ты хочешь представить данные в каком-то другом виде. И вот тут я могу как раз сказать про json - потому что из xml (wddx) ты с помощью xslt можешь получить всё, что угодно. А вот к json - да, уже придётся приделывать костыли.Спорим на бабло, что я быстрее напишу преобразователь JSON в WDDX на языке JavaScript, чем ты - преобразователь WDDX в JSON на языке XSLT?
Конкретные размеры. Проверял на данных от 2 до 200 кб JSON (ему соответствовал примеро в 5-8 раз больший XML).
потом ты потратишь год, когда надо будет работать с другой архитектурой или большими числами или просто обмениваться данными с чужими программами.Как уже писали в этом треде, такой проблемы с JSON нет. Читай чужие посты хотя бы через раз.
И ещё у тебя кривая аналогия, потому что human readable именно JSON, а не XML. Аналогию нужно проводить так: два формата, один human readable и экономный (JSON другой толстый и нечитабельный (XML).
Кстати, найди мне, пожалуйста, реализацию WDDX для Ruby.
оно?
Да и самому написать не проблема, если есть xml-парсер (а он есть почти везде).
Да и самому написать не проблема, если есть xml-парсер (а он есть почти везде).
самому написать не проблема,json же уже везде есть. Кроме того, что это уже хорошо само по себе, также это является признаком того, как легко реализовать поддержку json.
по ссылке: This Project Has Not Released Any Files
Сжатие, между прочим, ещё и какое-то время выполняется, хотя и довольно малое обычно, и осуществляет дополнительную нагрузку на процессорА конкретные числа у тебя есть? Что работа со сжатым wddx будет тратить времени в десять раз больше на клиенте и в полтора раза больше на сервере, чем работа с несжатым json (а ты ведь его сжимать не будешь, чтобы "костылями" не пользоваться - так что и объём json будет больше; или, если ты json тоже сжимаешь - то закроем тему сжатия).
Конечно, но для JS он встроен в интерпретатор, и тебе вообще не надо знать, что есть какой-то парсинг. В случае с WDDX тебе придется что-то делать ручками (ещё и на JS, что медленно и я опять не понимаю, зачем что-то делать ручками, если можно этого не делать. Только для того, чтобы торжественно заявить "Я мегакрут, потому что использую XML!"?1) Насколько я в курсе, xml-парсер в javascript встроен. А из xml-дерева получить данные уже достаточно легко, во всяком случае, затраченное время для пользователя будет незаметно.
2)
в JavaScript нет встроенных средств для сериализации/десериализации (есть тут ) из объектов JavaScript в JSON и назад.3) А тебя не смущает, что т.н. насильники тоже пишут что-то типа
#include<stdio>?
#include<math>
#include<someshit>
4) wddx даёт большую совместимость, чем json.
Спорим на бабло, что я быстрее напишу преобразователь JSON в WDDX на языке JavaScript, чем ты - преобразователь WDDX в JSON на языке XSLT?Не спорим.
1) Я не знаю xslt.
2) Мне лень тратить на это своё время.
3) Мы, кажется, говорили о преобразовании wddx в json вообще, на любом языке? Если в этом языке есть xml-парсер, то преобразовать получится быстро; если есть поддержка xslt - очень быстро (заметь, о поддержке wddx я не говорил). А вот чтобы преобразовать json в wddx не на языке javascript (с использованием готового json-парсера а на другом языке, где есть все "стандартные" вещи, типа xml-парсера (или ты думаешь, xml недостаточно распространён? регулярных выражений итп.
Как уже писали в этом треде, такой проблемы с JSON нет. Читай чужие посты хотя бы через раз.Ладно, если тебе не нравится то, что придётся писать <script language="Javascript" src="wddx_deserializer.js"></script>, уменя есть проблема, как пользоваться json в php (довольно распространённый язык, не правда ли?) Тот же wddx там есть встроенный, а вот для json придётся менять php.ini или писать dl("php_json.dll")
Так что тут json и wddx, вроде бы, одинаково плохи.
Но, опять же, реализовать парсинг wddx в языке, где есть xml-парсер, гораздо легче, чем json в языке, где есть регулярные выражения.
И ещё у тебя кривая аналогия, потому что human readable именно JSON, а не XML.XML и WDDX - разные вещи.
Тут лучше сказать так - "json, как подмножество всех строк; и wddx, как подмножество xml".
Так вот, xml (вне зависимости от того, что там внутри имея функции работы с xml, очень легко представить в том виде, который тебе нужен. А вот строку, имея функции работы со строками - гораздо сложнее.
Поэтому, элемент какого-то языка-подмножества xml в принципе не может быть менее human-readable, чем элемент какого-то языка-подмножества всех строк. Хотя бы потому что первое легко превратить во второе, а наоборот - уже гораздо сложнее (если поставить эти языки в равные условия - т.е. если у нас нет готового парсера ни для первого, ни для второго; но есть готовые функции и для работы с xml, и для работы со строками).
Чёрт, не заметил.
А поддержка xml в этом ruby есть?
Да, и ещё:
А поддержка xml в этом ruby есть?
Да, и ещё:
МБ, поддержка wddx пока что ещё никому не понадобилась?
Since its public release in 1995, Ruby has drawn devoted coders worldwide. In 2006, Ruby achieved mass acceptance.
А поддержка xml в этом ruby есть?да, есть. очень удобная.
МБ, поддержка wddx пока что ещё никому не понадобилась?По моим данным, так и есть. Все пользуются json
да, есть. очень удобная.Ну тогда вообще никакой проблемы прикрутить wddx нету.
По моим данным, так и есть. Все пользуются jsonошибся. Пообщался с человеком, который очень плотно работает с ruby. Он рассказал о том, что для ряда приложений более удобно пользоваться ruby-специфичным RJS.
ошибся. Пообщался с человеком, который очень плотно работает с ruby, он рассказал о том, что для ряда приложений более удобно пользовать ruby-специфичным RJS.RJS - это несколько не то. Это генератор JavaScript, управляемый кодом на Ruby.
Типа ты в коде на Ruby пишешь
page.show "myElement"RJS на это генерирует
Element.show("myElement");Ну, и есть какой-то ещё тип дополнительный тип шаблонов - RJS-шаблоны. Но, в общем, это немного другое.Ну тогда вообще никакой проблемы прикрутить wddx нету.Зачем
он решает ту же задачу: передать данные с сервера и обновить страницу на клиенте
если нужно большее, то тут уже, конечно, в дело вступают json и другие
если нужно большее, то тут уже, конечно, в дело вступают json и другие
он решает ту же задачу: передать данные с сервера и обновить страницу на клиентеJSON - формат передачи данных. RJS - набор классов, облегчающих генерацию JavaScript на Ruby. Несколько разные вещи, на мой взгляд.
если нужно большее, то тут уже, конечно в дело вступают json и другие
Можно в рамках RJS сделать сериализацию объектов Ruby в JSON. Как при этом можно говорить, что RJS используется вместо JSON?
Т.к. о существовании RJS узнал час назад, то, разумеется, ошибки в терминологии и понимании у меня будут. На уровне того, что передается клиенту это выглядит вот так (абсолютно нечитаемо, ага):
Element.update("outcome-2", "<div class=\"bMenu\">\n\t\t<a href=\"#\" onclick=\"new Ajax.Request('тут-урл', {asynchronous:true, evalScripts:true}); return false;\"><span>\u0411\u0435\u0433\u0443\u043d\u043e\u043a</span></a>\n\t<strong><span>\u0422\u0430\u0431\u043b\u0438\u0446\u0430</span></strong>\n\t</div>\n<div class=\"pole\">\n\t<div class=\"pole2\">\n\t\t<div class=\"pole3\" id=\"slider-2\">\n\t\t\t<div class=\"close\">\n\t\t\t\t<a href=\"#\" onclick=\"new Ajax.Request('/events/1/bets/1/2.js?close=on', {asynchronous:true, evalScripts:true}); return false;\"><img alt=\"[x]\" src=\"/images/btn-close.gif?1166446206\" /></a>\n\t\t\t\t \n\t\t\t\t2\u20140\n\t\t\t</div>\n\t\t\t<dl class=\"elem\">\n\t\t\t\t<dt><b>$</b> <span class=\"bet_result\">10</span></dt>\n\t\t\t\t<dd>\u0432\u043e\u0437\u043c\u043e\u0436\u043d\u044b\u0439 \u0432\u044b\u0438\u0433\u0440\u044b\u0448</dd>\n\t\t\t</dl>\n\t\t\t<dl class=\"elem\">\n\t\t\t\t<dt><b>$</b> <input class=\"bet_amount\" type=\"text\" value=\"10\" /></dt>\n\t\t\t\t<dd>\u0432\u0430\u0448\u0430 \u0441\u0442\u0430\u0432\u043a\u0430</dd>\n\t\t\t</dl>\n\t\t\t<dl class=\"elem\">\n\t\t\t\t<dt><b>$</b> <input type=\"text\" value=\"10\" /></dt>\n\t\t\t</dl>\n\t\t\t\n\t\t\t\t\t\t<div class=\"tabl\" id=\"slider_view-2\">\n\t\t\t\t<b>bet</b>\n\t\t\t\t<a href=\"3\" class=\"tab1 coeff\">\n\t\t\t\t\t<span>0.3<br />224</span>\n\t\t\t\t</a>\n\t\t\t\t<a href=\"4\" class=\"tab1 coeff\">\n\t\t\t\t\t<span>0.4<br />224</span>\n\t\t\t\t</a>\n\t\t\t\t<a href=\"5\" class=\"tab1 coeff\">\n\t\t\t\t\t<span>0.5<br />224</span>\n\t\t\t\t</a>\n\t\t\t\t<a href=\"6\" class=\"tab2 coeff\">\n\t\t\t\t\t<span>0.6<br />224</span>\n\t\t\t\t</a>\n\t\t\t\t<a href=\"7\" class=\"tab2 coeff\">\n\t\t\t\t\t<span>0.7<br />224</span>\n\t\t\t\t</a>\n\t\t\t\t<a href=\"8\" class=\"tab2 coeff\">\n\t\t\t\t\t<span>0.8<br />224</span>\n\t\t\t\t</a>\n\t\t\t\t<strong>lay</strong>\n\t\t\t</div>\n\t\t\t\t\t</div>\n\t\t\t\t<script type=\"text/javascript\">\n\t\tvar outcome_2 = new BetTable(\"slider-2\");\n\t\t</script>\n\t\t\t</div>\n</div>\n");
var outcome_2 = new BetTable('slider-2');
Оставить комментарий
tipnote
Казалось бы, в одной плоскости. Но в JavaScript нет встроенных средств для сериализации/десериализации (есть тут ) из объектов JavaScript в JSON и назад. Спрашивается, почему?