Um olhar profundo sobre JSON vs. XML, Parte 1: A história de cada padrão

Publicados: 2022-03-11
Relacionado: Um olhar profundo sobre JSON vs. XML, Parte 2: Os pontos fortes e fracos de ambos

Do desktop à web e móvel, quase todos os aplicativos de computador que usamos hoje contam com um dos dois principais padrões de mensagem: JSON e XML. Hoje, o JSON é o formato mais usado, mas só ultrapassou o XML nos últimos cinco anos. Uma rápida busca online por “JSON vs. XML” trará inúmeros artigos e postagens de blog comparando os dois padrões, e chegando a um viés de expansão progressiva elogiando a simplicidade do JSON e criticando a verbosidade do XML. Numerosos artigos insistem que o JSON é superior ao XML devido à sua semântica concisa e desconsidera o XML como um padrão ineficiente e confuso do passado. À primeira vista, o JSON parece ser o mais popular, então o JSON é simplesmente melhor que o XML? A batalha de “JSON vs. XML” pode ir para o JSON na superfície, mas em profundidade, há mais do que aparenta.

Na Parte 1 deste artigo, iremos:

  1. Dê uma olhada mais de perto na história da web para descobrir o propósito original de XML e JSON.
  2. Considere a evolução das tendências de software nos últimos anos para verificar por que o JSON se tornou mais popular que o XML.

A história do JSON e XML

Para descobrir o motivo da popularidade do JSON sobre o XML, vamos explorar a história da Web e como sua evolução da Web 1.0 para a Web 2.0 influenciou as tendências de desenvolvimento.

A Web 1.0: HTML

O início dos anos 1990 foi o alvorecer da Web 1.0. HTML foi introduzido em 1991 e foi amplamente adotado por universidades, empresas e organizações governamentais como a linguagem da web. HTML veio de SGML, ou “Standard Generalized Markup Language”, inventado na década de 1970 pela IBM. Além da adoção em massa, o HTML passou por uma adaptação em massa — extensões foram incorporadas para dar suporte a multimídia, animação, aplicativos online, comércio eletrônico e muito mais. Como um derivado do SGML, o HTML carecia de uma especificação estrita para impedir as empresas de expandi-lo livremente para atender a requisitos que estavam além do conceito original. A disputa pelo navegador mais popular entre a Netscape e a Microsoft rendeu um rápido progresso, mas também levou à fragmentação implacável do padrão. A competição acirrada resultou em uma “catástrofe de divergência”, pois o aumento do HTML pelas duas empresas fez com que os navegadores suportassem suas próprias versões exclusivas do HTML. Essa catástrofe de divergência tornou-se um grande problema para aplicativos da Web, pois os desenvolvedores lutavam para escrever código interoperável para os navegadores.

A Web 1.1: XML + HTML = XHTML

No final da década de 1990, um grupo de pessoas – incluindo Jon Bosak, Tim Bray, James Clark e outros – criou o XML: a “eXtensible Markup Language”. Como SGML, XML não é em si uma linguagem de marcação, mas uma especificação para a definição de linguagens de marcação. O XML foi uma evolução do SGML—projetado para fornecer um meio de definir e aplicar conteúdo estruturado. Considerada como “o santo graal da computação”, 1 a linguagem XML buscou “resolver o problema do intercâmbio universal de dados entre sistemas diferentes” (Dr. Charles Goldfarb) 2 . Em vez da fragmentação contínua do HTML, o Comitê da World Wide Web (W3C) foi formado para promover a compatibilidade e o acordo entre a indústria na adoção de novos padrões para a World Wide Web. 3 O W3C começou a remodelar o HTML como um aplicativo XML, com o resultado sendo XHTML.

XHTML foi uma grande iniciativa que chamou a atenção para XML, mas é apenas uma pequena parte do que é XML.

O XML forneceu uma maneira para a indústria especificar, com semântica estrita, linguagens de marcação personalizadas para qualquer aplicativo. Com a palavra-chave sendo “semântica estrita”, o XML definiu um padrão que poderia assegurar a integridade dos dados em qualquer documento XML, de qualquer sublinguagem XML. Para empresas de software que desenvolvem aplicativos corporativos distribuídos que fazem interface com sistemas distintos, uma linguagem de marcação que pudesse assegurar a integridade de seus dados era significativa. Ao definir o conteúdo estruturado com XML, as empresas aproveitaram os recursos dessa tecnologia para interoperar com qualquer plataforma, reforçar a integridade dos dados de cada intercâmbio de dados e reduzir sistematicamente o risco de software de seus sistemas. Para a indústria, o XML forneceu uma tecnologia para armazenar, comunicar e validar qualquer tipo de dados, de uma forma que os aplicativos em qualquer plataforma podem ler e processar facilmente. Para o HTML, o XML prometia resolver a “catástrofe da divergência”.

