3 ms·

There is less typing than JSON.

Solomoriah 2y ago
There are <> characters, which are awkward on a good day. Yeah, we use them in HTML but the editor helps with that. And there are a bunch of special characters and "objects" that require interpretation. JSON has what? Quotes, square brackets, colons, and commas, used the way they are used in most programming languages, and thus familiar to most of us. Outside of terseness, which is overrated, what real advantages does XENON provide?
- GeneThomas 2y ago
  See the opening paragraph.
milch 2y ago
It seems a bit like a toss-up to me ... Taking examples from your landing page I can see some where there is less typing in JSON and some where there is more. For example, the book one - I counted the equivalent JSON and they were 128 non-whitespace characters vs. 127 non-whitespace characters. Practically, at least for my editor, I had to type less for JSON because every paired character automatically inserts the closing equivalent. This is likely to work across a wide range of editors from the browser console to whatever else fringe text input field. Once you account for paired characters JSON wins at 114 chars. Of course if you had editor support for XENON it could also automatically insert some of the control characters, at the very least all of the > and the <$>, which brings XENON to 117 chars typed. Anyway, I think you probably would've gotten a less strong response from people here if you had less absolute statements on the site ("better alternative", "the best way") - certainly there are going to be use-cases where this excels, but I can also see how the average simple REST API would be very unlikely to benefit from this, and the extra features may in fact expose it to more risk (e.g. the graph support, look at YAML and the CVEs it has caused over the years)
xigoi 2y ago
How is <$> less typing than }?
- GeneThomas 2y ago
  JSON has superfluous quotes for the field names in objects, so overall xᴇɴᴏɴ is more terse than ᴊꜱᴏɴ.

There are <> characters, which are awkward on a good day. Yeah, we use them in HTML but the editor helps with that. And there are a bunch of special characters and "objects" that require interpretation. JSON has what? Quotes, square brackets, colons, and commas, used the way they are used in most programming languages, and thus familiar to most of us. Outside of terseness, which is overrated, what real advantages does XENON provide?

GeneThomas 2y ago
See the opening paragraph.

milch 2y ago

It seems a bit like a toss-up to me ... Taking examples from your landing page I can see some where there is less typing in JSON and some where there is more. For example, the book one - I counted the equivalent JSON and they were 128 non-whitespace characters vs. 127 non-whitespace characters. Practically, at least for my editor, I had to type less for JSON because every paired character automatically inserts the closing equivalent. This is likely to work across a wide range of editors from the browser console to whatever else fringe text input field. Once you account for paired characters JSON wins at 114 chars. Of course if you had editor support for XENON it could also automatically insert some of the control characters, at the very least all of the > and the <$>, which brings XENON to 117 chars typed. Anyway, I think you probably would've gotten a less strong response from people here if you had less absolute statements on the site ("better alternative", "the best way") - certainly there are going to be use-cases where this excels, but I can also see how the average simple REST API would be very unlikely to benefit from this, and the extra features may in fact expose it to more risk (e.g. the graph support, look at YAML and the CVEs it has caused over the years)

xigoi 2y ago

How is <$> less typing than }?

GeneThomas 2y ago
JSON has superfluous quotes for the field names in objects, so overall xᴇɴᴏɴ is more terse than ᴊꜱᴏɴ.