Una mirada profunda a JSON frente a XML, parte 1: la historia de cada estándar

Publicado: 2022-03-11
Relacionado: Una mirada profunda a JSON vs. XML, Parte 2: Las fortalezas y debilidades de ambos

Desde el escritorio hasta la web y los dispositivos móviles, casi todas las aplicaciones informáticas que usamos hoy en día se basan en uno de los dos principales estándares de mensajes: JSON y XML. Hoy en día, JSON es el formato más utilizado, pero solo superó a XML en los últimos cinco años. Una búsqueda rápida en línea de "JSON vs. XML" traerá innumerables artículos y publicaciones de blog que comparan los dos estándares, lo que equivale a un sesgo en expansión progresiva que elogia la simplicidad de JSON y critica la verbosidad de XML. Numerosos artículos insisten en que JSON es superior a XML debido a su semántica concisa y descartan XML como un estándar ineficiente y confuso del pasado. A primera vista, JSON parece ser el más popular; entonces, ¿JSON es simplemente mejor que XML? La batalla de "JSON vs. XML" podría ser para JSON en la superficie, pero en profundidad, hay más de lo que parece.

En la Parte 1 de este artículo, vamos a:

  1. Eche un vistazo más de cerca a la historia de la web para descubrir el propósito original de XML y JSON.
  2. Considere la evolución de las tendencias de software en los últimos años para determinar por qué JSON se volvió más popular que XML.

La historia de JSON y XML

Para descubrir el motivo de la popularidad de JSON sobre XML, exploremos la historia de la web y cómo su evolución de la Web 1.0 a la Web 2.0 influyó en las tendencias de desarrollo.

La Web 1.0: HTML

Los primeros años de la década de 1990 fueron los albores de la Web 1.0. HTML se introdujo en 1991 y fue ampliamente adoptado por universidades, empresas y organizaciones gubernamentales como el lenguaje de la web. HTML proviene de SGML, o "Lenguaje de marcado generalizado estándar", inventado en la década de 1970 por IBM. Además de la adopción masiva, HTML experimentó una adaptación masiva: se incrustaron extensiones para admitir multimedia, animación, aplicaciones en línea, comercio electrónico y más. Como derivado de SGML, HTML carecía de una especificación estricta para impedir que las empresas lo expandieran libremente para cumplir requisitos que iban más allá del concepto original. La competencia por el navegador web más popular entre Netscape y Microsoft produjo un rápido progreso, pero también condujo a una fragmentación implacable del estándar. La feroz competencia resultó en una "catástrofe de divergencia" ya que el aumento de HTML por parte de las dos compañías hizo que los navegadores admitieran sus propias versiones únicas de HTML. Esta catástrofe de divergencia se convirtió en un gran problema para las aplicaciones web, ya que los desarrolladores luchaban por escribir código interoperable para los navegadores.

La Web 1.1: XML + HTML = XHTML

A fines de la década de 1990, un grupo de personas, incluidos Jon Bosak, Tim Bray, James Clark y otros, idearon XML: el "lenguaje de marcado extensible". Al igual que SGML, XML no es en sí mismo un lenguaje de marcado, sino una especificación para la definición de lenguajes de marcado. XML fue una evolución de SGML, diseñado para proporcionar un medio para definir y hacer cumplir el contenido estructurado. Considerado como “el santo grial de la computación”, 1 el lenguaje XML buscaba “resolver el problema del intercambio universal de datos entre sistemas diferentes” (Dr. Charles Goldfarb) 2 . En lugar de la fragmentación en curso de HTML, se formó el Comité de la World Wide Web (W3C) para fomentar la compatibilidad y el acuerdo entre la industria en la adopción de nuevos estándares para la World Wide Web. 3 El W3C se dispuso a remodelar HTML como una aplicación XML, y el resultado fue XHTML.

XHTML fue una gran iniciativa que llamó la atención sobre XML, pero es solo una pequeña parte de lo que es XML.

XML proporcionó una forma para que la industria especificara, con una semántica estricta, lenguajes de marcado personalizados para cualquier aplicación. Con la palabra clave "semántica estricta", XML definió un estándar que podría afirmar la integridad de los datos en cualquier documento XML, de cualquier sublenguaje XML. Para las empresas de software que desarrollan aplicaciones empresariales distribuidas que interactúan con sistemas dispares, un lenguaje de marcado que pudiera afirmar la integridad de sus datos era importante. Al definir el contenido estructurado con XML, las empresas aprovecharon las características de esta tecnología para interoperar con cualquier plataforma, reforzar la integridad de los datos en cada intercambio de datos y reducir sistemáticamente el riesgo de software de sus sistemas. Para la industria, XML proporcionó una tecnología para almacenar, comunicar y validar cualquier tipo de datos, en una forma que las aplicaciones en cualquier plataforma puedan leer y procesar fácilmente. Para HTML, XML prometió resolver la "catástrofe de la divergencia".

