1. 23

Or, as Tim Bray put it on Twitter, The last JSON specification in the history of the universe.

Full spec here:


  2. 17

    If only json had allowed trailing commas in lists and maps.

    1. 9

      And /* comments! */

      1. 3

        And 0x... hex notation…

        1. 3

          Please no. If you want structured configs, use yaml. JSON is not supposed to contain junk, it’s a wire format.

          1. 4

            But YAML is an incredibly complex and truth be told, rather surprising format. Every time I get it, I convert it to JSON and go on with my life. The tooling and support for JSON is a lot better, I think YAMLs place is on the sidelines of history.

            1. 4

              it’s a wire format

              If it’s a wire format not designed to be easily read by humans, why use a textual representation instead of binary?

              If it’s a wire format designed to be easily read by humans, why not add convenience for said humans?

              1. 1

                Things don’t have to be black and white, and they don’t even have to be specifically designed to be something. I can’t know what Douglas Crockford was thinking when he proposed JSON, but the fact is that since then it did become popular as a data interchange format. It means it was good enough and better than the alternatives at the time. And is still has its niche despite a wide choice of alternatives along the spectrum.

                What I’m saying is that adding comments is not essential a sure-fire way to make it better. It’s a trade-off, with a glaring disadvantage of being backwards incompatible. Which warrants my “please no”.

            2. 1

              http://hjson.org/ is handy for human-edited config files.

              1. 1
              2. 5

                The solutions exist!


                I don’t know why it’s not more popular, especially among go people.

                There is also http://json-schema.org/

                1. 3

                  I had to do a bunch of message validation in a node.js app a while ago. Although as Tim Bray says the spec’s pretty impenetrable and the various libraries inconsistent, once I’d got my head round JSON Schema and settled on ajv as a validator, it really helped out. Super easy to dynamically generate per message-type handler functions from the schema.

                  1. 2

                    One rather serious problem with json5 is its lack of unicode.

                  2. 3

                    I think this only show that JSON has chosen tradeoff that make it more geared to be edited by software, but has the advantage of being human editable/readable for debugging. JSON as config is not appropriate. There is so many more appropriate format (toml, yaml or even ini come to mind), why would you pick the one that doesn’t allows comments and nice sugar such as trailing commas or multiline string. I like how kubernetes does use YAML as its configuration files, but seems to work internally with JSON.

                    1. 8

                      IMO YAML is not human-friendly, being whitespace-sensitive. TOML isn’t great for nesting entries.

                      Sad that JSON made an effort to be human-friendly but missed that last 5% that everyone wants. Now we have a dozen JSON supersets which add varying levels of complexity on top.

                      1. 11

                        “anything whitespace sensitive is not human friendly” is a pretty dubious claim

                        1. 5

                          Solution: XML.

                          Not even being ironic here. It has everything you’d want.

                          1. 5

                            And a metric ton of stuff you do not want! (Not to mention…what humans find XML friendly?)

                            This endless cycle of reinvention of S-expressions with slightly different syntax depresses me. (And yeah, I did it too.)

                            1. -5


                              1. 13

                                Keep this shit off lobsters.

                      2. 1

                        If the post linked is correct, the addition is:

                        8259 con­tains one new sen­tence: “JSON text ex­changed be­tween sys­tems that are not part of a closed ecosys­tem MUST be en­cod­ed us­ing UTF-8 [RFC3629].” Giv­en that, by 2017, an at­tempt to ex­change JSON en­cod­ed in any­thing but UTF-8 would be ir­ra­tional, this hard­ly needs say­ing; but its ab­sence felt like an omis­sion.