Hacker News Reader

Comment by StavrosK | Hacker News Reader

Really? For me, editing JSON is always a chore, because you have to match the multiple nested brackets, otherwise your whole file is invalid and you get to have fun finding out what you did wrong. YAML, in comparison, can be visually inspected quickly.

However, with all the apprehension in the thread, I'm rethinking this decision. Maybe TOML would be better?

View on HN

Pretty printed json isn't too bad, but I intentionally never bulk edit it. This format shouldn't end up heavily nested anyway?

Toml is nice for simple configs/Cargo.toml but I think everything I said basically applies to it as well. Toml has recent work on it in 2017 for some (but not broad) library support but what does it look like in 2024?

Yeah, good point (plus it's not fantastic for this project anyway). I'm going to think hard on this, I quite like YAML...

Fwiw I like yaml as well but it's just got a few too many issues these days.

While you are thinking maybe look at this

https://stedolan.github.io/jq/

and how people could leverage it when using your format.

Ah yes, I know about jq, it's fantastic. I've switched to JSON, with heavy heart, but YAML seems too big indeed.

> I think everything I said basically applies to it as well.

TOML is a much simpler format than YAML, and is a dialect/formalisation of INI files which have yet to go out of style. Direct database storage seems like a red herring (why would you want to store a playlist as a json blob?), so does "trivial JS consumption of the file".

[0] the entire spec is 10 pages, and that's with lots of examples, YAML 1.2 is ~80 pages

I, on the other hand, loathe editing YAML configuration files because the nesting is so obtuse and difficult to figure out based on limited examples in open source projects. JSON is much easier.

Reply on news.ycombinator.com