10 ms·

With JSON you're not working with it as a tree, you're working with it as a set of objects. But what do you use to work with XML(or HTML) as a tree? You use DOM

by xaduha 11y ago

With JSON you're not working with it as a tree, you're working with it as a set of objects. But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. There are wrappers around DOM, like jQuery, but even that leads to some spaghetti code. JSON is a first class citizen in JS, XML isn't and never was. E4X never was properly supported by browsers. Namespaces and doctypes are not mandatory. Merits of a language and/or framework has little to do with it's popularity. There are much better languages/frameworks than Go or Angular, for example, but that doesn't make them popular. I'm not overthinking it, it's not my idea in the first place. > If only xml designers thought of their creation as pieces of flexible, composable hierarchical data not as documents. That's just plain nonsense, what are you talking about? Nothing was stopping you from using XML the way it used in React. In fact these recent 'discoveries' in Javascript-land (React, Flux, Redux) are totally not new ideas.

scotty79 11y ago
> With JSON you're not working with it as a tree, you're working with it as a set of objects. I can't agree with that. Each JSON payload is a tree with three kinds of nodes. Lists, associative arrays and values (of few flexible types). I'm not sure what you mean by set of objects because JSON doesn't have set type. You can have something like set if you use an array but disregard order or use associative array but disregard types. Also the objects can contain objects. That's what makes it actually a tree. > But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. Yes but you don't have to. You could map XML (at least the subset commonly used with AJAX) directly to tree of plain old JavaScript objects (you'd need some conventions though because in xml you can invent various ways of representing lists and associative arrays). > Namespaces and doctypes are not mandatory. Probably just my personal experience but some implementations of xml interoperability didn't allow me to specify default namespace for my xml tags which made me add bogus namespace identifier and prefix all my tags with that. Namespaces are optional but that optionality is not stated clearly enough in the spec and some apis don't allow you to forget about namespaces. > Nothing was stopping you from using XML the way it used in React. Just lack of good syntax/api. > I'm not overthinking it, it's not my idea in the first place. I was referring to your argument (as I understood it) that there are some deep mismatches between JSON and XML akin to object relational impedance mismatch. It's not that JSON is objects and XML is data. Both are just trees of values. My point is that the difference is just syntax but I'd like to backpedal from that now. JSON vs XML is not just syntax and lack of XML oddities. It's also a good deal of "less is more". Now I think JSON is XML but with one obvious way to express sequence and one obvious way to label the data for access. Anyways. I think we can agree to disagree and finish at that.
- xaduha 11y ago
  Bottomline is that you're not free to use what you want in the browser, that's what drove the popularity of JS (and JSON). If you think that XML was a popular choice, but then lost its popularity due to JSON having better syntax - that's not how it happened. JSON is easier to use, that's why it displaced XML in browsers. But if there was native or close to native (WebAssembly?) support of things like XSLT/XQuery 3.0 and XForms 2.0, then I would switch away from JS and its framework zoo in a heartbeat. > deep mismatches between JSON and XML not between JSON and XML, google "X/O Impedance Mismatch"

by xaduha 11y ago

scotty79 11y ago

> With JSON you're not working with it as a tree, you're working with it as a set of objects. I can't agree with that. Each JSON payload is a tree with three kinds of nodes. Lists, associative arrays and values (of few flexible types). I'm not sure what you mean by set of objects because JSON doesn't have set type. You can have something like set if you use an array but disregard order or use associative array but disregard types. Also the objects can contain objects. That's what makes it actually a tree. > But what do you use to work with XML(or HTML) as a tree? You use DOM, OO API. And DOM sucks. Yes but you don't have to. You could map XML (at least the subset commonly used with AJAX) directly to tree of plain old JavaScript objects (you'd need some conventions though because in xml you can invent various ways of representing lists and associative arrays). > Namespaces and doctypes are not mandatory. Probably just my personal experience but some implementations of xml interoperability didn't allow me to specify default namespace for my xml tags which made me add bogus namespace identifier and prefix all my tags with that. Namespaces are optional but that optionality is not stated clearly enough in the spec and some apis don't allow you to forget about namespaces. > Nothing was stopping you from using XML the way it used in React. Just lack of good syntax/api. > I'm not overthinking it, it's not my idea in the first place. I was referring to your argument (as I understood it) that there are some deep mismatches between JSON and XML akin to object relational impedance mismatch. It's not that JSON is objects and XML is data. Both are just trees of values. My point is that the difference is just syntax but I'd like to backpedal from that now. JSON vs XML is not just syntax and lack of XML oddities. It's also a good deal of "less is more". Now I think JSON is XML but with one obvious way to express sequence and one obvious way to label the data for access. Anyways. I think we can agree to disagree and finish at that.

xaduha 11y ago
Bottomline is that you're not free to use what you want in the browser, that's what drove the popularity of JS (and JSON). If you think that XML was a popular choice, but then lost its popularity due to JSON having better syntax - that's not how it happened. JSON is easier to use, that's why it displaced XML in browsers. But if there was native or close to native (WebAssembly?) support of things like XSLT/XQuery 3.0 and XForms 2.0, then I would switch away from JS and its framework zoo in a heartbeat. > deep mismatches between JSON and XML not between JSON and XML, google "X/O Impedance Mismatch"