Crockford fala que não inventou o JSON, mas sim o descobriu e formalizou. Em 1996, algo em torno de 5 anos antes da formalização do JSON por Crockford, alguns desenvolvedors do Netscape já usavam arrays literals de JavaScript para troca de dados. O que ele fez foi dar uma especificação e um site ao formato. O restante aconteceu por conta própria.
A primeira mensagem JSON
Em 2001, Crockford fundou a empresa Veil e nela trabalhava em aplicações web que hoje chamaríamos de aplicações Ajax. Em 2002 a empresa teve o nome alterado para State Software.
No código abaixo nós temos a primeira mensagem JSON trafegada na Veil. Ela foi enviada em abril de 2001, como resposta (response) a um submit de um form enviado pelo laptop de Crockford.
<html><head><script>
document.domain = 'fudco.com';
parent.session.receive(
{to: "session", do: "test",
"text": "Hello world"}
);
</script></head></html>
Uma breve descrição de como funciona esse código: ele era encapsulado por tags HTML pois deveria funcionar no Internet Explorer e Netscape; na segunda linha é redefinido o domínio para que a política de “same-origin policy” não barrasse a requisição; e, logo depois, o método receive do frame que recebe a mensagem é executado para, de fato, tratar os dados recebidos. Uma bela gambiarra.
Mas o envio da mensagem falhou. E o motivo da falha foi o uso da palavra reservada do do JavaScript. Palavras reservadas no JavaScript devem ser quoted, e Crockford então optou por fazer com que, no padrão JSON, todas as keys fossem quoted ao invés de fazer e atualizar uma lista de todas as palavras reservadas da linguagem. Assim ficaria mais simples. E, além disso, seguia o mesmo padrão do Python.
E é por isso que todas as keys do JSON são quoted.
JSML, o quase-nome
O segundo óbvio passo era escolher um nome para o futuro padrão. JSML foi o nome escolhido. Mas já havia uma linguagem, que ninguém nunca tinha ouvido falar, no mundo Java que usava esse acrônimo, a Java Speech Markup Language.
Com esse empecílho optaram por mudar de nome e então batizaram o novo padrão de JSON, ou JavaScript Object Notation.
Isso não é um padrão
Os clientes da empresa de Crockford se recusaram a usar JSON pois alegavam que ele não era um padrão. Então Crockford fez dele um padrão. Ele comprou o domínio json.org, definiu a gramática e implementou um parser em Java, para servir de referência. E, desde então, o site está online com a especificação. Praticamente do mesmo jeito desde que foi lançado.
Ajax
O formato começou a ganhar bastante popularidade com o advento do Ajax, popularizado por Jesse James Garrett a partir de 2005. As pessoas achavam trabalhar com XML algo muito complexo e verboso, e logo descobriram que as tarefas ficavam mais simples se feitas com JSON.
JSON is the intersection of modern programming languages
Mesmo com a sigla Ajax significando Assynchronous JavaScript and XML, foi o JSON que acabou se tornando o padrão de troca de dados entre cliente e servidor.
O logo
O logo foi desenhado pelo próprio Crockford. Ele é basedo em uma ilusão de ótica chamada de Impossible Torus. É uma imagem 2D que representa algo 3D que é impossível de existir em um mundo tridimensional (na verdade, há pouco tempo provaram o contrário).
Sem comentários
Com a popularização, algumas pessoas começaram a usar os comentários para adicionar instruções ao parser, gerando uma complexidade desnecessária e quebrando a interoperabilidade, já que as instruções eram escritas para parsers específicos.
The least we’ve to agree to interoperate, the more likely we’re gonna be able to do it well
E retirar comentários JavaScript do JSON nos ports dos parsers escritos em outras linguagens estava, também, adicionando muita complexidade na implementação destes mesmos parsers.
Além disso, com a retirada dos comentários, JSON ficava também mais alinhado com a especificação do YAML, uma outra linguagem de marcação muito similar com JSON e que estava começando a ganhar popularidade.
Minimalismo
O formato JSON foi desenhado desde o início para ser simples. E sua especificação é tão simples que ela toda cabe em um cartão de visitas, que Crockford sempre distribui em suas palestras. Ele defende a idéia de que quanto menos tivermos de concordar em algo para interoperar, mais provável isso será de acontecer.
Versionamento
Não há versão 1.0, 1.1 ou nem 2.0 no JSON. Na verdade, não existe e não irá existir nunca uma versão. O que significa que o formato nunca irá mudar. Para Crockford a estabilidade é mais importante que qualquer nova feature que por ventura venha a ser adicionada. Daí sua decisão em não versionar a especificação.
Talvez um dia o JSON deixe de ser o padrão de troca de dados entre diferentes aplicações. Mas JSON continuará sendo o mesmo JSON. Para sempre.
Licença
Ao escolher por uma licença, Crockford pensou em usar a MIT, por ser bastante flexível. Mas era 2002, menos de um anos após os atentados terroristas de 11 de setembro. E ele se sentia na obrigação de “fazer sua parte”. Então adicionou uma linha à licença MIT: The Software shall be used for Good, not Evil.
This software shall be used for Good, not Evil
E até hoje recebe e-mails de algumas pessoas perguntando: “Como vou saber se o que faço é mal?”. E outras mesmo dizendo: “Não vou usar seu software caso não mude a licença.” Parece que Crockford conseguiu “fazer sua parte” =).
E é por isso, meus caros, que o JSON é o que é hoje.