Java y .NET

A principios de la década de 2000, la web estaba gobernada por dos empresas: Sun y Microsoft. En ese momento, el panorama de los lenguajes de programación estaba muy inclinado hacia el lado del servidor. La arquitectura común para las aplicaciones web se basaba en servidores que procesaban páginas HTML en el back-end para entregarlas al navegador. Este enfoque destacó las tecnologías de back-end, que a su vez popularizaron las principales plataformas de back-end: Java y C#.NET. Desarrollado por Sun Microsystems, Java lideró la nueva generación de lenguajes de programación orientados a objetos que resolvieron el problema de la arquitectura cruzada con su novedoso enfoque de "escribir una vez y ejecutar en cualquier lugar" 4 . Microsoft siguió con .NET, C# y Common Language Runtime (CLR) y fijó sus ojos en XML como el enfoque de elección para resolver el rompecabezas de la interoperabilidad de datos. Microsoft se convirtió en el mayor defensor de XML, y la empresa eligió XML como parte integral de su destacada iniciativa .NET. Anunciadas como “una plataforma para servicios web XML”, 5 las aplicaciones .NET se diseñaron para usar XML para la comunicación con otras plataformas. Seleccionado como el estándar de intercambio de datos de Microsoft, XML se integró en sus principales productos de servidor, como SQL Server y Exchange.

La Web 1.2: AJAX

La entrega de páginas HTML renderizadas previamente al navegador no era escalable y la web necesitaba una alternativa. Con cada acción del usuario que requería que se cargara una página nueva desde el servidor, la carga del proceso y el consumo de ancho de banda se convirtieron en una preocupación a medida que más personas inundaban la web.

Netscape y Microsoft se esforzaron por abordar este problema con la entrega de contenido asíncrono: ActiveX y JavaScript. En 1998, el equipo de Microsoft Outlook Web Access desarrolló el concepto detrás de ActiveX 6 , que luego fue implementado por Mozilla, Safari, Opera y otros navegadores en JavaScript como el objeto XMLHttpRequest .

AJAX nació de ActiveX de Microsoft y JavaScript de Netscape.

El término AJAX, abreviatura de "JavaScript asíncrono y XML", ha llegado a representar una amplia gama de tecnologías web que se pueden usar para implementar aplicaciones web que se comunican con servidores en segundo plano sin necesidad de recargar una página. En el artículo que acuñó el término AJAX, 7 8 Jesse James Garrett esbozó los conceptos principales:

  1. HTML (o XHTML) y CSS para la presentación.
  2. El modelo de objeto de documento (DOM) para la visualización dinámica y la interacción con los datos.
  3. XML para el intercambio de datos y XSLT para su manipulación.
  4. El objeto XMLHttpRequest para la comunicación asíncrona.
  5. JavaScript para unir estas tecnologías.

Con la entrega de contenido asincrónico demostrando reducir la carga del servidor y ahorrar un ancho de banda considerable, AJAX fue un cambio de juego. La introducción de XMLHttpRequest en los navegadores permitió a los desarrolladores implementar una lógica más compleja en el front-end. Google realizó una amplia implementación de AJAX compatible con los estándares y entre navegadores con Gmail en 2004 y Google Maps en 2005.9 Y, en octubre de 2004, la versión beta pública de Kayak.com fue uno de los primeros usos de comercio electrónico a gran escala de AJAX. 10

La Web 2.0: Aplicaciones de una sola página

La adopción de AJAX como arquitectura escalable para aplicaciones web condujo al nacimiento de la Web 2.0: la aplicación de una sola página (SPA). 11 En lugar de volver a cargar la página completa para cada interacción del usuario, los SPA reescriben dinámicamente la página actual dentro del navegador. Además de una reducción considerable en la carga del servidor y el consumo de ancho de banda, el enfoque SPA permitió que las aplicaciones web parecieran aplicaciones de escritorio debido a la experiencia fluida e ininterrumpida durante la interacción del usuario.

