JSON continuous growth
Article written in September 2017
JSON has taken over the world. If today any two applications communicate with each other via the Internet, then most likely they do it with the help of JSON. The standard is accepted by all major players: out of the ten most popular Web APIs, which are developed mainly by large companies, such as Google, Facebook and Twitter, only one API transfers data to XML, and not JSON. For example, Twitter supported XML until 2013, when it released a new version of the API exclusively on JSON. Other JSON developers are also popular: according to Stack Overflow, more questions are asked about JSON than about any other data exchange format .
XML is still alive and much used. For example, in the web formats SVG, RSS and Atom. If the author of an Android application wants to announce that permission is required from the user, then it does so in the application manifest written in XML. And XML is not the only alternative to JSON: some developers opt for YAML or Protocol Buffers from Google. But these formats are not as popular as JSON, which has now become practically the de facto standard for exchanging data between programs via the Internet.
')
The dominance of JSON is surprising, since back in 2005 everyone was discussing the potential of “asynchronous JavaScript and XML”, and not “asynchronous JavaScript and JSON”. Of course, there is a possibility that it does not say anything about the relative popularity of the two formats, just AJAX seemed to be a more attractive abbreviation than AJAJ. But although in 2005 some already used JSON instead of XML (in fact, few people), you still wonder how XML could fall so sharply that a decade later the phrase “asynchronous JavaScript and XML” causes an ironic smile. What happened during this decade? How does JSON replace XML in many applications? And who came up with this data format, on which engineers and systems all over the world now depend?
The first JSON message was sent in April 2001 from a computer in a garage near San Francisco. The story has kept the names of those involved in the event: Douglas Crockford and Chip Morningstar, co-founders of the technology consulting company State Software.
These two were developing AJAX applications long before the term AJAX appeared. But application support in browsers was not very good. They wanted to send data to their application after the initial page load, but they didn’t find a way that would work in all browsers.
Today it is hard to believe, but Internet Explorer in 2001 was the most advanced browser. Since 1999, Internet Explorer 5 supported the early form XMLHttpRequest via ActiveX. Crockford and Morningstar could use this technology to get data in the application, but it did not work in Netscape 4. So, I had to look for another format that worked in both browsers.
The first JSON message looked like this:
Only a small part of the message reminds JSON as we know it today. The message itself is actually an HTML document with a couple of lines of JavaScript. The part that looks like JSON is simply a JavaScript literal for the
Crockford and Morningstar decided to abuse the HTML frame for sending data. For a frame, you can specify a URL that returns an HTML document similar to the one above. When the HTML is received, the JavaScript starts and passes the literal back to the application. This worked on the condition that the browser protection was carefully circumvented, preventing the child window from accessing the parent window: as you can see, Crockford and Morningstar explicitly set the document domain. This technique is sometimes called a hidden frame, it was often used in the late 90s before the appearance of the normal XMLHttpRequest .
It is surprising in the first JSON message that it’s not at all obvious that this is the first use of a new kind of data format. This is just JavaScript! In fact, the idea of ​​using JavaScript in such a way is so simple that Crockford himself believes that he was not the first to do this - he claims that someone in Netscape used JavaScript array literals to transfer information back in 1996 . A simple JavaScript message does not require any special parsing. Everything is done by the JavaScript interpreter.
In fact, the first-ever JSON message had problems with the interpreter. JavaScript reserves a huge number of words - 64 words are reserved in ECMAScript 6 - and Crockford and Morningstar unwittingly used them in their message: namely, the reserved word
Crockford and Morningstar realized that the new method can be used in all kinds of applications. They wanted to name the JSML (JavaScript Markup Language) format, but it turned out that the abbreviation is already occupied by something called Java Speech Markup Language. Therefore, we chose Javascript Object Notation, that is, JSON. They began to offer a format to their customers, but it soon became clear that they did not risk using an unknown technology without official specifications. Therefore, Crockford decided to write it.
In 2002, Crockford bought the domain JSON.org , published the JSON syntax and an example of the implementation of the parser. The website is still working, although it now demonstrates a link to the JSON ECMA standard adopted in 2013. In addition to launching the site, Crockford practically did nothing to promote JSON, but soon there were implementations of the JSON parser in various programming languages. Initially, JSON was clearly associated with JavaScript, but then it became clear that it is well suited for exchanging data between arbitrary pairs of languages.
JSON received a big push in 2005. Then the designer and developer named Jesse James Garrett in his article introduced the term AJAX. He tried to emphasize that AJAX is not just one new technology, but rather “some kind of good technology in its own way, combined in powerful new ways.” A new approach to developing web applications, Garrett gave the name AJAX. In a blog, he told how developers can use JavaScript and XMLHttpRequest to create more interactive applications. He called Gmail and Flickr examples of sites based on AJAX methods.
Of course, “X” in AJAX meant XML. But in subsequent questions and answers, Garrett called JSON a perfectly acceptable alternative. He wrote that "XML is the most functional data exchange tool for an AJAX client, but the same effect can be achieved using Javascript Object Notation or any similar data structuring format."
Developers did find that they could easily use JSON to build AJAX applications, and many chose it instead of XML. Ironically, interest in AJAX led to an explosion in the popularity of JSON. Around this time, JSON attracted the attention of the blogosphere.
In 2006, Dave Winer, a prolific blogger and creator of a number of XML technologies, such as RSS and XML-RPC, complained that JSON reinvents XML without a good reason:
Easy to understand Weiner's frustration. XML never really liked. Even Wiener himself said that he didn’t like XML . But XML was designed as a universal system for any application imaginable. XML is actually a metalanguage that allows you to define domain languages ​​for specific applications — for example, RSS and SOAP. Winer believes that it is important to develop a consensus for the sake of all the advantages that the general exchange format carries. In his opinion, the flexibility of XML is able to satisfy any need. Still, JSON is a format that does not offer any advantages over XML, with the exception of trash cleanup, which made XML so flexible.
Crockford saw Weiner's blog post and left a comment. In response to the charge that JSON reinvents XML, Crockford wrote: “ Reinventing the wheel is good because you can make it round . ”
By 2014, JSON was officially recognized as the ECMA and RFC standard. He got his MIME type. JSON advanced to the big leagues.
Why JSON has become much more popular than XML?
On JSON.org, Crockford lists some of the advantages of JSON over XML . He writes that JSON is easier for people and machines to understand, since its syntax is minimal and its structure is predictable. Other bloggers mention the verbosity of XML and "tag taxes." Each opening tag in XML must have a closing tag, which means a lot of redundant information. This makes XML much more than the equivalent JSON document, but more importantly, because of this, the XML document is more difficult to read.
Crockford called another great advantage of JSON: that it was originally designed as a format for exchanging structured information between programs. Although XML was used for the same purpose, it was originally designed as a document markup language. It grew from SGML (Standard Generalized Markup Language), which, in turn, evolved from the markup language Scribe, intended for marking text like LaTeX. In XML, inside the tag there can be so-called “mixed content”, that is, text with embedded tags surrounding words or phrases. This is reminiscent of an editor marking a manuscript with a red or blue marker, a kind of metaphor for markup language. On the other hand, JSON does not support the exact equivalent of mixed content, which means that the structure is simplified. The document is best presented as a tree, but by discarding the idea of ​​the document, Crockford was able to restrict JSON with dictionaries and arrays of familiar elements that all programmers use in creating their programs.
Finally, my own hunch is that people didn’t like the entanglement of XML, and it really was because of its diversity. At first glance, it is difficult to distinguish between the actual XML and its sublanguages, such as RSS, ATOM, SOAP or SVG. The first lines of a typical XML document set the XML version, and then the specific sublanguage to which the XML document must correspond. This is already a lot of options compared to JSON, which is so simple that no new version of the JSON specification will ever be written. XML developers in an attempt to create a single data exchange format for the whole fell victim to the classic programmer's trap: excessive technical complexity. XML is so common that it is difficult to use for something simple.
In 2000, a campaign began to bring HTML into conformity with the XML standard. Published a specification for XML-compatible HTML, subsequently known as XHTML. Some browser manufacturers immediately began to support the new standard, but it quickly became apparent that the general public, working with HTML, did not want to change their habits. The new standard required more stringent XHTML validation than was accepted for HTML, but too many sites depended on the free rules of HTML. By 2009, activists stopped trying to write a second version of XHTML, when it became clear that the future was HTML5, which did not require compliance with XML.
If XHTML had succeeded, perhaps XML would have become a common data format, as its developers had hoped. Imagine a world in which HTML documents and API responses have exactly the same structure. In such a world, JSON might not have become as popular as it is today. But I consider the failure of XHTML to be a kind of moral defeat for the XML camp. If XML did not help HTML, perhaps there are better tools for other applications. In the real world, it's easy to see why the simple and highly specialized JSON format has been so successful.
JSON has taken over the world. If today any two applications communicate with each other via the Internet, then most likely they do it with the help of JSON. The standard is accepted by all major players: out of the ten most popular Web APIs, which are developed mainly by large companies, such as Google, Facebook and Twitter, only one API transfers data to XML, and not JSON. For example, Twitter supported XML until 2013, when it released a new version of the API exclusively on JSON. Other JSON developers are also popular: according to Stack Overflow, more questions are asked about JSON than about any other data exchange format .
XML is still alive and much used. For example, in the web formats SVG, RSS and Atom. If the author of an Android application wants to announce that permission is required from the user, then it does so in the application manifest written in XML. And XML is not the only alternative to JSON: some developers opt for YAML or Protocol Buffers from Google. But these formats are not as popular as JSON, which has now become practically the de facto standard for exchanging data between programs via the Internet.
')
The dominance of JSON is surprising, since back in 2005 everyone was discussing the potential of “asynchronous JavaScript and XML”, and not “asynchronous JavaScript and JSON”. Of course, there is a possibility that it does not say anything about the relative popularity of the two formats, just AJAX seemed to be a more attractive abbreviation than AJAJ. But although in 2005 some already used JSON instead of XML (in fact, few people), you still wonder how XML could fall so sharply that a decade later the phrase “asynchronous JavaScript and XML” causes an ironic smile. What happened during this decade? How does JSON replace XML in many applications? And who came up with this data format, on which engineers and systems all over the world now depend?
JSON Birth
The first JSON message was sent in April 2001 from a computer in a garage near San Francisco. The story has kept the names of those involved in the event: Douglas Crockford and Chip Morningstar, co-founders of the technology consulting company State Software.
These two were developing AJAX applications long before the term AJAX appeared. But application support in browsers was not very good. They wanted to send data to their application after the initial page load, but they didn’t find a way that would work in all browsers.
Today it is hard to believe, but Internet Explorer in 2001 was the most advanced browser. Since 1999, Internet Explorer 5 supported the early form XMLHttpRequest via ActiveX. Crockford and Morningstar could use this technology to get data in the application, but it did not work in Netscape 4. So, I had to look for another format that worked in both browsers.
The first JSON message looked like this:
<html><head><script> document.domain = 'fudco'; parent.session.receive( { to: "session", do: "test", text: "Hello world" } ) </script></head></html> Only a small part of the message reminds JSON as we know it today. The message itself is actually an HTML document with a couple of lines of JavaScript. The part that looks like JSON is simply a JavaScript literal for the
receive() function.Crockford and Morningstar decided to abuse the HTML frame for sending data. For a frame, you can specify a URL that returns an HTML document similar to the one above. When the HTML is received, the JavaScript starts and passes the literal back to the application. This worked on the condition that the browser protection was carefully circumvented, preventing the child window from accessing the parent window: as you can see, Crockford and Morningstar explicitly set the document domain. This technique is sometimes called a hidden frame, it was often used in the late 90s before the appearance of the normal XMLHttpRequest .
It is surprising in the first JSON message that it’s not at all obvious that this is the first use of a new kind of data format. This is just JavaScript! In fact, the idea of ​​using JavaScript in such a way is so simple that Crockford himself believes that he was not the first to do this - he claims that someone in Netscape used JavaScript array literals to transfer information back in 1996 . A simple JavaScript message does not require any special parsing. Everything is done by the JavaScript interpreter.
In fact, the first-ever JSON message had problems with the interpreter. JavaScript reserves a huge number of words - 64 words are reserved in ECMAScript 6 - and Crockford and Morningstar unwittingly used them in their message: namely, the reserved word
do as the key. Since there are so many reserved words in JavaScript, Crockford decided not to avoid them, but simply to quote all the JSON keys. The quoted key is considered by the JavaScript interpreter as a string, so you can safely use reserved words. This is why JSON keys are still quoted.Crockford and Morningstar realized that the new method can be used in all kinds of applications. They wanted to name the JSML (JavaScript Markup Language) format, but it turned out that the abbreviation is already occupied by something called Java Speech Markup Language. Therefore, we chose Javascript Object Notation, that is, JSON. They began to offer a format to their customers, but it soon became clear that they did not risk using an unknown technology without official specifications. Therefore, Crockford decided to write it.
In 2002, Crockford bought the domain JSON.org , published the JSON syntax and an example of the implementation of the parser. The website is still working, although it now demonstrates a link to the JSON ECMA standard adopted in 2013. In addition to launching the site, Crockford practically did nothing to promote JSON, but soon there were implementations of the JSON parser in various programming languages. Initially, JSON was clearly associated with JavaScript, but then it became clear that it is well suited for exchanging data between arbitrary pairs of languages.
Wrong AJAX
JSON received a big push in 2005. Then the designer and developer named Jesse James Garrett in his article introduced the term AJAX. He tried to emphasize that AJAX is not just one new technology, but rather “some kind of good technology in its own way, combined in powerful new ways.” A new approach to developing web applications, Garrett gave the name AJAX. In a blog, he told how developers can use JavaScript and XMLHttpRequest to create more interactive applications. He called Gmail and Flickr examples of sites based on AJAX methods.
Of course, “X” in AJAX meant XML. But in subsequent questions and answers, Garrett called JSON a perfectly acceptable alternative. He wrote that "XML is the most functional data exchange tool for an AJAX client, but the same effect can be achieved using Javascript Object Notation or any similar data structuring format."
Developers did find that they could easily use JSON to build AJAX applications, and many chose it instead of XML. Ironically, interest in AJAX led to an explosion in the popularity of JSON. Around this time, JSON attracted the attention of the blogosphere.
In 2006, Dave Winer, a prolific blogger and creator of a number of XML technologies, such as RSS and XML-RPC, complained that JSON reinvents XML without a good reason:
“Of course, I can write a procedure for parsing [JSON], but look at how far they went in re-inventing the technology: for some reason, XML is not good enough for them (I wonder why). Who created this parody? Let's find a tree and hang a guy. Right now".
Easy to understand Weiner's frustration. XML never really liked. Even Wiener himself said that he didn’t like XML . But XML was designed as a universal system for any application imaginable. XML is actually a metalanguage that allows you to define domain languages ​​for specific applications — for example, RSS and SOAP. Winer believes that it is important to develop a consensus for the sake of all the advantages that the general exchange format carries. In his opinion, the flexibility of XML is able to satisfy any need. Still, JSON is a format that does not offer any advantages over XML, with the exception of trash cleanup, which made XML so flexible.
Crockford saw Weiner's blog post and left a comment. In response to the charge that JSON reinvents XML, Crockford wrote: “ Reinventing the wheel is good because you can make it round . ”
JSON vs XML
By 2014, JSON was officially recognized as the ECMA and RFC standard. He got his MIME type. JSON advanced to the big leagues.
Why JSON has become much more popular than XML?
On JSON.org, Crockford lists some of the advantages of JSON over XML . He writes that JSON is easier for people and machines to understand, since its syntax is minimal and its structure is predictable. Other bloggers mention the verbosity of XML and "tag taxes." Each opening tag in XML must have a closing tag, which means a lot of redundant information. This makes XML much more than the equivalent JSON document, but more importantly, because of this, the XML document is more difficult to read.
Crockford called another great advantage of JSON: that it was originally designed as a format for exchanging structured information between programs. Although XML was used for the same purpose, it was originally designed as a document markup language. It grew from SGML (Standard Generalized Markup Language), which, in turn, evolved from the markup language Scribe, intended for marking text like LaTeX. In XML, inside the tag there can be so-called “mixed content”, that is, text with embedded tags surrounding words or phrases. This is reminiscent of an editor marking a manuscript with a red or blue marker, a kind of metaphor for markup language. On the other hand, JSON does not support the exact equivalent of mixed content, which means that the structure is simplified. The document is best presented as a tree, but by discarding the idea of ​​the document, Crockford was able to restrict JSON with dictionaries and arrays of familiar elements that all programmers use in creating their programs.
Finally, my own hunch is that people didn’t like the entanglement of XML, and it really was because of its diversity. At first glance, it is difficult to distinguish between the actual XML and its sublanguages, such as RSS, ATOM, SOAP or SVG. The first lines of a typical XML document set the XML version, and then the specific sublanguage to which the XML document must correspond. This is already a lot of options compared to JSON, which is so simple that no new version of the JSON specification will ever be written. XML developers in an attempt to create a single data exchange format for the whole fell victim to the classic programmer's trap: excessive technical complexity. XML is so common that it is difficult to use for something simple.
In 2000, a campaign began to bring HTML into conformity with the XML standard. Published a specification for XML-compatible HTML, subsequently known as XHTML. Some browser manufacturers immediately began to support the new standard, but it quickly became apparent that the general public, working with HTML, did not want to change their habits. The new standard required more stringent XHTML validation than was accepted for HTML, but too many sites depended on the free rules of HTML. By 2009, activists stopped trying to write a second version of XHTML, when it became clear that the future was HTML5, which did not require compliance with XML.
If XHTML had succeeded, perhaps XML would have become a common data format, as its developers had hoped. Imagine a world in which HTML documents and API responses have exactly the same structure. In such a world, JSON might not have become as popular as it is today. But I consider the failure of XHTML to be a kind of moral defeat for the XML camp. If XML did not help HTML, perhaps there are better tools for other applications. In the real world, it's easy to see why the simple and highly specialized JSON format has been so successful.
Source: https://habr.com/ru/post/421657/
All Articles