4 ms·

After XML, JSON. Then What?

13 points by draegtun 14y ago

kls 14y ago
I do like the syntax of TOML quite a bit, but it has the same issue that XML once had in that it is not natively supported in the browser. Things have changed a lot and non-native document parsing is a lost faster but one of JSON's primary advantages was an still is, is that it is a native browser format.
- Millennium 14y ago
  Native parsing is a red herring; even in the bad old days, it was quick enough to be unnoticeable unless you were working on Big Data in the browser. Moving to native-code parsing for the sake of performance is a major case of premature optimization. JSON's big advantage was that you didn't have to do any work. One function call, with a single argument, would take you from a blob of text to a fully populated data structure, and that function was already built into every browser. The name of the function has changed (eval() to JSON.parse()), and some genuine security enhancements went with that, but the form of the API hasn't, and there's a reason for that: anything more than one monadic function call is too much work. Some formats, like TOML, have gone so far as to explicitly specify the data structure they describe. You could make a no-work API like JSON's for that: TOML.parse() and TOML.stringify() would take up more code space than their corresponding JSON APIs, but using the APIs would still involve no work. Less work, in fact, because TOML has a date literal, which even JSON doesn't. Something like that could catch on.
PuercoPop 14y ago
S-expressions of course. See: http://www.schnada.de/grapt/eriknaggum-xmlrant.html http://www.schnada.de/grapt/eriknaggum-xmlrant.html
- draegtun 14y ago
  Yep. Or alternatively go for Rebol which JSON was originally influenced by - http://www.rebol.com/cgi-bin/blog.r?view=0423 http://www.rebol.com/cgi-bin/blog.r?view=0423
dragonwriter 14y ago
HTML: sure, its a little heavier than JS, but lighter than XML, popular languages have libraries to parse it (and doing it consistently is better since HTML5), and exposing an HTML-based API makes things easy to interact with.
rpedela 14y ago
Why don't we just change the JSON spec to include ISO 8601 date, time, timestamp, and comments?
- Millennium 14y ago
  The problem comes from the fact that JSON is explicitly defined in terms of JavaScript, and as a strict subset of JavaScript. You could add comments without much trouble, because JavaScript has comments. But JavaScript has no date literal, so neither does JSON, and adding one becomes problematic. You'd have to either decouple JSON from JavaScript, or you'd have to convince the ECMAScript folks to adopt a date literal syntax. It could be argued that decoupling JSON from JavaScript might be a good idea. It would force developers to stop parsing JSON as JavaScript (through eval() or script tags), and this alone would eliminate whole classes of bugs. But the logistics would be nothing short of nightmarish.
EdgarVerona 14y ago
Protocol buffers!

13 points by draegtun 14y ago

kls 14y ago

I do like the syntax of TOML quite a bit, but it has the same issue that XML once had in that it is not natively supported in the browser. Things have changed a lot and non-native document parsing is a lost faster but one of JSON's primary advantages was an still is, is that it is a native browser format.

Millennium 14y ago
Native parsing is a red herring; even in the bad old days, it was quick enough to be unnoticeable unless you were working on Big Data in the browser. Moving to native-code parsing for the sake of performance is a major case of premature optimization. JSON's big advantage was that you didn't have to do any work. One function call, with a single argument, would take you from a blob of text to a fully populated data structure, and that function was already built into every browser. The name of the function has changed (eval() to JSON.parse()), and some genuine security enhancements went with that, but the form of the API hasn't, and there's a reason for that: anything more than one monadic function call is too much work. Some formats, like TOML, have gone so far as to explicitly specify the data structure they describe. You could make a no-work API like JSON's for that: TOML.parse() and TOML.stringify() would take up more code space than their corresponding JSON APIs, but using the APIs would still involve no work. Less work, in fact, because TOML has a date literal, which even JSON doesn't. Something like that could catch on.

PuercoPop 14y ago

S-expressions of course. See: http://www.schnada.de/grapt/eriknaggum-xmlrant.html http://www.schnada.de/grapt/eriknaggum-xmlrant.html

draegtun 14y ago
Yep. Or alternatively go for Rebol which JSON was originally influenced by - http://www.rebol.com/cgi-bin/blog.r?view=0423 http://www.rebol.com/cgi-bin/blog.r?view=0423

dragonwriter 14y ago

HTML: sure, its a little heavier than JS, but lighter than XML, popular languages have libraries to parse it (and doing it consistently is better since HTML5), and exposing an HTML-based API makes things easy to interact with.

rpedela 14y ago

Why don't we just change the JSON spec to include ISO 8601 date, time, timestamp, and comments?

Millennium 14y ago
The problem comes from the fact that JSON is explicitly defined in terms of JavaScript, and as a strict subset of JavaScript. You could add comments without much trouble, because JavaScript has comments. But JavaScript has no date literal, so neither does JSON, and adding one becomes problematic. You'd have to either decouple JSON from JavaScript, or you'd have to convince the ECMAScript folks to adopt a date literal syntax. It could be argued that decoupling JSON from JavaScript might be a good idea. It would force developers to stop parsing JSON as JavaScript (through eval() or script tags), and this alone would eliminate whole classes of bugs. But the logistics would be nothing short of nightmarish.

EdgarVerona 14y ago

Protocol buffers!