En abril de 2002, Stuart Morris escribió uno de los primeros SPA en slashdotslash.com 12 y, más tarde, ese mismo año, Lucas Birdeau, Kevin Hakman, Michael Peachey y Evan Yeh describieron una implementación de aplicación de una sola página en la patente estadounidense 8.136.109. 13 La patente describía navegadores web que usaban JavaScript para mostrar la interfaz de usuario, ejecutar la lógica de la aplicación y comunicarse con un servidor web.

Gmail de Google, Google Maps y la versión beta pública de Kayak iniciaron una nueva era en el desarrollo de aplicaciones web. Los navegadores habilitados con AJAX permitieron a los desarrolladores escribir aplicaciones ricas para la web. La fácil semántica de JavaScript hizo posible el desarrollo de aplicaciones para programadores de cualquier calibre. La barrera de entrada al desarrollo de software se redujo considerablemente y los desarrolladores individuales de todo el mundo comenzaron a contribuir con sus propias bibliotecas y marcos. Las bibliotecas populares como jQuery, que normalizan el comportamiento de AJAX en navegadores de diferentes fabricantes, impulsaron aún más la revolución de AJAX.

El auge de JSON

En abril de 2001, Douglas Crockford y Chip Morningstar enviaron el primer mensaje JSON desde una computadora en el garaje de Morningstar's Bay Area. Crockford y Morningstar intentaban crear aplicaciones AJAX mucho antes de que se acuñara el término "AJAX", pero el soporte del navegador para lo que intentaban lograr no era bueno. Deseaban pasar datos a su aplicación después de que se cargara la página, pero no habían encontrado una manera de permitir que esto funcionara en todos los navegadores.

En 2001, el desarrollo de AJAX recién comenzaba y aún no había una forma interoperable del objeto XMLHttpRequest en Internet Explorer 5 y Netscape 4. Entonces, Crockford y Morningstar usaron un enfoque diferente que funcionó en ambos navegadores.

El primer mensaje JSON se veía así:

 <html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session," do: "test," text: "Hello world" } ) </script></head></html>

Este mensaje es en realidad un documento HTML que contiene algo de JavaScript, y solo una pequeña parte del mensaje se parece a JSON tal como lo conocemos hoy. Crockford y Morningstar pudieron cargar datos de forma asincrónica apuntando un <iframe> a una URL que devolvería un documento HTML como el de arriba. Cuando se recibió la respuesta, se ejecutaría el JavaScript en el HTML y, al eludir las protecciones del navegador que impiden que las subventanas accedan al padre, el objeto literal se devolvió al marco principal de la aplicación. Esta técnica basada en marcos, a veces llamada "técnica de marco oculto", se usaba comúnmente a finales de los 90 antes de la implementación generalizada de XMLHttpRequest . 14

Este enfoque atrajo a los desarrolladores porque ofrecía interoperabilidad en todos los navegadores. Dado que el mensaje es solo JavaScript, no requiere ningún tipo de análisis especial. La idea de usar JavaScript de esta manera era tan sencilla que el propio Crockford dijo que no era la primera persona en hacerlo; afirma que alguien en Netscape estaba usando JavaScript para comunicar información ya en 1996.15

Crockford y Morningstar se dieron cuenta de que tenían algo que podía usarse en todo tipo de aplicaciones. Llamaron a su formato JSON, que es la abreviatura de "Notación de objetos de JavaScript". Comenzaron a proponérselo a los clientes, pero pronto descubrieron que muchos no estaban dispuestos a arriesgarse con una tecnología novedosa que carecía de una especificación oficial. Entonces Crockford decidió que escribiría uno. En 2002, Crockford compró el dominio JSON.org y puso la gramática JSON y una implementación de referencia de un analizador. El sitio web todavía está activo, aunque ahora incluye un enlace destacado al estándar JSON ECMA ratificado en 2013. 16 Después de instalar el sitio web, Crockford hizo poco más para promover JSON, pero pronto encontró personas que enviaban implementaciones de analizadores JSON para diferentes lenguajes de programación. El origen de JSON está claramente ligado a JavaScript, pero se hizo evidente que JSON era adecuado para intercambiar datos entre lenguajes arbitrarios.

JSON en AJAX

