Почему каждый выбирает JSON Over XML для jQuery?

Я думал, что XML очень портативен и может использоваться как мини-база данных. Я видел XML везде. Я даже вижу, что крупные компании переключаются на JSON. Даже Microsoft интегрировала поддержку JSON. Какова все шумиха над JSON?

ОТВЕТЫ

Ответ 1

В основном потому, что JSON распознается изначально JavaScript, он действительно легкий, минималистичный и переносимый, поскольку он опирается только на две фундаментальные структуры:

  • Коллекция пар имя/значение. На разных языках это реализуется как объект, запись, структура, словарь, хеш-таблица, список клавиш или ассоциативный массив.
  • Упорядоченный список значений. В большинстве языков это реализуется как массив, вектор, список или последовательность.

Ответ 2

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

Ответ 3

Я нахожу, что большое преимущество JSON над XML заключается в том, что мне не нужно решать, как форматировать данные. Как показали некоторые из них, существует множество способов сделать даже простые структуры данных в XML - как элементы, как значения атрибутов и т.д. Затем вам нужно документировать его, написать XML Schema или Relax NG или какую-то другую дерьмо... Это беспорядок.

XML может иметь свои достоинства, но для базового обмена данными JSON намного компактнее и прямо. Как разработчик Python, не существует несоответствия импеданса между простыми типами данных в JSON и Python. Поэтому, если бы я писал обработчик на стороне сервера для запроса AJAX, спрашивающего о снежных условиях для конкретного горнолыжного курорта, я бы создал словарь вроде следующего:

conditions = {
    'new_snow_24': 5.0,
    'new_snow_48': 8.5,
    'base_depth': 88.0,
    'comments': 'Deep and steep!',
    'chains_required': True,
}
return simplejson.dumps(conditions)   # Encode and dump `conditions` as a JSON string

При переходе через JSON (используя библиотеку типа "simplejson" для Python) результирующая структура JSON выглядит почти идентичной (за исключением JSON, булевы имеют нижний регистр).

Декодирование этой структуры требует только анализатора JSON, будь то для Javascript или Objective-C для родного приложения iPhone или С# или клиента Python. Поплавки будут интерпретироваться как float, строки как строки и boolean как логические значения. Используя библиотеку "simplejson" в Python, оператор simplejson.loads(some_json_string) вернет мне полную структуру данных, как я сделал в приведенном выше примере.

Если бы я написал XML, мне пришлось бы решить, нужно ли делать элементы или атрибуты. Оба значения действительны:

<conditions>
    <new-snow-24>5</new-snow-24>
    <new-snow-48>8.5</new-snow-48>
    <chains-required>yes</chains-required>
    <comments>deep and steep!</comments>
</conditions>

<conditions newSnow24="5" newSnow48="8.5" chainsRequired="yes">
   <comments>deep and steep!</comments>
</conditions>

Поэтому я не только должен думать о данных, которые я могу отправить клиенту, я должен подумать о том, как его форматировать. XML, хотя и более простой, чем простой SGML, будучи более строгим с его правилами, по-прежнему предоставляет слишком много способов думать об этих данных. Тогда мне пришлось бы его генерировать. Я не мог просто взять словарь Python (или другую простую структуру данных) и сказать "сделай сам в свой XML". Я не мог получить XML-документ и сразу сказать "сделай сам себя в объектах и ​​структурах данных" без написания настраиваемого анализатора или не требуя дополнительных накладных расходов на XML Schema/Relax NG и других подобных болей.

Короче говоря, это намного проще и гораздо более прямое кодирование и декодирование данных в JSON, особенно для быстрых развязок. Это может относиться больше к людям, поступающим с динамического языкового фона, поскольку базовые типы данных (списки, словари и т.д.), Встроенные в JavaScript/JSON, напрямую сопоставляются с теми же или похожими типами данных в Python, Perl, Ruby и т.д.

Ответ 4

Производительность JSON не сильно отличается от XML для большинства случаев использования, JSON не очень подходит и читаемый для глубоко вложенных структур... вы столкнетесь с]]]}], что затрудняет отладку

Ответ 5

Это легкий по сравнению с XML. Если вам нужно масштабировать, уменьшите требования к пропускной способности!

Сравнить JSON

 [
      {
           color: "red",
           value: "#f00"
      },
      {
           color: "green",
           value: "#0f0"
      },
      {
           color: "blue",
           value: "#00f"
      },
      {
           color: "cyan",
           value: "#0ff"
      },
      {
           color: "magenta",
           value: "#f0f"
      },
      {
           color: "yellow",
           value: "#ff0"
      },
      {
           color: "black",
           value: "#000"
      }
 ]

в XML:

 <colors>
      <color >
           <name>red</name>
           <value>#f00</value>
      </color>
      <color >
           <name>green</name>
           <value>#0f0</value>
      </color>
      <color >
           <name>blue</name>
           <value>#00f</value>
      </color>
      <color >
           <name>cyan</name>
           <value>#0ff</value>
      </color>
      <color >
           <name>magenta</name>
           <value>#f0f</value>
      </color>
      <color >
           <name>yellow</name>
           <value>#ff0</value>
      </color>
      <color >
           <name>black</name>
           <value>#000</value>
      </color>
 </colors>

Ответ 6

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

Я написал небольшой каталог Javascript, сначала с данными в XML, а затем адаптировал его для использования JSON, чтобы я мог запускать их бок о бок и сравнивать скорости с Firebug. JSON оказался примерно в 3 раза быстрее (350-400 мс против 1200-1300 мс для отображения всех данных). Кроме того, как отмечали другие, JSON намного проще на глазах, а размер файла был на 25% меньше из-за более компактной разметки.