Java e .NET

No início dos anos 2000, a web era governada por duas empresas: Sun e Microsoft. Na época, o cenário das linguagens de programação estava fortemente inclinado para o lado do servidor. A arquitetura comum para aplicativos da Web dependia de servidores renderizando páginas HTML no back-end para serem entregues ao navegador. Essa abordagem destacou as tecnologias de back-end, que por sua vez popularizaram as principais plataformas de back-end: Java e C#.NET. Desenvolvido pela Sun Microsystems, o Java liderou a nova geração de linguagens de programação orientadas a objetos que resolveram o problema de arquitetura cruzada com sua nova abordagem “gravar uma vez e executar em qualquer lugar” 4 . A Microsoft seguiu com .NET, C# e o Common Language Runtime (CLR) e colocou seus olhos no XML como a abordagem de escolha para resolver o quebra-cabeça da interoperabilidade de dados. A Microsoft se tornou a maior defensora do XML, com a empresa escolhendo o XML como parte integrante de sua proeminente iniciativa .NET. Anunciado como “uma plataforma para serviços web XML”, 5 aplicativos .NET foram arquitetados para usar XML para comunicação com outras plataformas. Selecionado como o padrão de intercâmbio de dados da Microsoft, o XML foi integrado aos seus principais produtos de servidor, como SQL Server e Exchange.

A Web 1.2: AJAX

A entrega de páginas HTML pré-renderizadas para o navegador não era escalável, e a web precisava de uma alternativa. Com cada ação do usuário exigindo que uma nova página fosse carregada do servidor, a carga do processo e o consumo de largura de banda se tornaram uma preocupação à medida que mais pessoas cresciam na web.

A Netscape e a Microsoft se esforçaram para resolver esse problema com entrega de conteúdo assíncrona: ActiveX e JavaScript. Em 1998, a equipe do Microsoft Outlook Web Access desenvolveu o conceito por trás do ActiveX 6 , que mais tarde foi implementado pelo Mozilla, Safari, Opera e outros navegadores em JavaScript como o objeto XMLHttpRequest .

O AJAX nasceu do ActiveX da Microsoft e do JavaScript da Netscape.

O termo AJAX – abreviação de “Asynchronous JavaScript and XML” – passou a representar uma ampla gama de tecnologias da Web que podem ser usadas para implementar aplicativos da Web que se comunicam com servidores em segundo plano sem exigir que uma página seja recarregada. No artigo que cunhou o termo AJAX, 7 8 Jesse James Garrett delineou os principais conceitos:

  1. HTML (ou XHTML) e CSS para apresentação.
  2. O Document Object Model (DOM) para exibição dinâmica e interação com dados.
  3. XML para o intercâmbio de dados e XSLT para sua manipulação.
  4. O objeto XMLHttpRequest para comunicação assíncrona.
  5. JavaScript para reunir essas tecnologias.

Com a entrega de conteúdo assíncrona provando reduzir a carga do servidor e economizar largura de banda considerável, o AJAX foi um divisor de águas. A introdução do XMLHttpRequest nos navegadores permitiu que os desenvolvedores implementassem uma lógica mais complexa no front-end. O Google fez uma ampla implantação de AJAX compatível com os padrões e entre navegadores com o Gmail em 2004 e o Google Maps em 2005. 9 E, em outubro de 2004, a versão beta pública do Kayak.com foi um dos primeiros usos de AJAX em grande escala no comércio eletrônico. 10

A Web 2.0: aplicativos de página única

A adoção do AJAX como arquitetura escalável para aplicativos da Web levou ao surgimento da Web 2.0: o aplicativo de página única (SPA). 11 Em vez de recarregar a página inteira para cada interação do usuário, os SPAs reescrevem dinamicamente a página atual no navegador. Além de uma redução considerável na carga do servidor e no consumo de largura de banda, a abordagem SPA permitiu que os aplicativos da Web se assemelhassem aos aplicativos de desktop devido à experiência contínua e ininterrupta durante a interação do usuário.

