Hacker News Reader

Most languages have JSON5 libraries just as they have TOML libs.

TOML is decent but if you need nested data it gets super awkward.

> What if you have an issue in prod and need to fix something quick? You might only be able to open it up in a stripped-down vi, or if the machine is locked down you might only be able to materialize a plain text view. What if not everyone uses the same tool? This imposes a further constraint. Yet more concessions pointing to how horrible JSON is for humans.

JSON5 is pretty easy to edit correctly with any text editor. Not much harder than TOML.

> Can you imagine projects where [lack of programmability] might be an issue? These aren't the only codebases in the world. And just because VSCode appears to be doing fine doesn't mean they don't second guess that decision. They might just be locked in at this point.

Does TOML allow programmability that JSON5 doesn't?

This is the first time I read about TOM. After checking out the syntax, I don't like the way you declare nested data, because if you need to move one block of data to a different parent you need to replace all the path of each table. If done wrong, this can lead to very difficult to find errors. OTOH, it can be easier to send partial information, just append this block to your config and you are done.

How do you tell if a file is json or json5? Feels better to forget about json for config and go with the obvious TOML that has single file extension with single standard.

While J4X would simply let you specify the version number in the DTD, if course! ;)

https://news.ycombinator.com/item?id=19656646

If you're trying to parse it, you don't need to tell. Just parse as JSON5, it's a strict superset.

And if you're editing a file, you can usually tell by the fact that there are comments in it. :)

Official json5 site does mention using .json5 extension to be obvious but I bet people will just use .json which will be confusing if the file is passed to another party and they get parse error until they realize it's json5. I think the only downside to json5 is that they inherited the name json instead of coming up with a different name.

Generally, you swap out the config file at build time if that's a requirement. Just as a few examples - you can set up a dev/demo/prod(whatever you call these where you work) config file in .NET Core, Docker/K8S, Angular, etc. As far as I know, this is considered best practice.

There are many different needs.

  - static config
  - environment specification
  - runtime feature flagging 
  - semi-static control plane config 
  - rollout weights

Etc.

All of these have different characteristics.

Infrequently changed, a priori config that doesn't need to be changed in emergencies is suitable for baking in at compile time.

> What if you have an issue in prod and need to fix something quick?

Just fix it quick somewhere that’s not prod. Snowflaking has not been a good practice for a long time now, so arguing that a certain tool makes it easier is a bit of a moot point.