5 ms·

this... this is actually what we did in 199x, before xmlhttprequest. there's a reason we switched away from that.

by _ZeD_ 4y ago

denton-scratch 4y ago
XMLHttpRequest is fine and groovy (if your user has Javascript enabled, of course). But why does everything have to be JSON?
- Kinrany 4y ago
  JSON is close to using the most fundamental logical primitives needed to structure serialized data. It's a set of value types, an ordered collection and a key-value collection.
  - mort96 4y ago
    With a syntax that's ridiculously easy to write a parser and generator for (with the one exception of high unicode character escape sequences being encoded as two \uXXXX escapes after each other which form a surrogate pair rather than one \uXXXXXXXX escape, which is a bitch to deal with unless you use UTF-16 internally). It's certainly easier to write a mostly-correct JSON parser than an XML parser.
  - artificialLimbs 4y ago
    But why not just return hypermedia, assuming a web page?
    - Kinrany 4y ago
      What do you mean? JSON can be hypermedia, you can even click hyperlinks in browsers.
      - artificialLimbs 4y ago
        You can't return JSON to the browser. (I mean you can, but why lol?) You have to interpret both up and down stream with a JSON parser (usually JS). In contrast, you can return hypertext/hypermedia directly to the browser and the user can interact with it immediately, without needing translation layers. A primer: https://dev.to/rajasegar/html-over-the-wire-is-the-future-of-web-development-542c https://dev.to/rajasegar/html-over-the-wire-is-the-future-of...
- TheRealPomax 4y ago
  Because it is a vast improvement over XML, the thing that XMLHttpRequest was designed to be used for. It was supposed to be an http request for a DTD'd XML asset, and thank god we stopped using it for that and went "no that's okay, it doesn't enforce XML compliance, we'll use it for any text content we want, thanks". Which of course turned out to be incredibly dangerous when that text is (or is derived from) user-generated content, and that's where JSON comes in: JSON is a true data format, instantly turned into the native object that you can work with in the programming language that browser already has to speak in order to be considered a real browser. In stark contrast to XML, which ironically can't be turned into a data object, it can only be turned into a full fledged, separate document that you then need to use additional APIs for in order to extract data from. XMLHttpRequest was a bad idea that worked because it was also the best option because it was the only option. Thank goodness we moved on.
  - denton-scratch 4y ago
    I didn't mean to emphasize the 'XML' part of XMLHttpRequest; the payload can be anything. I think it always could be anything; I think it's always been possible to retrieve the unparsed raw data.
    - TheRealPomax 4y ago
      I know, hence the part where we decided to ignore XML and go for "arbitrary text", which is incredibly dangerous once we started working with user-generated content that we retrieved from a database and then injected into pages as innerHTML content, or loaded as off-page DOM fragment that we'd then copy nodes out of. In both cases, exploits were near-trivial. Using JSON to communicate just the content that needs to be shown, and making the client-side JS load that in directly (no parser behind JSON.parse required) so we can either template that into the page, or create some DOM nodes that we know are safe because we're setting textContent, not innerHTML, is immensely better. Could you do the same by sending yaml, or toml, or ini, or cfg or etc. etc. etc.? Probably, but browsers don't natively load any of those, whereas they do natively load JSON. Especially since the Fetch API landed way back in 2015. Native json loading has been a thing for 7+ years now.

this... this is actually what we did in 199x, before xmlhttprequest. there's a reason we switched away from that.

by _ZeD_ 4y ago

this... this is actually what we did in 199x, before xmlhttprequest. there's a reason we switched away from that.

XMLHttpRequest is fine and groovy (if your user has Javascript enabled, of course). But why does everything have to be JSON?

Kinrany 4y ago
JSON is close to using the most fundamental logical primitives needed to structure serialized data. It's a set of value types, an ordered collection and a key-value collection.
- mort96 4y ago
  With a syntax that's ridiculously easy to write a parser and generator for (with the one exception of high unicode character escape sequences being encoded as two \uXXXX escapes after each other which form a surrogate pair rather than one \uXXXXXXXX escape, which is a bitch to deal with unless you use UTF-16 internally). It's certainly easier to write a mostly-correct JSON parser than an XML parser.
- artificialLimbs 4y ago
  But why not just return hypermedia, assuming a web page?
  - Kinrany 4y ago
    What do you mean? JSON can be hypermedia, you can even click hyperlinks in browsers.
    - artificialLimbs 4y ago
      You can't return JSON to the browser. (I mean you can, but why lol?) You have to interpret both up and down stream with a JSON parser (usually JS). In contrast, you can return hypertext/hypermedia directly to the browser and the user can interact with it immediately, without needing translation layers. A primer: https://dev.to/rajasegar/html-over-the-wire-is-the-future-of-web-development-542c https://dev.to/rajasegar/html-over-the-wire-is-the-future-of...
TheRealPomax 4y ago
Because it is a vast improvement over XML, the thing that XMLHttpRequest was designed to be used for. It was supposed to be an http request for a DTD'd XML asset, and thank god we stopped using it for that and went "no that's okay, it doesn't enforce XML compliance, we'll use it for any text content we want, thanks". Which of course turned out to be incredibly dangerous when that text is (or is derived from) user-generated content, and that's where JSON comes in: JSON is a true data format, instantly turned into the native object that you can work with in the programming language that browser already has to speak in order to be considered a real browser. In stark contrast to XML, which ironically can't be turned into a data object, it can only be turned into a full fledged, separate document that you then need to use additional APIs for in order to extract data from. XMLHttpRequest was a bad idea that worked because it was also the best option because it was the only option. Thank goodness we moved on.
- denton-scratch 4y ago
  I didn't mean to emphasize the 'XML' part of XMLHttpRequest; the payload can be anything. I think it always could be anything; I think it's always been possible to retrieve the unparsed raw data.
  - TheRealPomax 4y ago
    I know, hence the part where we decided to ignore XML and go for "arbitrary text", which is incredibly dangerous once we started working with user-generated content that we retrieved from a database and then injected into pages as innerHTML content, or loaded as off-page DOM fragment that we'd then copy nodes out of. In both cases, exploits were near-trivial. Using JSON to communicate just the content that needs to be shown, and making the client-side JS load that in directly (no parser behind JSON.parse required) so we can either template that into the page, or create some DOM nodes that we know are safe because we're setting textContent, not innerHTML, is immensely better. Could you do the same by sending yaml, or toml, or ini, or cfg or etc. etc. etc.? Probably, but browsers don't natively load any of those, whereas they do natively load JSON. Especially since the Fetch API landed way back in 2015. Native json loading has been a thing for 7+ years now.