> but really, why JSON? No comments, no multiline, no schema
Limitations are good. I find it really easy to read. You can install browser extensions to make it even more readable.
Schema can come from a well written specification.
> Was ditching XML for JSON just due to cosmetic / trending reasons?
No, as said before, it's easy to write / read / generate / parse. No awkward DOM style management if you want to parse out a value. I really hated it with XML.
> You can install browser extensions to make it even more readable.
Most browsers can display XML readably by default.
> Schema can come from a well written specification.
That doesn't replace a schema though.
> No, as said before, it's easy to write / read / generate / parse. No awkward DOM style management if you want to parse out a value.
"DOM-style management" of XML documents which can be replaced by JSON is equivalent to hand-rolling a JSON parser from the raw bytes. It's not the hardest thing in the world, but it's not exactly easy either.
With most XML applications equivalent to JSON, that part would be tucked away in the relevant library, e.g. the XML-RPC serialisation format is almost isomorphic to JSON[0], and in Python converting between native objects and the XML-RPC serialisation is just `loads` and `dumps`[1] — though you don't usually have to do that at all since the XML-RPC client will handle the serialisation and deserialisation for you automatically — which is more or less what the JSON library provides[2].
And JSON is convenient in dynamically typed languages because it maps more or less directly to their native dynamic structures, that's not quite the case for languages like C++ or Haskell.
[0] null (nil) is an extension but it natively supports binaries and datetimes
> that's not quite the case for languages like C++ or Haskell.
So handling XML in those languages are easier?
BTW if your server / services feel more native with XML serialization / parsing to native data structures use that. Picking JSON just because everybody else does it is not a good idea.
However if you make a public web API consumed mostly by browsers (JS), then yeah, pick JSON and REST.
Both are "crap" since they're dynamic information which has to be brought into a statically typed world. However depending on the schema it might be possible to automatically generate the binding and hide the dynamic resolution.
> BTW if your server / services feel more native with XML serialization / parsing to native data structures use that. Picking JSON just because everybody else does it is not a good idea.
> However if you make a public web API consumed mostly by browsers (JS), then yeah, pick JSON and REST.
Limitations are good. I find it really easy to read. You can install browser extensions to make it even more readable.
Schema can come from a well written specification.
> Was ditching XML for JSON just due to cosmetic / trending reasons?
No, as said before, it's easy to write / read / generate / parse. No awkward DOM style management if you want to parse out a value. I really hated it with XML.
HTML is fine also for what it was invented for.