Em abril de 2002, Stuart Morris escreveu um dos primeiros SPAs em slashdotslash.com 12 , e mais tarde no mesmo ano, Lucas Birdeau, Kevin Hakman, Michael Peachey e Evan Yeh descreveram uma implementação de aplicação de página única na patente US 8.136.109. 13 A patente descrevia navegadores da Web usando JavaScript para exibir a interface do usuário, executar a lógica do aplicativo e se comunicar com um servidor da Web.

O Gmail do Google, o Google Maps e a versão beta pública do Kayak deram início a uma nova era de desenvolvimento de aplicativos da web. Navegadores habilitados com desenvolvedores habilitados para AJAX para escrever aplicativos avançados para a web. A semântica fácil do JavaScript tornou o desenvolvimento de aplicativos possível para programadores de qualquer calibre. A barreira de entrada no desenvolvimento de software foi bastante reduzida e desenvolvedores individuais em todo o mundo começaram a contribuir com bibliotecas e estruturas próprias. Bibliotecas populares como jQuery, que normalizam o comportamento do AJAX em navegadores de diferentes fabricantes, avançaram ainda mais na revolução do AJAX.

A ascensão do JSON

Em abril de 2001, Douglas Crockford e Chip Morningstar enviaram a primeira mensagem JSON de um computador na garagem da Morningstar Bay Area. Crockford e Morningstar estavam tentando construir aplicativos AJAX bem antes do termo “AJAX” ser cunhado, mas o suporte do navegador para o que eles estavam tentando alcançar não era bom. Eles desejavam passar dados para seu aplicativo após o carregamento da página, mas não encontraram uma maneira de permitir que isso funcionasse em todos os navegadores.

Em 2001, o desenvolvimento do AJAX estava apenas começando, e ainda não havia uma forma interoperável do objeto XMLHttpRequest no Internet Explorer 5 e Netscape 4. Então Crockford e Morningstar usaram uma abordagem diferente que funcionou em ambos os navegadores.

A primeira mensagem JSON ficou assim:

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

Esta mensagem é na verdade um documento HTML contendo algum JavaScript, e apenas uma pequena parte da mensagem se assemelha ao JSON como o conhecemos hoje. Crockford e Morningstar conseguiram carregar dados de forma assíncrona apontando um <iframe> para uma URL que retornaria um documento HTML como o acima. Quando a resposta fosse recebida, o JavaScript no HTML seria executado e, ao contornar as proteções do navegador, impedindo que as subjanelas acessassem o pai, o literal do objeto era passado de volta ao quadro principal do aplicativo. Essa técnica baseada em quadros, às vezes chamada de “técnica de quadros ocultos”, era comumente usada no final dos anos 90 antes da implementação generalizada do XMLHttpRequest . 14

Essa abordagem atraiu os desenvolvedores porque oferecia interoperabilidade em todos os navegadores. Como a mensagem é apenas JavaScript, ela não requer nenhum tipo de análise especial. A ideia de usar JavaScript dessa maneira era tão direta que o próprio Crockford disse que não era a primeira pessoa a fazê-lo - ele afirma que alguém na Netscape estava usando JavaScript para comunicar informações já em 1996. 15

Crockford e Morningstar perceberam que tinham algo que poderia ser usado em todos os tipos de aplicações. Eles nomearam seu formato JSON, que é a abreviação de “JavaScript Object Notation”. Eles começaram a lançá-lo aos clientes, mas logo descobriram que muitos não estavam dispostos a se arriscar em uma nova tecnologia que não tinha uma especificação oficial. Então Crockford decidiu que escreveria um. Em 2002, Crockford comprou o domínio JSON.org e colocou a gramática JSON e uma implementação de referência de um analisador. O site ainda está ativo, embora agora inclua um link proeminente para o padrão JSON ECMA ratificado em 2013. 16 Depois de criar o site, Crockford fez pouco mais para promover o JSON, mas logo encontrou pessoas enviando implementações de analisadores JSON para diferentes linguagens de programação. A origem do JSON está claramente ligada ao JavaScript, mas ficou claro que o JSON era adequado para trocar dados entre linguagens arbitrárias.

JSON em AJAX

