¿Por qué Todos Eligen JSON Sobre XML para jQuery? [cerrado]

XML realmente no empieza a brillar hasta que empiezas a mezclar diferentes esquemas con espacio 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, liviano, más legible por humanos y generalmente más rápido que XML.

Encuentro que un gran beneficio de JSON sobre XML es que no tengo que decidir cómo formatear los datos. Como algunos han demostrado, hay numerosas formas de hacer incluso estructuras de datos simples en XML -- como elementos,como valores de atributos, etc. Luego tienes que documentarlo, escribir un esquema XML o Relajar NG o alguna otra mierda... Es un desastre.

XML puede tener sus ventajas, pero para el intercambio básico de datos, 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. Así que si estuviera escribiendo un controlador del lado del servidor para una consulta AJAX que preguntara sobre las condiciones de nieve para una estación de esquí en particular, construirí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 JSON resultante se ve casi idéntica (excepto en JSON, los booleanos son de carcasa inferior).

Decodificar esa estructura solo requiere un analizador JSON, ya sea para Javascript o Objective-C para una aplicación nativa para iPhone o C# o un cliente Python. Los flotadores se interpretarían como flotadores, las cuerdas como cuerdas y los booleanos como booleanos. Usando la biblioteca' simplejson ' en Python, una instrucción simplejson.loads(some_json_string) 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. Ambos de los 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>

Así que no solo tengo que pensar en los datos que puedo querer enviar al cliente, tengo que pensar en cómo formatearlo. XML, aunque es más simple que el SGML simple al ser más estricto con sus reglas, todavía proporciona demasiadas maneras de pensar sobre esos datos. Entonces tendría que ir generándolo. No podía simplemente tomar un diccionario Python (u otra estructura de datos simple) y decir "ve a convertirte en mi XML". No podía recibir un documento XML e inmediatamente decir "go make thyself into objects and data structures" sin escribir un analizador personalizado, o sin requiere la sobrecarga adicional de XML Schema / Relax NG y otros problemas similares.

El corto es que es mucho más fácil y mucho más directo codificar y decodificar datos a JSON, especialmente para intercambios rápidos. Esto puede aplicarse más a personas que vienen de un fondo 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 o similares tipos de datos en Python, Perl, Ruby, etc.

El rendimiento de JSON no es muy diferente de 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 lado a lado y comparar velocidades con Firebug. El JSON terminó siendo aproximadamente 3 veces más rápido (350-400 ms vs. 1200-1300 ms para mostrar todos los datos). Además, como otros han señalado, el JSON es mucho más fácil a la vista y el tamaño del archivo era un buen 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 bueno. Pero por alguna razón, XML hecho en casa es generalmente 100% hecho de elementos, y feo.

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

JSON es el mejor para el consumo de datos en aplicaciones web desde servicios web por su tamaño y facilidad de uso, especialmente debido al soporte integrado 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 etiqueta <script> generada dinámicamente para que los datos se puedan consumir directamente en el function my_callback(). No hay manera de acercarse a esta conveniencia usando XML.

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

Aquí nadie ha mencionado la principal ventaja de XML-s: las reglas de validación (DTD, XSD). Mis conclusiones, después de haber utilizado ambos:

• JSON es perfecto para ajax, especialmente si desarrolla el lado del servidor y el cliente usted mismo. Básicamente crea objetos js directamente en su script de servidor!
• XML brilla en entornos corporativos, cuando hay 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 de validar sus peticiones contra XSD acordado. Además, en las grandes corporaciones, la transferencia de datos a menudo se traduce entre diferentes sistemas. Esta es también la fortaleza de XML, piensa en XSLT. Ejemplo: conversión sin código a JSON: p

Por supuesto, se está desarrollando un esquema json, pero no encontrará soporte integrado para él en ningún lugar.

Soy un fanboy de ambos, tienen fortalezas diferentes.

Ahora que hay codificadores y decodificadores JSON para la mayoría de los lenguajes, 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 tanto que sea diferente 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 impedancia-desajuste con la programación JavaScript. JSON puede contener enteros, cadenas, listas, matrices. XML es solo elementos y nodos que necesitan ser analizados en enteros y así sucesivamente antes de que pueda ser consumido.

Ambos son geniales y muy portátiles. Sin embargo, JSON ha ido ganando 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 ya que coincide con la sintaxis del objeto JavaScript, se puede traducir directamente a un objeto en memoria, lo que hace que Ajax sea mucho más fácil de implementar.

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

Fácilmente analizado por 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 que se puede evaluar(aJsonString) directamente en un objeto JavaScript. Dentro de un navegador es una obviedad JSON es perfectamente adecuado para JavaScript. Al mismo tiempo, JavaScript es un lenguaje dinámico de tipo muy impreciso y no puede aprovechar de forma nativa toda la información de tipo específica disponible en un documento Xml/Xsd. Estos metadatos adicionales (que son excelentes para la interoperabilidad) son un obstáculo en JavaScript que lo hace más tedioso y cubersome para trabajar.

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, es compatible de forma nativa. Tengo algunos puntos de referencia de la base de datos northwind disponibles comparando el tamaño y la velocidad entre los diferentes serializadores disponibles. En la Biblioteca de Clases Base, se ha terminado el serializador XML DataContract de Microsoft 30% más rápido que su JSON uno. Aunque esto tiene más que ver con el esfuerzo Microsoft puso en su serializador XML como yo era capaz de desarrollar un JsonSerializer que es más que 2.6 x más rápido que su XML uno. En cuanto a las cargas útiles basadas en los puntos de referencia, parece que XML es más o menos mayor que 2x el tamaño de JSON. Sin embargo, esto puede desaparecer 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 da la mayoría de los beneficios sin la hinchazón.

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

No soy un experto de lejos, pero de las diversas empresas para las que he trabajado generalmente usamos 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 reportar / buscar que XML.

¿esto tiene sentido? Como dije anteriormente, No soy un experto, pero por mi experiencia este parece ser el caso. Además, creo que Microsoft integró el soporte JSON debido a la ola de desarrolladores que se mueven hacia el lado del cliente o acciones con scripts 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 (Yahoo YUI también está en esa mezcla) debido a su hermosa integración de objetos serializables utilizando JSON.

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