Ask HN: JSON or XML, questions about an idea ?

My first question would be "what are you writing this social network in?" Because I think every mainstream language in existence has free libraries to create both XML and JSON output (Javascript is made for it, .Net has WCF, there are several Gems for Ruby, php has _encode, etc...). So implementing both should just be a matter of passing the values to the appropriate function and reaping the benefits of already available libraries.

That in mind I'd say both. If for some reason you insist on choosing I'd probably say JSON. XML's only real advantage over JSON, imho, is it's human readability. That makes it great for stuff like configuration files. But for machine to machine communication JSON is faster and less prone to conversion errors. Plus it's easier to accept JSON in Javascript which you defined as your target audience.

It's strictly machine-to-machine, basically this is a way of extending the functionality of a website without having code server side, all the extension code runs on the browser of the end-user and talks to the server using the API.

The server side code for the project is going to be in PHP.

Think of it as HN on steroids, custom filtering and alternative user interfaces, tweaks and so on by adding chunks of javascript to the site, either just for yourself or if you think your stuff deserves a greater audience as a switchable plug in for others. If something is very well thought out we might make it default to 'on'.

Greasemonkey allows you to do some of this for a single user, but you normally wouldn't have access to the 'raw' data that builds up a site, in this case you would, all the rendering comes from the javascript. Another part of the configurables is custom stylesheets.

The general idea is that you can completely overhaul the front end of the site from a plug-in on the assumption that more than one person will want to make those changes we make those changes available to the rest of the users.

I got the idea a while ago while browsing HN, it's one of the things that made me wonder how far you can push customization of a website and my conclusion is very far if you are willing to give up control.

So the only criteria I would attach to public distribution of an extension would be that the extension is not malicious in intent. Beyond that it is 'anything goes'.

A 'hackable' social network. Very simple in basis but extremely extensible.

"That makes it great for stuff like configuration files"

Nothing beats YAML for configuration files.

For everything else, use JSON.

XML's only real advantage over JSON, imho, is it's human readability.

While there may be cases where this is true, I've never encountered any and I find this difficult to believe without some specific examples.

>> "XML's only real advantage over JSON, imho, is it's human readability."

You're obviously being sarcastic here.

XML/JSON: Answer is both. If you've built it well then you can just switch a template.

Your plugin system sounds a bit like AppEngine.

JSON if you need SPEED at the client or server ends. If speed isn't a major factor than XML may win out, depending on the complexity of the data your sending back. XML in large, hierarchies is going to be easier to read.

i agree. JSON for "simple" data structures if you want to save bandwith, XML if you want to have more complicate structured documents with markup.

That's a tough one. Ideally the javascript would render the page so that the absolute minimum would be transmitted across the line, basically just the raw data once per page, the javascript would stay cached on the clients machine.

But sending markup along would make the whole thing considerably easy to implement, I think (but this could be just a wrong gut feeling, I'll have to figure that one out).

I prefer JSON. Though I do agree with the other comments that xml is more readable if the structure is big, and that one can easily (and perhaps should) do both.

In practice I have noticed that where I work we tend to have complex data structures but not very deeply nested ones. We wrote a simple find function that recursively traverses the JSON structure looking for keys. Not anything nearly as powerful as XPath but sufficient.

It tends to be highly useful in my experience to create a list of objects. For example instead of a list of phone numbers a list of phone number objects. One may then easily add attributes to the phone number. Primary, cell phone, home phone etc. This tends to be highly flexible in that attributes may be later added that were not at all considered up front.

Of course all of this can be done with xml as well. JSON just seems more convenient. If I add an attribute in Javascript or Python I can just use it and get on with it. No messing with my SaxParser or building up some new XPath. Again I am not bashing xml at all, this is just my take.

In practice we use JSON exclusively in the core services for input and output. When we need to use xml we convert it to JSON and then back to XML as a filtering process rather than fool around with our core services. This adds overhead but keeps us flexible and loosely coupled.

JSON.

It makes for a significantly smaller payload (especially important in that in most cases, you're transmitting a great number of smaller chunks) and I don't buy the readability argument — especially when it's almost a no-brainer to employ a function to display to "pretty" indent JSON represenstation — print_r in PHP, pp in ruby, etc.…)

I believe just about every language used in web development includes a library for shuffling JSON in and out of native data structures.

JSON first. XML when people ask for it and when you have no more excuse to delay it. It is so much easier to play with JSON, or to pick a particular value. Most languages (with a library built-in or not), lets you manipulate the result as a combination of dictionary/hashmap and array/list. It is SO easy.

And advantage of XML is the ability to easily get substructures out of the data using XPath, and/or use XSLT to transform the XML directly to XHTML. So if you expect API users to be doing any filtering of the requested data on the fly at the client side, XML may be preferred.

Another rule of thumb is that the deeper the nesting of complex data structures, the easier XML will be to manipulte. With XPath I can quickly get a list of all the foo/bar/baz where haha=true, whereas with JSON I would have to have three nested loops to extract that data.

I would suggest provide support for both. As it has been mentioned, there are libraries that you can use to generate either of these. Tumblr is the first that came to my mind - it provides support for both.

Give developers freedom to choose either of them...

XML - because it is easily parsable, both client-side and server-side.