Ответ 7

 <colors>
      <color name='red'     value='#f00'/>
      <color name='green'   value='#0f0'/>
      <color name='blue'    value='#00f'/>
      <color name='cyan'    value='#0ff'/>
      <color name='magenta' value='#f0f'/>
      <color name='yellow'  value='#ff0'/>
      <color name='black'   value='#000'/>
 </colors>

С атрибутами XML хорош. Но по какой-то причине самодельный XML, как правило, на 100% состоит из элементов и уродливый.

Ответ 8

Простое потребление JavaScript может быть одной из причин.

Ответ 9

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

Очень хорошим примером является JSON-P. Вы можете вернуть данные из веб-сервиса, завернутого в вызов функции обратного вызова, например my_callback({"color": "blue", "shape":"square"}); внутри динамически генерируемого тега <script>, чтобы данные могли непосредственно потребляться в функции my_callback(). Невозможно приблизиться к этому удобству с помощью XML.

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

Ответ 10

Никто здесь не упомянул основное преимущество XML: правила проверки (DTD, XSD). Мои выводы, используя оба:

  • JSON идеально подходит для ajax, особенно если вы сами разрабатываете серверную и клиентскую стороны. Вы в основном создаете объекты js прямо на своем сервере script!
  • XML сияет в корпоративных средах, когда вам нужно установить стандарты обмена данными между крупными бюрократическими организациями. Часто одна сторона развивает свою часть за несколько месяцев до другой, поэтому ей действительно выгодно проверять свои запросы против согласованного XSD. Кроме того, в крупных корпорациях передача данных часто переводится между различными системами. Это также сила XML, подумайте о XSLT. Пример: преобразование без кода в JSON: p

Конечно, существует json-schema, но вы не найдете встроенной поддержки для нее где угодно.

Я поклонник обоих, у них просто разные силы.

Ответ 11

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

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

Ответ 12

JSON не имеет несоответствия импеданса с программированием JavaScript. JSON может содержать целые числа, строки, списки, массивы. XML - это просто элементы и узлы, которые необходимо проанализировать в виде целых чисел и т.д., Прежде чем они могут быть использованы.

Ответ 13

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

Ответ 14

Оба отличные и очень портативные. Однако JSON набирает популярность, поскольку в большинстве случаев он сериализуется в меньшие символы (что приводит к более быстрому времени доставки), и поскольку он соответствует синтаксису объекта JavaScript, он может быть непосредственно переведен в объект в памяти, который делает Ajax намного проще реализовать.

XML по-прежнему велик. JSON просто "самый последний и самый лучший" по сравнению с XML.

Ответ 15

Легко анализируется JavaScript и является легким (документ в JSON меньше, чем XML-документ, содержащий одни и те же данные.)

Ответ 16

JSON - это фактически сериализованный JavaScript, в котором вы можете eval (aJsonString) непосредственно в объект JavaScript. Внутри браузера он без проблем JSON отлично подходит для JavaScript. В то же время JavaScript является очень слабо типизированным динамическим языком и не может изначально использовать всю информацию определенного типа, содержащуюся в документе Xml/Xsd. Эти дополнительные метаданные (которые отлично подходят для интероперабельности) являются препятствием на JavaScript, что делает его более утомительным и трудным для работы.

Размер и производительность

Если вы находитесь в браузере, JSON быстрее выполняет сериализацию/десериализацию, поскольку он проще, компактнее и, что более важно, поддерживается естественным образом. У меня есть некоторые доступные тесты базы данных Northwind, сравнивающие размер и скорость между различными доступными сериализаторами. В библиотеке базового класса Microsoft XML DataContract сериализатор более 30% быстрее, чем их JSON. Хотя это больше связано с тем, что Microsoft поставила в свой XML-сериализатор, поскольку мне удалось разработать JsonSerializer, который больше, чем 2.6x быстрее, чем их XML. Что касается полезных нагрузок на основе эталонных тестов, похоже, что XML составляет примерно больше 2x размера JSON. Однако это может быстро сдуться, если ваша полезная нагрузка XML использует много разных пространств имен в одном документе.

Ответ 17

XML - это раздутое змеиное масло в большинстве ситуаций. JSON дает вам большую часть преимуществ без раздувания.

Ответ 18

Одно из главных преимуществ, кроме упомянутых здесь. Для одних и тех же данных существует несколько способов представления его как XML файла, но только один способ с JSON, устраняет двусмысленность:)

Ответ 19

Я не эксперт, но из разных компаний, над которыми я работал, мы обычно используем XML в небольших средах данных или значениях конфигурации (отличный пример - web.config).

Когда у вас есть большой объем данных, как правило, вы захотите сообщить об этих данных. И XML не является отличным источником для отчетности. В грандиозной схеме вещей кажется, что транзакционная база данных легче сообщать/искать против XML.

Это имеет смысл? Как я уже сказал выше, я не эксперт, но, по моему опыту, похоже, что так оно и есть. Кроме того, я считаю, что Microsoft интегрировала поддержку JSON из-за того, что волна разработчиков перешла на клиентские или сценарийные действия для улучшения визуализации пользовательского интерфейса (Ajax и Microsoft Ajax не использовались так же, как другие библиотеки, такие как jQuery и MooTools (Yahoo YUI также находится в этом соединении) благодаря их прекрасной интеграции сериализуемых объектов с использованием JSON.

Я нахожу, что написание кода теперь реализует сериализатор JSON в моем коде VB. Это слишком легко и с точки зрения обновления/модификации, вы не можете победить. Это Microsoft способ держать нас зависимыми от VS, я думаю. Недавно я преобразовал корпоративное приложение в использование Ajax (через jQuery) и используя формат JSON. Это заняло около 2 недель. Я действительно благодарю Microsoft за ее интеграцию, потому что без нее мне пришлось бы написать довольно много дополнительного кода.