¿Por qué todos eligen JSON sobre XML para jQuery? [cerrado]

Pensé que XML es altamente portátil y se puede usar como una mini base de datos. He visto XML usado en todas partes. Incluso veo grandes empresas que cambian a JSON . Incluso Microsoft tiene soporte integrado para JSON. ¿Qué es todo el bombo sobre JSON?

Básicamente, debido a que JSON es reconocido de forma nativa por JavaScript, es realmente liviano, minimalista y altamente portátil porque se basa solo en dos estructuras fundamentales:

• Una colección de pares de nombre / valor. En varios idiomas, esto se realiza como un objeto, registro, estructura, diccionario, tabla hash, lista con clave o matriz asociativa.
• Una lista ordenada de valores. En la mayoría de los idiomas, esto se realiza como una matriz, vector, lista o secuencia.

XML realmente no comienza a brillar hasta que comienzas a mezclar diferentes esquemas de espacios de nombres. Luego verá que JSON comienza a caerse, pero si solo necesita un formato de serialización para sus datos, JSON es más pequeño, más liviano, más legible para los humanos y, en general, más rápido que XML.

Creo que una gran ventaja de JSON sobre XML es que no tengo que decidir cómo formatear los datos. Como algunos han demostrado, existen numerosas formas de hacer incluso estructuras de datos simples en XML: como elementos, como valores de atributos, etc. Luego debe documentarlo, escribir un esquema XML o Relax NG o alguna otra basura ... Es un desastre.

XML puede tener sus ventajas, pero para el intercambio de datos básicos, JSON es mucho más compacto y directo. Como desarrollador de Python, no hay desajuste de impedancia entre los tipos de datos simples en JSON y en Python. Entonces, si estaba escribiendo un controlador del lado del servidor para una consulta AJAX que preguntaba sobre las condiciones de nieve para una estación de esquí en particular, crearía un diccionario como el siguiente:

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

Cuando se traduce a través de JSON (usando una biblioteca como 'simplejson' para Python), la estructura de JSON resultante se ve casi idéntica (excepto en JSON, los booleanos están en minúsculas).

Decodificar esa estructura solo requiere un analizador JSON, ya sea para Javascript o Objective-C para una aplicación nativa de iPhone o C # o un cliente Python. Las carrozas se interpretarían como carrozas, las cuerdas como cuerdas y los booleanos como booleanos. Usando la biblioteca 'simplejson' en Python, unsimplejson.loads(some_json_string) declaración me devolvería una estructura de datos completa como acabo de hacer en el ejemplo anterior.

Si escribiera XML, tendría que decidir si hacer elementos o atributos. Los dos siguientes son válidos:

<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>

Entonces, no solo tengo que pensar en los datos que quiero enviar al cliente, también tengo que pensar en cómo formatearlos. XML, si bien es más simple que SGML simple al ser más estricto con sus reglas, aún proporciona demasiadas formas de pensar en esos datos. Entonces tendría que empezar a generarlo. No podría simplemente tomar un diccionario de Python (u otra estructura de datos simple) y decir "ve a convertirte en mi XML". No pude recibir un documento XML e inmediatamente dije "ve a convertirte en objetos y estructuras de datos" sin escribir un analizador personalizado, o sin requerir la sobrecarga adicional de XML Schema / Relax NG y otros dolores similares.

En resumen, es mucho más fácil y directo codificar y decodificar datos en JSON, especialmente para intercambios rápidos. Esto puede aplicarse más a las personas que provienen de un entorno de lenguaje dinámico, ya que los tipos de datos básicos (listas, diccionarios, etc.) integrados en JavaScript / JSON se asignan directamente a los mismos tipos de datos o similares en Python, Perl, Ruby, etc.

El rendimiento de JSON no es muy diferente del XML para la mayoría de los casos de uso, JSON no es muy adecuado y legible para estructuras de nido profundo ... se encontrará con]]]}], lo que dificulta la depuración

Es ligero en comparación con XML. Si necesita escalar, reduzca sus requisitos de ancho de banda.

Comparar 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"
      }
 ]

a 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>

Solo una anécdota de mi propia experiencia personal:

Escribí un pequeño directorio Javascript, primero con los datos en XML, y luego lo adapté para usar JSON para poder ejecutarlos uno al lado del otro y comparar velocidades con Firebug. El JSON terminó siendo aproximadamente 3 veces más rápido (350-400 ms frente a 1200-1300 ms para mostrar todos los datos). Además, como otros han notado, el JSON es mucho más fácil a la vista y el tamaño del archivo era un 25% más pequeño debido al marcado más delgado.

 <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>

Con atributos, XML es agradable. Pero por alguna razón, el XML hecho en casa generalmente está hecho al 100% de elementos y es feo.

El fácil consumo por JavaScript puede ser una de las razones.

JSON es mejor para el consumo de datos en aplicaciones web de servicios web por su tamaño y facilidad de uso, especialmente debido al soporte incorporado en JavaScript . Imagine la sobrecarga de cálculo para analizar un fragmento xml en comparación con la búsqueda instantánea en JSON.

Un muy buen ejemplo es JSON-P. Puede recuperar datos de un servicio web envuelto en una llamada de función de devolución de llamada, como my_callback({"color": "blue", "shape":"square"});dentro de una <script>etiqueta generada dinámicamente para que los datos se puedan consumir directamente en la función my_callback(). No hay forma de acercarse a esta conveniencia utilizando XML.

XML sería el formato de elección para documentos grandes, donde tiene un marco de representación de páginas de datos en múltiples formatos usando XSLT. XML también se puede usar con archivos de configuración de aplicaciones para facilitar la lectura entre muchos otros usos.

