TOML is a better format for configuration files IMO, if not for many reasons, primarily because TOML accepts comments.
However, one annoying thing for TOML was the lack of schema, and the reliance on JSON Schema for that. Which I decided to tackle years ago when I started the TOML Schema project. In the past few months I leveraged code agents to take to the finish line and got something compelling: tomlschema.org
I'd argue that for code, yes, JSON is vastly closer to computer structures.
I think this is the real "why do so many tools have JSON config files": because it's just a literal notation, for basic data structures, that looks a lot like what many programming languages natively do, what their data structures natively are. The answer to the post is: it's mechanistic sympathy.
For humans, I do find TOML to be a lot easier to manage. Even if you have a really good editor that takes care of all the quoting/nesting/comma concerns for you, even if you have jsonc or json5 with comments, it's still not as easy/friendly as a big flat file with sections in it.
Interesting. The website says that it's "validation-focused". I don't know how that plays out for TOML, but the lack of focus in json schema to define an interface in addition to validation can be very frustrating. Most of the time I would rather trade off some expressitivity in terms of validation in favor of having a defined typed interface into the validated data.
It would be too easy to have every option in a config file documented in comments in the default config file. Think of the poor tutorial industry. It may even make chatbots less useful.
Let me guess... if they're a form of Lisp, did someone add jndi support, then made it possible to print to the console while the string gets read and finally made it executable because who wouldn't want a LISP for-loop in an Oracle connection string? On to the next RCE...
Nah, they are pretty constrained data description. AFAIK, you can't even substitute environment variables.
They are also apparently very hard to use, to the point that many people can't and several web sites exist that will take your database server, username, and password and assemble a connection string for you. (I can see no issues with that! None!)
JSON is obviously a poor choice. It's job is to interchange data, produced and parsed by computers.
ESR had the idea of writing configuration in English. It didn't gain traction at the time, but we have LLMs now. It might be a good idea to revisit the idea of accepting plain english. The LLM output could then be any format that's easy and unambiguous to parse.
I'm not sure why there's a problem before even trying.
Say for instance you have a program that keeps recipes. In your configuration file, there's settings such as metric/imperical units, allergies, diets, type of stove in your kitchen, and some theming (font, size, color...). You put them all in a file that you can parse, but aunt tillie messes up the formatting and the program breaks.
Instead of changing the config by hand, an LLM could supply the diff according to instructions in English. I really don't see why this would be "Terrible for prod". If the LLM screws up, you're simply back to square 1 and aunt tillie will call you just like she would before she had an LLM to fix her computer.
Using an LLM to parse your application's config is a bit like using an F1 racecar to drive from your house to the bicycle in your attached garage. Getting config into the application should to be fast, light (lighter than the rest of the application), and deterministic. And if the LLM's output is easy and unambiguous to parse, it's easier to simply use that as the original config file.
I totally get that. The application shouldn't use an LLM to parse the config file, but it would be useful to write one. An LLM could supply a diff to make the changes you want without learning the config-language-du-jour.
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.
In C#, I find "binary serialization" much easier to program with than JSON.
Then again, the resulting blobs require specialized tooling to read, and they're very hard to work with in other programming languages.
---
But, jokes aside:
I find CSV is great for "rows" because it doesn't repeat field names for every object.
I really like XML when each tag is an object, and fields are attributes. Most people don't understand this and end up making a hug mess; and some serializers do this by default too. IMO, this is why JSON became much more popular.
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:
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
JSON still a very simple and useful format and being natively supported on the web and by javascript basically guarantees its universality. Native comments would be nice though. But to be fair even Douglas Crockford suggested using comments in JSON was fine as long as you stripped them out before parsing.
<whispers>but Lua tables are even better.</whispers>
That is not quite true, because you have to define "numbers" and "strings" more specifically; JSON uses Unicode strings, and how numbers work depends on the implementation (but are generally finite 64-bit IEEE floating point; JSON does not have Infinity and NaN).
ASN.1 is almost a superset, but lacks a key/value list type; I had made some nonstadard extensions called ASN.1X and one of my new types is a key/value list type, so that makes the data types of ASN.1X a superset of JSON (although the format is different, it makes that all JSON data can be represented using DER if the nonstandard key/value list type of ASN.1X is used).
I don't like JSON that much because of its many problems (some are problems with syntax, others are problems with the data), so I use ASN.1X instead (with the DER format), for my own stuff (but I also deal with JSON because it is common enough).
I don't agree with "readable," though. For a simple set of key-values, yes. Once you get into complicated structures, other file formats express the semantics much better.
If you have a complex configuration you are doing it wrong... Spend some time thinking about you really want and turn it into a simple key-value setup. JSON should feel like it is overpowered and bloated for your needs. (I'd still use JSON because you can find a parser and editor that can handle it, but it should feel overpowered for your needs)
Which is better than the all too common middle ground: writing something once and then not maintaining it. I've been burned many times reading some documentation and thinking I understood until I discovered the code has changed since and the documentation is now wrong.
I'm in favor of documentation. I write it. I get people pointing at what I've written as examples of what everybody should do. However it is a lot of work. I'm constantly looking things over to be sure it still makes sense. I often wonder if it is really worth it. I hope you follow my example and write documentation, but it better feel like a lot of work.
SQLite is a tiny relational db that essentially runs right in the same folder as your application. No connection other than connecting from the app itself to the SQLite.db sitting next to it.
You're missing the point: Why are your config files so complicated that you need SQLite?
I've shipped a product that used SQLite, and we actively removed configuration from SQLite. It was a lot easier to diagnose issues when configuration was in text files, because non-programmers could kinda-sorta understand them without needing to learn how to use SQL.
I don't know about others, but I use JSON because it's in the standard Go library, and most of the times, I rather use something weird than add a dependency.
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
I wish everyone would embrace Amazon's Ion format. Of the data serialization formats it seems the most reasonable with the exception that it can encode S-expressions (so like having data serialization within your data serialization), so it is a bit excessive.
At a previous employer we tried using Ion, but when they stopped supporting our QLDB it was obvious that nothing else really used it and it was a dead end.
> 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.
> 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.
The "writing things down bit" is in the context of commenting. I mean, it's literally in the same paragraph.
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.
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.
1. JSON parsers are available at your corner convenience store.
2. The format is too simple to have ambiguous behavior. No weird “yes” means true, 0 means false, odd rules about comments, blah blah blah. It’s hard to fuck up JSON (but obviously not impossible if you get creative).
3. It errors out early in the parsing if you mess it up.
4. Its data types are present in more or less any language.
5. Most configs are just key/value. JSON does this reasonably well.
6. It is easy to generate and validate JSON documents. For some use cases you don’t need a library (though you should use one).
7. There is only one way to do anything (sane).
8. Everyone is familiar with it.
9. It is dynamic. You do not need to pre-define your sections or keys ahead of time.
10. It can easily be auto formatted to look good with zero risk of changing semantics.
11. Data stores often natively support storing and querying JSON objects.
12. If you are old enough to remember the era when every tool invented its own, often very buggy, config format and parser you will also remember the moment you first saw a JSON config file that was parsed with a standard library parser and thought “finally, this is the modern way”, you will understand why JSON continues being popular. It was the first thing that unambiguously worked compared to what came before it.
This is like asking why people use their keys to open packages: it might not be the right tool for the job but it’s hard to mess up, is the closest thing to you that can get the job done, and everyone (with functioning hands/fingers) can do it with little issue.
I am also certain there is some small but non-zero percentage of people who do it simply because everyone else moralizes about not doing it. Spite is a powerful thing.
brunoborges | 10 hours ago
However, one annoying thing for TOML was the lack of schema, and the reliance on JSON Schema for that. Which I decided to tackle years ago when I started the TOML Schema project. In the past few months I leveraged code agents to take to the finish line and got something compelling: tomlschema.org
bakies | 10 hours ago
jauntywundrkind | 9 hours ago
I think this is the real "why do so many tools have JSON config files": because it's just a literal notation, for basic data structures, that looks a lot like what many programming languages natively do, what their data structures natively are. The answer to the post is: it's mechanistic sympathy.
For humans, I do find TOML to be a lot easier to manage. Even if you have a really good editor that takes care of all the quoting/nesting/comma concerns for you, even if you have jsonc or json5 with comments, it's still not as easy/friendly as a big flat file with sections in it.
leni536 | 10 hours ago
Sha1rholder | 9 hours ago
ChickeNES | 9 hours ago
marcosdumay | 9 hours ago
It should really define sections as something different from dot-separated identifier groups.
nottorp | 10 hours ago
mr_toad | 10 hours ago
eastbound | 10 hours ago
marcosdumay | 9 hours ago
They are also apparently very hard to use, to the point that many people can't and several web sites exist that will take your database server, username, and password and assemble a connection string for you. (I can see no issues with that! None!)
tosti | 10 hours ago
ESR had the idea of writing configuration in English. It didn't gain traction at the time, but we have LLMs now. It might be a good idea to revisit the idea of accepting plain english. The LLM output could then be any format that's easy and unambiguous to parse.
bigstrat2003 | 10 hours ago
samrus | 10 hours ago
Thats the problem isnt it? LLMs arent deterministic. Terrible for prod
anon291 | 9 hours ago
Still a terrible idea for config
NewJazz | 9 hours ago
tosti | 9 hours ago
Say for instance you have a program that keeps recipes. In your configuration file, there's settings such as metric/imperical units, allergies, diets, type of stove in your kitchen, and some theming (font, size, color...). You put them all in a file that you can parse, but aunt tillie messes up the formatting and the program breaks.
Instead of changing the config by hand, an LLM could supply the diff according to instructions in English. I really don't see why this would be "Terrible for prod". If the LLM screws up, you're simply back to square 1 and aunt tillie will call you just like she would before she had an LLM to fix her computer.
delecti | 9 hours ago
tosti | 7 hours ago
gwbas1c | 10 hours ago
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.
happymellon | 9 hours ago
gwbas1c | 9 hours ago
In C#, I find "binary serialization" much easier to program with than JSON.
Then again, the resulting blobs require specialized tooling to read, and they're very hard to work with in other programming languages.
---
But, jokes aside:
I find CSV is great for "rows" because it doesn't repeat field names for every object.
I really like XML when each tag is an object, and fields are attributes. Most people don't understand this and end up making a hug mess; and some serializers do this by default too. IMO, this is why JSON became much more popular.
bluGill | 9 hours ago
bonestamp2 | 10 hours ago
env=staging
db=0.0.0.0
#descriptive comment
etc=true
jetbalsa | 9 hours ago
[section_name]
key=value
key=value
Super3000 | 10 hours ago
It fits into the poor choices we made, <-- Parse error
Garlef | 10 hours ago
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)
[OP] stagas | 9 hours ago
dd8601fn | 9 hours ago
1) JSON is pretty darn good for storing configuration. Everything speaks it, and a pretty printed one is very readable/tweakable in a pinch.
2) If you insist that someone manually edit a significant amount of it, you kinda fucked up.
Just my opinion, but it feels like two separate things.
krapp | 9 hours ago
<whispers>but Lua tables are even better.</whispers>
arcanemachiner | 9 hours ago
6510 | 9 hours ago
deaf_coder | 9 hours ago
zzo38computer | 8 hours ago
ASN.1 is almost a superset, but lacks a key/value list type; I had made some nonstadard extensions called ASN.1X and one of my new types is a key/value list type, so that makes the data types of ASN.1X a superset of JSON (although the format is different, it makes that all JSON data can be represented using DER if the nonstandard key/value list type of ASN.1X is used).
I don't like JSON that much because of its many problems (some are problems with syntax, others are problems with the data), so I use ASN.1X instead (with the DER format), for my own stuff (but I also deal with JSON because it is common enough).
francisofascii | 9 hours ago
Because XML hasn't been cool for about two decades. And suggesting .ini would you laughed out of the room into retirement.
szatkus | 9 hours ago
No, we're just lazy.
binsquare | 9 hours ago
I don't think that's necessarily lazy, it's just efficient
herbst | 9 hours ago
That's what I am saying about my ruby codes as well. Still my boss wanted proper commit messages
zamadatix | 9 hours ago
gwbas1c | 9 hours ago
bluGill | 9 hours ago
jjice | 9 hours ago
bluGill | 9 hours ago
I'm in favor of documentation. I write it. I get people pointing at what I've written as examples of what everybody should do. However it is a lot of work. I'm constantly looking things over to be sure it still makes sense. I often wonder if it is really worth it. I hope you follow my example and write documentation, but it better feel like a lot of work.
spottedmarley | 9 hours ago
Y-bar | 9 hours ago
LambdaComplex | 9 hours ago
Y-bar | 9 hours ago
Given what I know about it (single file, no auth, and such by default) I sort of understand the ”file” part I think. But not the ”config” part.
spottedmarley | 9 hours ago
gwbas1c | 9 hours ago
I've shipped a product that used SQLite, and we actively removed configuration from SQLite. It was a lot easier to diagnose issues when configuration was in text files, because non-programmers could kinda-sorta understand them without needing to learn how to use SQL.
jamesponddotco | 9 hours ago
mholt | 9 hours ago
p4bl0 | 9 hours ago
climate_denier_ | 9 hours ago
https://en.wikipedia.org/wiki/Ion_(serialization_format)
happymellon | 9 hours ago
Shame.
raincole | 9 hours ago
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.
lelanthran | 9 hours ago
The "writing things down bit" is in the context of commenting. I mean, it's literally in the same paragraph.
phforms | 9 hours ago
[1]: https://github.com/edn-format/edn
[2]: https://en.wikipedia.org/wiki/Clojure#Extensible_Data_Notati...
zzo38computer | 8 hours ago
IgorPartola | 8 hours ago
2. The format is too simple to have ambiguous behavior. No weird “yes” means true, 0 means false, odd rules about comments, blah blah blah. It’s hard to fuck up JSON (but obviously not impossible if you get creative).
3. It errors out early in the parsing if you mess it up.
4. Its data types are present in more or less any language.
5. Most configs are just key/value. JSON does this reasonably well.
6. It is easy to generate and validate JSON documents. For some use cases you don’t need a library (though you should use one).
7. There is only one way to do anything (sane).
8. Everyone is familiar with it.
9. It is dynamic. You do not need to pre-define your sections or keys ahead of time.
10. It can easily be auto formatted to look good with zero risk of changing semantics.
11. Data stores often natively support storing and querying JSON objects.
12. If you are old enough to remember the era when every tool invented its own, often very buggy, config format and parser you will also remember the moment you first saw a JSON config file that was parsed with a standard library parser and thought “finally, this is the modern way”, you will understand why JSON continues being popular. It was the first thing that unambiguously worked compared to what came before it.
This is like asking why people use their keys to open packages: it might not be the right tool for the job but it’s hard to mess up, is the closest thing to you that can get the job done, and everyone (with functioning hands/fingers) can do it with little issue.
I am also certain there is some small but non-zero percentage of people who do it simply because everyone else moralizes about not doing it. Spite is a powerful thing.