4 ms·

Sweet, it supports trailing commas! Single biggest personal JSON annoyance.

codethief 4y ago
That, and comments! Personally, I really hope Human JSON, https://github.com/tailscale/hujson https://github.com/tailscale/hujson , will get more popular!
- higherhalf 4y ago
  There's also JSON5 https://json5.org https://json5.org
- ranting-moth 4y ago
  JSON initially had comments. https://www.freecodecamp.org/news/comments-in-json/ https://www.freecodecamp.org/news/comments-in-json/ They were removed from the standard because some were using them for custom parser directives.
  - MereInterest 4y ago
    I feel like that is throwing away all the advantages of comments with any benefits. If somebody wants to add parsing directives, they could still be added through specific keys or strings.
capableweb 4y ago
That's a big pet peeve for me as well! Only thing remaining now is those pesky colons (edit: was semi-colons) that everyone and their mother seems to place in their new formats. Just get rid of them already! Who wants to type `{name: "pveierland"}` when you could just do `{name "pveierland"}`?!
- Drakim 4y ago
  Not a fan, it looks kinda alright when you are using a string like that, but {num 5, val 4} looks alien to me. If you used this style in a programming language you'd even get {num var} which is even worse.
  - capableweb 4y ago
    Alien is not a reason something is bad, just that's it's unusual. JSON was a bit alien when it first arrived as well, as everyone was used to XML at the time. `{num 5, val 4}` looks fine to me, but we can do even better! We already know objects/maps are always in pairs, so we don't really need that comma either. Just do `{num 5 val 4}` and we save yet another unnecessary characters. Of course, I didn't come up with this format myself, what I actually want JSON to be is EDN (https://github.com/edn-format/edn https://github.com/edn-format/edn) which is a standalone format but also directly used in Clojure, so it already exists inside a programming language and works very well. There keys are strings though, so you example would end up being `{"num" 5 "val" 5 "person" var}`, where commas are optional.
    - estebank 4y ago
      For machine to machine interchange formats, removing redundant elements is reasonable, but for formats that are meant to be read (and more critically, edited) by humans it is better to have syntactical redundancy. It makes it easier to scan documents and much, much easier to provide human-friendly parser errors when we inevitably make mistakes. The redundancy works as flagposts that both machines and humans can use to get their bearings even in the face of malformed input.
      - capableweb 4y ago
        I think it's highly subjective what's easier for humans to read/write. Personally, I much prefer the latter of these two: JSON: [ { "id":"0003", "type":"donut", "name":"Old Fashioned", "ppu":0.55, "batters":{ "batter":[ { "id":"1001", "type":"Regular" } ] }, "topping":[ { "id":"5004", "type":"Maple" } ] } ] EDN [{"id" "0003" "type" "donut" "name" "Old Fashioned" "ppu" 0.55 "batters" {"batter" [{"id" "1001" "type" "Regular"}]} "topping" [{"id" "5004" "type" "Maple"}]}] Strings (like `"id"`) are usually keywords (like `:id`) in EDN, but I still find it much easier to parse and understand. I've read a lot more JSON over the years than I've read EDN, so I don't think it's a "used to" feeling I have either.
- mkl 4y ago
  That's a colon, not a semicolon. I prefer them myself, as I find them easier to read and slightly simpler to process in ad hoc ways with sed etc.
  - capableweb 4y ago
    Cheers, I'll blame the typo on lack of coffee. Although I'd like to get rid of both colons and semi-colons.
- kaba0 4y ago
  Linked from elsewhere in this thread: KDL

That, and comments! Personally, I really hope Human JSON, https://github.com/tailscale/hujson https://github.com/tailscale/hujson , will get more popular!

higherhalf 4y ago
There's also JSON5 https://json5.org https://json5.org
ranting-moth 4y ago
JSON initially had comments. https://www.freecodecamp.org/news/comments-in-json/ https://www.freecodecamp.org/news/comments-in-json/ They were removed from the standard because some were using them for custom parser directives.
- MereInterest 4y ago
  I feel like that is throwing away all the advantages of comments with any benefits. If somebody wants to add parsing directives, they could still be added through specific keys or strings.

capableweb 4y ago

That's a big pet peeve for me as well! Only thing remaining now is those pesky colons (edit: was semi-colons) that everyone and their mother seems to place in their new formats. Just get rid of them already! Who wants to type `{name: "pveierland"}` when you could just do `{name "pveierland"}`?!

Drakim 4y ago
Not a fan, it looks kinda alright when you are using a string like that, but {num 5, val 4} looks alien to me. If you used this style in a programming language you'd even get {num var} which is even worse.
- capableweb 4y ago
  Alien is not a reason something is bad, just that's it's unusual. JSON was a bit alien when it first arrived as well, as everyone was used to XML at the time. `{num 5, val 4}` looks fine to me, but we can do even better! We already know objects/maps are always in pairs, so we don't really need that comma either. Just do `{num 5 val 4}` and we save yet another unnecessary characters. Of course, I didn't come up with this format myself, what I actually want JSON to be is EDN (https://github.com/edn-format/edn https://github.com/edn-format/edn) which is a standalone format but also directly used in Clojure, so it already exists inside a programming language and works very well. There keys are strings though, so you example would end up being `{"num" 5 "val" 5 "person" var}`, where commas are optional.
  - estebank 4y ago
    For machine to machine interchange formats, removing redundant elements is reasonable, but for formats that are meant to be read (and more critically, edited) by humans it is better to have syntactical redundancy. It makes it easier to scan documents and much, much easier to provide human-friendly parser errors when we inevitably make mistakes. The redundancy works as flagposts that both machines and humans can use to get their bearings even in the face of malformed input.
    - capableweb 4y ago
      I think it's highly subjective what's easier for humans to read/write. Personally, I much prefer the latter of these two: JSON: [ { "id":"0003", "type":"donut", "name":"Old Fashioned", "ppu":0.55, "batters":{ "batter":[ { "id":"1001", "type":"Regular" } ] }, "topping":[ { "id":"5004", "type":"Maple" } ] } ] EDN [{"id" "0003" "type" "donut" "name" "Old Fashioned" "ppu" 0.55 "batters" {"batter" [{"id" "1001" "type" "Regular"}]} "topping" [{"id" "5004" "type" "Maple"}]}] Strings (like `"id"`) are usually keywords (like `:id`) in EDN, but I still find it much easier to parse and understand. I've read a lot more JSON over the years than I've read EDN, so I don't think it's a "used to" feeling I have either.
mkl 4y ago
That's a colon, not a semicolon. I prefer them myself, as I find them easier to read and slightly simpler to process in ad hoc ways with sed etc.
- capableweb 4y ago
  Cheers, I'll blame the typo on lack of coffee. Although I'd like to get rid of both colons and semi-colons.
kaba0 4y ago
Linked from elsewhere in this thread: KDL