
Why is JSON so popular? Developers want out of the syntax business - william-shulman
http://blog.mongolab.com/?p=23
======
olliej
The 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_ ]

~~~
ajross
I gotta ask: that just sounds wrong to me. The fact that it used a built-in
parser was supposed to have been a _feature_ of JSON. Have we pedantricized
that into a bad thing now too? What's the disadvantage of "allowing invalid
JSON" in an application protocol you control? Likewise, what's the value of
valid JSON (I honestly don't know what the example here is) that can't be
parsed by a Javascript interpreter?

And where does the "huge security hole" come from? I certainly hope you're not
saying that you trust requests generated by client code...

~~~
olliej
The moment you use eval to parse "JSON" data you _are_ trusting content from
the client. eval _executes_ javascript, JSON just happens to be mostly
compatible with JS object and array literal syntax so it "Just Works".

Because eval is executing the data it is using the full JS parser. That means
that while '{"name":"bill"}' works as expected '{"name": window.location =
"myevildownload.com"}' does too.

JSON.parse is built into the language. It enforces strict JSON conformance so
you can't end up accidentally having invalid content that won't be parsed by
other JSON libraries, and it does not execute data -- it creates the object
graph and nothing else. If there's anything that is not valid JSON it fails
and has no side effects. When constructing the object graph it uses the real
Object and Array constructors, so nothing can be injected that way. When
setting properties on objects it sets them directly and does not call setters.

If you use JSON.parse to parse your JSON data, it is not possible for an
attacker to either run or inject code in your site.

And it's faster than eval.

~~~
majmun
> The moment you use eval to parse "JSON" data you _are_ trusting content from
> the client. eval _executes_ javascript, JSON just happens to be mostly
> compatible with JS object and array literal syntax so it "Just Works".

not nesseserily , this attack could be easily mitigated if supposed JSON
string is first parsed and validated on server. and only then send back to
eval() on browser.

so it is therefore not inherently unsafe to use eval() on JSON.

~~~
olliej
Your server side validation would have to be a full JSON parser. So in order
to use eval, you're adding a full server side parse of the data on each
request, increasing server load, and request latency (i've seen sites sending
megs of json to the browser).

All so that you can save 6 characters of typing to load the JSON less
efficiently on the client side.

Of course because people _do_ do this most engines these days preflight calls
to eval to see if they can be parsed as a subset of pseude-JSON. Note: this
doesn't make it safe, any inject xss is not valid json so will still be a
hole, and these preparsers try to bail out quickly so treat only a minimal
subset of JSON. In JavaScriptCore (so all webkit browsers other than chrome)
you can't have escaped characters in string literals nor any non-ascii
characters anywhere.

------
RyanMcGreal
The 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.

~~~
iacvlvs
I'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.

~~~
kalleboo
It looks like it was written by someone who wanted to parse their XML using
regexps instead of a real parser.

------
senko
JSON 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
JSON is an example of 'worse is better'.

~~~
kleiba
You mean "less is more".

~~~
william42
He means Worse is Better: <http://dreamsongs.com/WorseIsBetter.html>

------
rmc
XML is good as a _markup_ language. Unfortunatly many people use it as a data
serialization language.

------
pbreit
The 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
No 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.

------
carsongross
The 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
That 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.

~~~
DuncanIdaho
Not 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
I 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.

------
PotatoEngineer
The 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
That 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
I 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
XSLT 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.

------
jasonlotito
JSON 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.

------
greyfade
XML 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."

------
hesselink
One 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?

------
angstrom
I 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.

------
arrakeen
just gimme sexps

~~~
william-shulman
Hard to believe we had the right answer in 1960 yet are still afraid of the
parens as an industry.

~~~
ericmoritz
(we (are (very (afraid)))

~~~
irahul
More like (afraid (very (are (we))))

or clojurish: (-> we are very afraid)

~~~
lani
Master Yoda called, he wants his cool back

------
getone
you 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
With 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.

------
lazylland
I 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
If 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.

------
nirvdrum
The 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
Yes, there is support for stream parsing of JSON. I haven't tried it myself,
<https://github.com/lloyd/yajl> is one example, which has various bindings in
other languages.

~~~
nirvdrum
Ahh, 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.

------
alecco

      <Product>
        <RecordReference>T0142</RecordReference>
        <NotificationType>03</NotificationType>
    

The horror.

------
jmmcd

        Map m = new HashMap();
        m.put("a", 1);
        m.put("b", 2);
        m.put("c", 3);
        .
        .
        .
    

The single worst thing in Java?

~~~
eonwe
I 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.

------
faseidl
I blogged a detailed response here: <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.

------
stephenr
Ironically, php provides a way to access XML data almost as easily as JASON
data - SimpleXML. Do other languages/frameworks really have nothing similar?

~~~
zachanker
While 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.

~~~
yahelc
The moment I realized I could do
json_decode(json_encode($simple_xml_object),true); to turn a complex SimpleXML
object into an array was the happiest moment of my life.

~~~
mun2mun
Every day you learn a new thing. Thank you very much.

------
mgutz
"all you need to do is call eval on a JSON string to obtain a first-class
Javascript object"

need i say more?

------
jerhewet
LINQ to XML. Couldn't be easier!

~~~
mythz
var yesItCan = JSON.parse(json);

------
mpunaskar
first thing that comes to mind is saving on bandwith.imagine sending same
amount data down the line with less bandwidth.

~~~
arocks
Actually 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

------
jeez
why did XML happen at all? JSON looks like the obvious solution. :\

