Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • because JSON is in the following sense "universal":

    every format/structure that has numbers, strings, booleans, null/none, finite lists of items, and string-indexed records of items already contains JSON

    and that's pretty much the barebones you need for a configuration language

    (of course you can argue about the syntax)

  • For our internal tooling we use something similar to a bash profile config file with name/value pairs separated by linebreaks. So, our configs look something like:

    env=staging

    db=0.0.0.0

    #descriptive comment

    etc=true

  • In my opinion, JSON is not the best format and has some problems. Lack of comments is one of the reasons, as they mention in there. Another is the lack of trailing commas (optional trailing commas would be useful for manually written files). However, these are problems with the syntax, and there are also problems with the data, such as a lack of a proper integer type, lack of Infinity and NaN, lack of support for character sets other than Unicode (and ASCII), lack of proper octet string type, etc.
  • I really like the EDN[1][2] (extensible data notation) format that is used mostly by Clojure for config and data transfer/exchange. It is so much more expressive than JSON and supports a well thought-out set of elements for the most common data structures.

    [1]: https://github.com/edn-format/edn

    [2]: https://en.wikipedia.org/wiki/Clojure#Extensible_Data_Notati...

  • For Caddy we chose JSON because it's fairly universal, maps nearly 1:1 with Go structs (useful for initializing an extensible server), and nearly everything else compiles to JSON one way or another, so you can choose your own config format, really: https://caddyserver.com/docs/config-adapters
  • > Why do so many tools have JSON config files‽

    1: Because JSON is a very easy serialization format to work with. I suspect these tools all have configuration classes / objects that are deserialized straight from the config file.

    2: I suspect a lot of these tools are written in Javascript, and in Javascript JSON is very easy to work with.

  • > A lot of tech folks resist documentation because they think it provides them with job security.

    No, we're just lazy.

  • > Why do so many tools have JSON config files‽ Commenting why options have been set the way they have is just such a basic thing to want to do… Why do tech people have such an aversion to writing things down⁇

    That's the whole post. First I don't know why this is posted on HN. Second I don't see how "JSON config" and "writing things down" are the two opposite options.

Explore Birbla archives