Nadie aquí ha mencionado la principal ventaja de XML-s: reglas de validación (DTD, XSD). Mis conclusiones, habiendo usado ambos:

• JSON es perfecto para ajax, especialmente si desarrolla usted mismo tanto el servidor como el cliente. ¡Básicamente creas objetos js directamente en el script de tu servidor!
• XML brilla en entornos corporativos, cuando tiene que establecer estándares de intercambio de datos entre grandes organizaciones burocráticas. A menudo, una parte desarrolla su parte meses antes que otra, por lo que realmente se beneficia al validar sus solicitudes contra XSD acordado. Además, en las grandes corporaciones, la transferencia de datos a menudo se traduce entre diferentes sistemas. Esta también es la fuerza de XML, piense en XSLT. Ejemplo: conversión sin código a JSON: p

Por supuesto, se está desarrollando el esquema json, pero no encontrará soporte incorporado para él en ningún lado.

Soy fanboy de ambos, tienen puntos fuertes diferentes.

Ahora que hay codificadores y decodificadores JSON para la mayoría de los idiomas, no hay razón para NO usar JSON para usos donde tiene sentido (y eso es probablemente el 90% de los casos de uso para XML).

Incluso he oído hablar de cadenas JSON que se utilizan en grandes bases de datos SQL para facilitar los cambios de esquema.

Honestamente, no hay muchas diferencias entre JSON y XML en el hecho de que pueden representar todo tipo de datos. Sin embargo, XML es sintácticamente más grande que JSON y eso lo hace más pesado que JSON.

JSON no tiene falta de coincidencia de impedancia con la programación de JavaScript. JSON puede contener enteros, cadenas, listas, matrices. XML son solo elementos y nodos que deben analizarse en enteros y así sucesivamente antes de que se pueda consumir.

Ambos son geniales y muy portátiles. Sin embargo, JSON ha ganado popularidad ya que se serializa en menos caracteres en la mayoría de los casos (lo que se traduce en un tiempo de entrega más rápido) y, dado que coincide con la sintaxis del objeto JavaScript, se puede traducir directamente a un objeto en memoria que hace que Ajax sea mucho más fácil de usar. implementar.

XML sigue siendo genial. JSON es solo el "último y mejor" en comparación con XML.

Se analiza fácilmente con JavaScript y es ligero (un documento en JSON es más pequeño que un documento XML que contiene los mismos datos).

JSON es efectivamente JavaScript serializado en el que puede evaluar (aJsonString) directamente en un objeto JavaScript. Dentro de un navegador es un JSON obvio que es perfectamente adecuado para JavaScript. Al mismo tiempo, JavaScript es un lenguaje dinámico muy poco tipado y no puede aprovechar de forma nativa toda la información de tipo específica disponible contenida en un documento Xml / Xsd. Estos metadatos adicionales (que son excelentes para la interoperabilidad) son un obstáculo en JavaScript, por lo que es más tedioso y complejo trabajar con ellos.

Tamaño vs rendimiento

Si está en un navegador, JSON es más rápido de serializar / deserializar, ya que es más simple, más compacto y, lo que es más importante, compatible de forma nativa. Tengo algunos puntos de referencia de la base de datos de Northwind disponibles que comparan el tamaño y la velocidad entre los diferentes serializadores disponibles. En la Base Class Library, el serializador XML DataContract de Microsoft es un 30% más rápido que su JSON. Aunque esto tiene más que ver con el esfuerzo que Microsoft puso en su serializador XML, ya que pude desarrollar un JsonSerializer que es más de 2.6 veces más rápido que su XML. En cuanto a las cargas útiles basadas en los puntos de referencia, parece que XML es aproximadamente más de 2El tamaño de JSON. Sin embargo, esto puede explotar rápidamente si su carga XML utiliza muchos espacios de nombres diferentes dentro del mismo documento.

XML es aceite de serpiente hinchado en la mayoría de las situaciones. JSON le brinda la mayoría de los beneficios sin la hinchazón.

Una gran ventaja aparte de las mencionadas aquí. Para los mismos datos, hay varias formas de representarlo como un archivo XML, pero solo una forma con JSON elimina la ambigüedad :)

No soy un experto con diferencia, pero de las diversas compañías para las que he trabajado generalmente utilizamos XML en entornos de datos pequeños o valores de configuración (web.config es un gran ejemplo).

Cuando tiene grandes cantidades de datos, generalmente, querrá informar sobre esos datos. Y XML no es una gran fuente de informes. En el gran esquema de las cosas, parece que una base de datos transaccional es más fácil de informar / buscar que XML.

¿Esto tiene sentido? Como dije anteriormente, no soy un experto, pero según mi experiencia, este parece ser el caso. Además, creo que Microsoft integró el soporte JSON debido a la ola de desarrolladores que se movieron hacia acciones del lado del cliente o con secuencias de comandos para mejorar las imágenes de la interfaz de usuario ( Ajax ) y Ajax de Microsoft no se ha utilizado tanto como otras bibliotecas como jQuery y MooTools ( YUI de Yahoo también está en esa mezcla) debido a su hermosa integración de objetos serializables usando JSON.

Me encuentro escribiendo código ahora implementando el serializador JSON en mi código VB. Es MUY fácil y desde un punto de vista de actualización / modificación, no se puede superar. Supongo que es la forma en que Microsoft nos mantiene adictos a VS. Recientemente he convertido una aplicación empresarial para usar Ajax (a través de jQuery) y usar el formato JSON. Le llevó aproximadamente 2 semanas hacerlo. De hecho, agradezco a Microsoft por integrarlo porque sin él, habría tenido que escribir bastante código extra.