Em 2005, Jesse James Garrett cunhou o termo “AJAX” em um post de blog, onde ele enfatizou que o AJAX não era uma nova tecnologia, mas sim “várias tecnologias, cada uma florescendo em seu próprio direito, reunindo-se de maneiras novas e poderosas”. 16 Sua postagem no blog continuou descrevendo como os desenvolvedores poderiam aproveitar JavaScript e XMLHttpRequest para criar novos tipos de aplicativos que fossem mais responsivos e com estado do que uma página da Web típica. Ele apontou para o Gmail, Google Maps e Flickr como exemplos de sites usando técnicas AJAX. Embora “X” em “AJAX” significasse XML, Garrett apontou o JSON como uma alternativa totalmente aceitável. Ele escreveu que “XML é o meio mais desenvolvido de obter dados dentro e fora de um cliente AJAX, mas não há razão para que você não consiga obter os mesmos efeitos usando uma tecnologia como JavaScript Object Notation ou qualquer meio semelhante de estruturar dados”. 17

JavaScript e JSON foram inequivocamente destinados a estar juntos. A semântica do JSON é mapeada diretamente para o JavaScript, tornando-o o formato de intercâmbio de dados nativo para a linguagem. Os desenvolvedores rapidamente descobriram que JSON era mais fácil de trabalhar em JavaScript, e muitos passaram a preferi-lo ao XML.

Como JSON chamou a atenção da blogosfera, a proliferação de JSON começou.

Por que o JSON se tornou mais popular que o XML

JSON é o formato nativo para dados em aplicativos JavaScript. Com a popularização do JavaScript na última década, mais mensagens JSON foram criadas do que qualquer outro formato de dados. Escrever aplicativos em JavaScript quase exige o uso de JSON para troca de dados. Outros formatos são possíveis, mas exigem mais esforço do que com JSON. Com o JavaScript ganhando popularidade para o desenvolvimento de aplicativos, o JSON seguiu de perto como o formato de intercâmbio de dados fácil de usar e integrado nativamente.

No que diz respeito à blogosfera, mais artigos, exemplos e tutoriais foram escritos sobre JavaScript (e, portanto, JSON) do que qualquer outra plataforma de programação.

A história e o caminho evolutivo da web tiveram um papel significativo na popularização do JSON. De acordo com o Stack Overflow, agora são feitas mais perguntas sobre JSON do que sobre outros formatos de intercâmbio de dados. 18

texto alternativo

De acordo com o Google Trends, um perfil semelhante é visto comparando o interesse de pesquisa por JSON e XML. 19

texto alternativo

A proliferação de JavaScript significa que JSON é melhor que XML?

As comunidades de desenvolvedores insistem que o JSON se tornou mais popular que o XML por causa de seu escopo declarativo conciso e semântica simples. O próprio Douglas Crockford resume algumas das vantagens do JSON no JSON.org: “JSON é mais fácil para humanos e máquinas entenderem, pois sua sintaxe é mínima e sua estrutura é previsível”. 20 Outros críticos do XML se concentraram na verbosidade do XML como o “imposto de colchetes angulares”. 21 O formato XML exige que cada tag de abertura corresponda a uma tag de fechamento, resultando em informações redundantes que podem tornar um documento XML significativamente maior do que um documento JSON equivalente quando descompactado. E, talvez mais importante, os desenvolvedores dizem: “também torna um documento XML mais difícil de ler”. 22

JSON foi prontamente elogiado devido à sua simplicidade e semântica concisa, e XML rotulado como um padrão antiquado do passado devido à sua verbosidade e complexidade aparentemente excessiva. Muitos artigos e postagens de blog oferecem uma perspectiva limitada ao comparar JSON com XML, levando os leitores a acreditar que JSON é um substituto para XML. Este não é o caso!

A perspectiva limitada oferecida por artigos e postagens de blog levou os leitores a descartar o XML como obsoleto, deixando muitos inconscientes de recursos poderosos que podem ajudá-los a melhorar a arquitetura e a resiliência de seu software a mudanças, bem como reduzir sistematicamente o risco do software.

JSON é mais popular que XML devido ao domínio do JavaScript como a linguagem mais usada atualmente. Com a influência do JavaScript nas tendências de software na última década, o JSON continua recebendo cada vez mais atenção do que qualquer outro formato de intercâmbio de dados. A blogosfera é rápida em ecoar que “JSON é melhor que XML”, mas na maioria das vezes, essas declarações são deixadas injustificadas ou são apoiadas por comparações simplistas em relação à semântica e verbosidade. Então, um padrão é melhor que o outro? A resposta a esta pergunta só pode vir de uma avaliação mais profunda de cada padrão.

