11 ms·
Why is JSON so popular? Developers want out of the syntax business
- PotatoEngineer 15y agoThe mostly-just-one-way-to-organize-it approach cannot be overstated here. XPath is neat, but iterating through parser results is still a pain.
- SigmundA 15y agoThat because XML does not map well to Simula style OO. "Iterating" XML in XSLT (a language designed to manipulate XML) is way less of a pain.
- j_baker 15y agoI don't disagree with this, but I think there's something wrong when need another markup language to deal with the first markup language.
- SigmundA 15y agoXSLT is XML, that whats nice about it, you can reflect on it. XML has no operators for manipulating or evaluating, it is a metalanguage. XSLT adds this on top of XML to process XML.
- st0p 15y agoYou've got to be kidding. I see the usefulness of XSLT, but still XSLT is a synonym to pain. Definitely one of the most ugly syntaxes I've ever. It has a place, it can be useful, but I thoroughly detest it.
- SigmundA 15y agoNot kidding, XSLT is functional, it's very different from imperative style OO, it's not complex and can get a lot done with few lines of code. If you think it's painful and ugly, then don't dig any deeper in computer science than javascript.
- pbreit 15y agoThe problem with XML is that it seemed to encourage more complicated data structures. People sort of forgot that you still have to process all this data. And that, at the end of the day, a lot of it ends up needing to be represented in columns and rows.
- Kroem3r 15y agoNo question that's a huge problem; that's the gist of this thread after all. To my eye the problem with XML is that relational data feels like a hack and people specifying XML default to flattening their data. My favorite example is a thing called ONIX (for representing bibliographic metadata) which is irredeemably broken, but in world-wide use, none the less.
- olliej 15y agoThe post actually appears to endorse using eval to parse JSON. Not only does that allow invalid JSON through, it disallows some valid JSON, and of course is a huge security hole. If you want to handle JSON data in JavaScript use JSON.parse -- it's the safest, fastest, and most correct path to having your data available to you. [update: edited to remove bizarre use of whole vs hole... boggles]
- fletchowns 15y agoYes! I was shocked to see him recommend the use of a straight eval for parsing JSON. json2.js is a must! JSON.parse and JSON.stringify are your friends. https://github.com/douglascrockford/JSON-js/blob/master/json2.js https://github.com/douglascrockford/JSON-js/blob/master/json...
- olliej 15y agoToo my knowledge all browsers now ship with json built in -- if you must work with older browsers (not an entirely unreasonable requirement) you should check for the JSON object first, and if it isn't present load json2.js. Otherwise you're just adding an additional load penalty to your site (and on mobile browsers that can be 100s of milliseconds)
- DanielRibeiro 15y agoJson2.js does the check. However, it has to be loaded in order to be checked. Not a big issue if you are minifying and bundling all your js files before sending them to the browser client.
- daleharvey 15y agojust pointing out to others although the parent probably already knew, but JSON.parse is native in all modern browsers, json2 is only needed if you support older browsers (ie7)
- JackdawX 15y ago
- arrakeen 15y agojust gimme sexps
- william-shulman 15y agoHard to believe we had the right answer in 1960 yet are still afraid of the parens as an industry.
- ericmoritz 15y ago(we (are (very (afraid)))
- MetallicCloud 15y ago)
- guelo 15y ago:)
- irahul 15y agoMore like (afraid (very (are (we)))) or clojurish: (-> we are very afraid)
- lani 15y agoMaster Yoda called, he wants his cool back
- jhuni 15y ago(declare (very-afraid? we))
- danking00 15y agoTo be clear, the parent post is referring to the invention of LISP. As a side note, for those who don't know, JavaScript shares a number of features with LISP/Scheme. JSON has the trappings of the very LISPy idea of "Data = Code". It doesn't quite live up to it though. Now, if we only had a parenthesized syntax for JavaScript...
- stephenr 15y agoIronically, php provides a way to access XML data almost as easily as JASON data - SimpleXML. Do other languages/frameworks really have nothing similar?
- zachanker 15y agoWhile SimpleXML gives you an easy way to walk the tree, it still requires you to actually do it. All 3 of those examples would require slightly different calls to SimpleXML to handle.
- SigmundA 15y agowhat else do you do with a data structure besides walk it at some point? JSON comes out as an acyclic object graph in javascript, so what it still needs to be walked to actually do something with the data. The difference between walking JSON and XML is simply the syntax of the parser library your are using. The problem with XML is it has things that don't map directly to most OO languages, like node order matters, and attributes and elements are similar but different things, and mixed content. So JSON is nice simply because it's close the the OO style everyone is used to today, and is in fact a subset of one of those languages. IMO either way we need to settle on a way to interchange structured data, and agree on data types, but I would prefer some binary format, text encoding all this data such a waste of space/time.
- zachanker 15y agoReiterating the point the blog post makes, but: It's very very easy to structure the same data in different ways in XML. While JSON has the same issue, it's a lot harder to do and you have less flexibility in making bad storage decisions. You are absolutely right on walking the structure. JSON just tends to be easier (in my experience), even when working with XML libraries that make it less of a pain.
- nowarninglabel 15y agoI'll give the opposing opinion that I find working with XML easier than JSON, but mostly because of QueryPath.
- jerhewet 15y agoLINQ to XML. Couldn't be easier!
- mythz 15y agovar yesItCan = JSON.parse(json);
- carsongross 15y agoThe baby that has been thrown out with the bathwater here is a schema/data description layer. NOT, I repeat NOT, I repeat NOT for verification but rather for tools, so that people working in strongly typed languages can interact with JSON services in a reasonable manner. Unfortunately the one option I see, JSON Schema, appears to have caught the XML/Java bug, and has gotten very complicated.
- SigmundA 15y agoThat because schemas are complicated, no matter which way you encode the data. JSON is so nice and easy and simple until it needs all those things that made it into XML to get the job done. I whole heartedly agree, there is nothing sweeter than giving another vendor our WSDL with schema when they ask how to work with our system. It eliminates huge effort and ambiguity in system interaction.
- carsongross 15y agoWell, I think there is a middle ground: non-recursive structs, lists, maps, and some judicious "primitives" and basically allowing only natural tree mappings would go a long way, IMO.
- DuncanIdaho 15y agoNot sure if serious... SOAP, WSDL and everything else XML and XML Schema related is overkill for simple interfaces. For complex interfaces it is just - well too complex. If the time spent creating XML based web services that kinda but not really work (we're only talking interfaces here!) is spent documenting your JSON WS - you get quite a better experience. Ant this is the reason why everybody has switched to JSON.
- SigmundA 15y agoI am serious, document a JSON interface with what, English? Are you serious? JSON has no way to describe in machine readable way what to expect, instead you have to read a document then go hand code the interface in your language of choice. WSDL and SOAP is not complicated, and I have implemented my own SOAP stack. Then again everyone now days everyone thinks relational databases are complicated. If you you have tools that implement it for you then there is no excuse.
- RyanMcGreal 15y agoThe best way I've encountered to construct XML: <person> <property> <name>first-name</name> <value>John</value> </property> <property> <name>last-name</name> <value>Smith</value> </property> </person> I kid you not. That's what I'm dealing with at work right now. Thank you, enterprise SOAP solutions.
- knieveltech 15y agoThat makes me want to claw my eyes out, set fire to my keyboard and immigrate to China, where I will start a new life as a blind monk. Most of the worst experiences of my career as a developer involve some enterprise SOAP API or another.
- brehaut 15y agoxmlrpc[1] is similar. <?xml version="1.0"?> <methodCall> <methodName>examples.getStateName</methodName> <params> <param> <value><i4>41</i4></value> </param> </params> </methodCall> my favorite part[2] is how <params> only contain <param> elements within. each <param> has exactly one child. Why is it not just <params><i4>41</i4></params>?. Its no surprise that the creator of xmlrpc was involved with soap. [1] http://www.xmlrpc.com/spec http://www.xmlrpc.com/spec [2] not really.
- iacvlvs 15y agoI've worked with worse: <PERSON> <PERSON_HEADER_1> <PERSON_HEADER_1_NAME> <PERSON_HEADER_1_NAME_FIRST_NAME>John</PERSON_HEADER_1_NAME_FIRST_NAME> <PERSON_HEADER_1_NAME_LAST_NAME>Smith</PERSON_HEADER_1_NAME_LAST_NAME> </PERSON_HEADER_1_NAME> <PERSON_HEADER_1_ADDRESS> <PERSON_HEADER_1_ADDRESS_1>123 Some Street</PERSON_HEADER_1_ADDRESS_1> <PERSON_HEADER_1_ADDRESS_2>Blah</PERSON_HEADER_1_ADDRESS_2> <PERSON_HEADER_1_ADDRESS_3>Blah</PERSON_HEADER_1_ADDRESS_3> <PERSON_HEADER_1_ADDRESS_4>Blah</PERSON_HEADER_1_ADDRESS_4> </PERSON_HEADER_1_ADDRESS> ... and so on. I can't think of any advantage to (or excuse for) doing it this way. The only possible reason for it that I can think of, is rather comprehensive ignorance of how XML and related standards work.
- angstrom 15y agoI still prefer binary IDL over json/bson/xml. Keep the schema off the wire and out of storage. People tend to not get as crazy when they stick to lists.
- nirvdrum 15y agoThe article mentions SAX parsers and then kinda just moves on and talks a bit about loading JSON with eval. I realize there are other ways of doing things and a fair bit between his two data processing points. My experience with JSON is mostly limited to simple APIs. Is there a way to handle streaming JSON? I guess it'd be doable in a language like JavaScript where you build up the prototype. Others would probably vary substantially. But I can't say I've tried it yet.
- zachanker 15y agoYes, there is support for stream parsing of JSON. I haven't tried it myself, https://github.com/lloyd/yajl https://github.com/lloyd/yajl is one example, which has various bindings in other languages.
- nirvdrum 15y agoAhh, silly me. I never realized YAJL handled that. It should be a good place to learn from. The YAJL code base is pretty tight IIRC.
- jmmcd 15y agoMap m = new HashMap(); m.put("a", 1); m.put("b", 2); m.put("c", 3); . . . The single worst thing in Java?
- eonwe 15y agoI think the current way to write that is to either use Google Guave ImmutableMap.of("a", 1, "b", 2, "c", 3) or when mutable maps are required, to write: Map m = new HashMap() {{ put("a", 1); put("b", 2); put("c", 3); }}; Both of these are a bit lighter yet still far away from JavaScript or Ruby special syntaxes.
- senko 15y agoJSON is so popular because it's data description abilities are poorer than that of XMLs. Everything in JSON can be easily mapped to a few basic types in any popular language, and so all the JSON writers/readers do exactly that. The consequence is that it's very easy to work with JSON. Contrast with XML, which has node attributes and children, to start with. This alone is sufficient to make it not as naturally representable in any of the languages (Python's ElementTree does come close), so you have to worry about the "syntax". And that's not even considering namespaces or schema. XML having a much richer way to represent data and to reason about the meaning of the data make it a good format for case where it is important. But for everything else, JSON wins.
- rmc 15y agoJSON is an example of 'worse is better'.
- getone 15y agoyou could do {"name": {"first": "John", "last": "Smith" } } even for json there's multiple ways you could do it. You could also include the person like XML did, but oh well...
- loup-vaillant 15y agoWith JSON, there's still a culture of doing things the simplest possible way. Sure, it won't eliminate all the variability, but the lighter syntax makes needless complexity more obvious. For instance, if you don't need to separate the first name from the last name, {"name":"John Smith"} is obviously simplest. If you need to, and you have few other parameters besides the name, the OP's solution is obviously simplest. If there are lots, or if the name itself is complicated (first, last, mother's maiden name, pseudonym…), then your solution is obviously simplest.
- rmc 15y agoXML is good as a markup language. Unfortunatly many people use it as a data serialization language.
- mpunaskar 15y agofirst thing that comes to mind is saving on bandwith.imagine sending same amount data down the line with less bandwidth.
- arocks 15y agoActually early proponents of XML used to downplay this by claiming that it will be compressed on wire anyways and it's well-suited to higher compression
- jasonlotito 15y agoJSON is popular because: JSON can be consumed by JavaScript. This makes pushing JSON rules easy. I can create an API once in JSON. Now, someone can create a web app and make API calls with JavaScript. That's the reason it's popular. Another, smaller reason, is: Many languages/libraries/frameworks provide poor XML support. If your hand coding your XML-RPC/SOAP calls, or dealing with your average XML in a way different then you would JSON, I really don't know what to say other than: Why? All the other reasons: verbosity, confusion over XML, etc. All those are okay, I guess, but aren't good reasons. If JSON couldn't be parsed by JavaScript, it wouldn't be used.
- jeez 15y agowhy did XML happen at all? JSON looks like the obvious solution. :\
- hesselink 15y agoOne problem I have with JSON is that there is no canonical way to represent union types. For example, if you have the Haskell type data C = A { field1 :: T1, field2 :: T2 } | B { field3 :: T3 } How do you represent this in JSON? The contents of the 'A' or 'B' constructor are easy: { field1: value1, field2: value2 } But how do you indicate which constructor it is? I can come up with a couple less than ideal ways. Which one do others use?
- alecco 15y ago<Product> <RecordReference>T0142</RecordReference> <NotificationType>03</NotificationType> The horror.
- lazylland 15y agoI recall having an easy time de/serializing XML in C# ... you don't HAVE to get into the syntax business if you don't want to. And I think the Java also has something analogous in the JAXB library
- natural219 15y agoIf you work with any data that's remotely complicated (i.e. practically any relational data), then you get into some pretty hefty messes with C#'s and JAXB's serializers. Unless you know XML schemas thoroughly, trying to map pointers in serialized XML is a mess.
- mgutz 15y ago"all you need to do is call eval on a JSON string to obtain a first-class Javascript object" need i say more?
- faseidl 15y agoI blogged a detailed response here: http://bit.ly/lyCwCH http://bit.ly/lyCwCH But the bottom line is IMO the reason JSON is so popular (and it is popular) has more to do with the ubiquity of JavaScript in browsers than anything in the format itself.
- greyfade 15y agoXML was a solution to a problem that didn't exist. Actually, no, I take that back. XML was a solution that was created for a problem that was devised to justify the work. It's insanity for the sake of itself. JSON is simply a serialized object format for a popular programming language - that happened to fit the general case very well - yet it's also very much closer to S-expressions, which seem to be the most efficient way to model data in the general case. It makes me wonder how people manage to convince themselves that a format like XML is somehow a "good idea."