En 2005, Jesse James Garrett acuñó el término "AJAX" en una publicación de blog, donde enfatizó que AJAX no era una sola tecnología nueva sino "varias tecnologías, cada una floreciente por derecho propio, uniéndose de formas nuevas y poderosas". 16 La publicación de su blog continuó describiendo cómo los desarrolladores podrían aprovechar JavaScript y XMLHttpRequest para crear nuevos tipos de aplicaciones que fueran más receptivas y con más estado que la típica página web. Señaló a Gmail, Google Maps y Flickr como ejemplos de sitios web que utilizan técnicas AJAX. Aunque "X" en "AJAX" significaba XML, Garrett señaló a JSON como una alternativa completamente aceptable. Escribió que "XML es el medio más desarrollado para obtener datos dentro y fuera de un cliente AJAX, pero no hay ninguna razón por la que no pueda lograr los mismos efectos utilizando una tecnología como la notación de objetos de JavaScript o cualquier medio similar de estructuración de datos". 17

JavaScript y JSON estaban destinados inequívocamente a estar juntos. La semántica de JSON se asigna directamente a JavaScript, lo que lo convierte en el formato de intercambio de datos nativo del lenguaje. Los desarrolladores descubrieron rápidamente que era más fácil trabajar con JSON en JavaScript, y muchos llegaron a preferirlo a XML.

Cuando JSON atrajo la atención de la blogosfera, la proliferación de JSON había comenzado.

Por qué JSON se volvió más popular que XML

JSON es el formato nativo para datos en aplicaciones de JavaScript. Con la popularización de JavaScript en la última década, se han creado más mensajes JSON que cualquier otro formato de datos. Escribir aplicaciones en JavaScript casi exige el uso de JSON para el intercambio de datos. Son posibles otros formatos, pero requieren más esfuerzo que con JSON. Con JavaScript ganando popularidad para el desarrollo de aplicaciones, JSON siguió de cerca su estela como el formato de intercambio de datos integrado de forma nativa y fácil de usar.

En lo que respecta a la blogósfera, se han escrito más artículos, muestras y tutoriales sobre JavaScript (y, por lo tanto, JSON) que sobre cualquier otra plataforma de programación.

La historia y el camino evolutivo de la web han jugado un papel importante en la popularización de JSON. Según Stack Overflow, ahora se hacen más preguntas sobre JSON que sobre otros formatos de intercambio de datos. 18

texto alternativo

Según Google Trends, se ve un perfil similar comparando el interés de búsqueda de JSON y XML. 19

texto alternativo

¿La proliferación de JavaScript significa que JSON es mejor que XML?

Las comunidades de desarrolladores insisten en que JSON se volvió más popular que XML debido a su alcance declarativo conciso y semántica simple. El propio Douglas Crockford resume algunas de las ventajas de JSON en JSON.org: "JSON es más fácil de entender tanto para humanos como para máquinas, ya que su sintaxis es mínima y su estructura es predecible". 20 Otros críticos de XML se han centrado en la verbosidad de XML como el “impuesto del paréntesis angular”. 21 El formato XML requiere que cada etiqueta de apertura coincida con una etiqueta de cierre, lo que da como resultado información redundante que puede hacer que un documento XML sea significativamente más grande que un documento JSON equivalente cuando no está comprimido. Y, quizás lo más importante, los desarrolladores dicen: "también hace que un documento XML sea más difícil de leer". 22

JSON ha sido elogiado fácilmente debido a su simplicidad y semántica concisa, y XML ha sido etiquetado como un estándar anticuado del pasado debido a su verbosidad y complejidad aparentemente excesiva. Muchos artículos y publicaciones de blog ofrecen una perspectiva limitada al comparar JSON con XML, lo que lleva a los lectores a creer que JSON es un reemplazo de XML. ¡Este no es el caso!

La perspectiva limitada que ofrecen los artículos y las publicaciones de blog ha llevado a los lectores a descartar XML como obsoleto, dejando a muchos sin darse cuenta de las potentes funciones que pueden ayudarlos a mejorar la arquitectura de su software y la resiliencia al cambio, así como a reducir sistemáticamente el riesgo del software.

JSON es más popular que XML debido al dominio de JavaScript como el lenguaje más utilizado en la actualidad. Con la influencia de JavaScript en las tendencias de software de la última década, JSON continúa recibiendo cada vez más atención que cualquier otro formato de intercambio de datos. La blogosfera se apresura a repetir que "JSON es mejor que XML", pero la mayoría de las veces, estas declaraciones no se justifican o se respaldan con comparaciones simplistas con respecto a la semántica y la verbosidad. Entonces, ¿cualquier estándar es mejor que el otro? La respuesta a esta pregunta solo puede provenir de una evaluación más profunda de cada estándar.