Conclusão

De 1990 até hoje, a web percorreu um longo caminho. As guerras de navegadores entre Netscape e Microsoft levaram a uma catástrofe de divergência de HTML, e era necessária uma solução para salvar a web. O XML foi inventado para formalizar o XHTML e forneceu uma solução do Santo Graal para a computação como um todo. Desde a renderização de páginas HTML completas por servidores de back-end até AJAX e SPAs, as tendências na arquitetura da Web e no desenvolvimento de navegadores trouxeram o foco para o JavaScript, direcionando os desenvolvedores em todo o mundo para o JSON.

A popularidade do JSON está correlacionada com a do JavaScript. Com sua facilidade de uso e curva de aprendizado curta, o JavaScript trouxe mais novos desenvolvedores para escrever software do que qualquer outra linguagem. Com a integração nativa do JSON com a plataforma de desenvolvimento mais popular, não é surpreendente que mais perguntas sejam feitas sobre JSON no Stack Overflow do que qualquer outro formato de intercâmbio de dados.

Com as tendências de software nos últimos anos trazendo mais desenvolvedores de JavaScript para a indústria, o JSON ganhou o título de "formato de intercâmbio de dados mais popular".

Na superfície, a batalha de “JSON vs. XML” vai para JSON, mas em profundidade, há mais do que aparenta.

Na Parte 2 deste artigo, examinaremos mais detalhadamente os pontos fortes e fracos técnicos de JSON e XML e avaliaremos a adequação de cada padrão para aplicativos comuns e corporativos. Um olhar mais atento ao “intercâmbio de dados” revelará a amplitude de sua influência no risco de software do aplicativo como um todo. Uma compreensão mais profunda das diferenças fundamentais entre JSON e XML permitirá que os desenvolvedores avaliem melhor o risco de software de cada padrão em relação aos requisitos de seu projeto - para capacitar os desenvolvedores a construir um software mais estável e mais resistente a bugs e futuros desconhecidos.

A propósito, uma peculiaridade interessante da especificação JSON é que você não pode converter objetos JavaScript com relacionamentos bidirecionais, em que as propriedades filhas se referem às propriedades pai, em JSON. Fazer isso resultaria em um erro Uncaught TypeError: Converting circular structure to JSON . Para saber como contornar essa limitação, consulte Suporte de relacionamento bidirecional em JSON .

Referências

1. A Internet: Uma Enciclopédia Histórica. Cronologia, Volume 3, p. 130 (ABC-CLIO, 2005)

2. Manual de Metadados, Semântica e Ontologias, p. 109 (World Scientific, dezembro de 2013)

3. WebDiy.org - World Wide Web Consortium (W3C) - História

4. "JavaSoft envia Java 1.0" (Sun Microsystems, janeiro de 1996)

5. Habilitando espacialmente a Internet de próxima geração (David Engen, janeiro de 2002)

6. A história do XMLHTTP (AlexHopmann.com, janeiro de 2007)

7. Iniciando o Ajax - Página 2 (Wiley Publishing, março de 2007)

8. Ajax: uma nova abordagem para aplicativos da Web (Jesse James Garrett, fevereiro de 2005)

9. Uma Breve História do Ajax (Aaron Swartz, dezembro de 2005)

10. "O que é Kayak.com?" (Antecedentes Corporativos, outubro de 2008)

11. Navegação Interna: Ampliando o Paradigma de Navegação de Navegação (Netscape, maio de 2003)

12. "Um site independente usando DHTML" (SlashDotSlash.com, julho de 2012)

13. Entrega de dados e informações de formatação para permitir a manipulação do lado do cliente (US Patent Bureau, abril de 2002)

14. "O que é Ajax?" Ajax Profissional, 2ª ed. (Wiley, março de 2007)

15. Douglas Crockford: The JSON Saga (Yahoo!, julho de 2009)

16. Norma ECMA 404 (ECMA Internacional, dezembro de 2017)

17. Ajax: uma nova abordagem para aplicativos da Web (Jesse James Garrett, fevereiro de 2005)

18. Tendências de estouro de pilha (estouro de pilha, 2009-2019)

19. Google Trends (Google, 2004-2019)

20. JSON: The Fat-Free Alternative to XML (Crockford, 2006)

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

22. Xml é uma merda (WikiWikiWeb, 2016)