Conclusión

Desde 1990 hasta hoy, la web ha recorrido un largo camino. Las guerras de navegadores entre Netscape y Microsoft condujeron a una catástrofe de divergencia de HTML, y se necesitaba una solución para salvar la web. XML se inventó para formalizar XHTML y proporcionó una solución del santo grial para la informática en su conjunto. Desde la representación de páginas HTML completas por parte de servidores back-end hasta AJAX y SPA, las tendencias en la arquitectura web y el desarrollo de navegadores se han enfocado en JavaScript, dirigiendo a los desarrolladores de todo el mundo hacia JSON.

La popularidad de JSON se correlaciona con la de JavaScript. Con su facilidad de uso y su corta curva de aprendizaje, JavaScript ha atraído a más desarrolladores nuevos para escribir software que cualquier otro lenguaje. Con la integración nativa de JSON con la plataforma de desarrollo más popular, no sorprende que se hagan más preguntas sobre JSON en Stack Overflow que sobre cualquier otro formato de intercambio de datos.

Con las tendencias de software de los últimos años que han traído más desarrolladores de JavaScript a la industria, JSON se ha ganado el título de "formato de intercambio de datos más popular".

En la superficie, la batalla de "JSON vs. XML" es para JSON, pero en el fondo, hay más de lo que parece.

En la Parte 2 de este artículo, veremos más de cerca las fortalezas y debilidades técnicas de JSON y XML, y evaluaremos la idoneidad de cada estándar para las aplicaciones comunes y la empresa. Una mirada más cercana al "intercambio de datos" revelará la amplitud de su influencia en el riesgo de software de la aplicación en su totalidad. Una comprensión más profunda de las diferencias fundamentales entre JSON y XML permitirá a los desarrolladores evaluar mejor el riesgo de software de cada estándar en relación con los requisitos de su proyecto, para empoderar a los desarrolladores para crear software que sea más estable y más resistente a errores y errores futuros. incógnitas

Por cierto, una peculiaridad interesante de la especificación JSON es que no puede convertir objetos JavaScript con relaciones bidireccionales, donde las propiedades secundarias se refieren a propiedades principales, en JSON. Si lo hace, se produciría un Uncaught TypeError: Converting circular structure to JSON . Para solucionar esta limitación, consulte Compatibilidad con relaciones bidireccionales en JSON .

Referencias

1. Internet: una enciclopedia histórica. Cronología, Volumen 3, pág. 130 (ABC-CLIO, 2005)

2. Manual de Metadatos, Semántica y Ontologías, p. 109 (World Scientific, diciembre de 2013)

3. WebDiy.org - Consorcio World Wide Web (W3C) - Historia

4. "JavaSoft distribuye Java 1.0" (Sun Microsystems, enero de 1996)

5. Habilitación espacial de Internet de próxima generación (David Engen, enero de 2002)

6. La historia de XMLHTTP (AlexHopmann.com, enero de 2007)

7. Beginning Ajax - Página 2 (Wiley Publishing, marzo de 2007)

8. Ajax: un nuevo enfoque para las aplicaciones web (Jesse James Garrett, febrero de 2005)

9. Una breve historia de Ajax (Aaron Swartz, diciembre de 2005)

10. "¿Qué es Kayak.com?" (Antecedentes corporativos, octubre de 2008)

11. Navegación interna: Ampliación del paradigma de navegación de navegación (Netscape, mayo de 2003)

12. "Un sitio web autónomo que utiliza DHTML" (SlashDotSlash.com, julio de 2012)

13. Entrega de datos e información de formato para permitir la manipulación del lado del cliente (Oficina de Patentes de EE. UU., abril de 2002)

14. "¿Qué es Ajax?" Ajax profesional, 2ª ed. (Wiley, marzo de 2007)

15. Douglas Crockford: La saga JSON (Yahoo!, julio de 2009)

16. ECMA Standard 404 (ECMA International, diciembre de 2017)

17. Ajax: un nuevo enfoque para las aplicaciones web (Jesse James Garrett, febrero de 2005)

18. Tendencias de desbordamiento de pila (desbordamiento de pila, 2009-2019)

19. Tendencias de Google (Google, 2004-2019)

20. JSON: la alternativa sin grasa a XML (Crockford, 2006)

21. XML: The Angle Bracket Tax (Coding Horror, mayo de 2008)

22. XML apesta (WikiWikiWeb, 2016)