Skip to content
loading...
Discussion
markdown guide
 

YAML, for a couple of very specific reasons:

  • It's reasonably concise. YAML doesn't waste huge amounts of space like XML usually does, it just uses exactly what's needed for structure and nothing more.
  • It allows comments. This is honestly one of my biggest complaints about JSON. On any reasonable system, your configuration should be properly documented, and that's harder to do without comments. Also, lack of support for comments makes it hard to temporarily disable a segment of the configuration.
  • It's not picky about quotes. Another complaint about JSON specifically, and some other config formats generically. I hate having to remember what type of quotation marks to use around values that need quoted, and for that matter whether or not values need quoted at all. YAML makes this dead simple.
  • In most implementations, it allows both full and partial reuse of segments of the configuration. This is a huge benefit when dealing with situations where you have to use essentially the same configuration for a bunch of things with minimal modification. YAML is a bit unique in that it's the only widespread config formats that lets you reuse the contents of a mapping while selectively changing only some keys.
 

I'm using JSON these days just because most of my day to day coding is js/ts and the native integration of JSON with these projects is seamless and clear.

I also agree with everything Austin S. Hemmelgarn expressed so clearly above.

Mostly I don't choose XML anymore. It was my go-to until just a few years ago.

One format you didn't mention that is still around in a big way for shell scripts is simple Key=Value files. They are not going away soon enough. :)

 

Thank you for your detailed response!

Comments are key for what we are working on right now. Our configuration files are enormous and if we take away comments it becomes confusing and we can't ship with optional segments disabled.

I know some people love to hate YAML, so as we are building out our products I want to make sure we are making informed decisions about why we choose YAML, or any other config format for that matter.

 

Austin got all my points, in special about comments, he didn't express all the hate and loathe that XML deserve, I really "dislike" it with the intensity of a thousand suns. Is basically a machine that converts simple, clear and useful data into a hot mess that you can only hope is somewhat well defined. I applaud his restraint tho, well done sir.

 

"Into a hot mess you can only hope is somewhat well defined"

🀣

That hit me so hard it took me back into my IT days.

 

I have to disagree about quotes (standard should always be double quotes, and if single quote only for chars), and there is problem about Yes, No, true, false, date-time.

It is just some JSON over-done.

Otherwise, you are right about circular reference.

 

I'll agree on the point about handling of booleans, it gets a bit tricky at times in YAML, especially since some tools that use YAML accept other things for booleans (for example, lots of stuff accpets on and off as booleans in it's configuration when using YAML).

As far as quotes though, I would argue that it's actually better even for those who are pedantic about quoting that YAML doesn't care. Yes, you might run into existing YAM that quotes things differently than you expect, but OTOH you can use whichever quoting (including none at all in many cases) you prefer and it just works (provided it's not crazy stuff like Lua's multiline string format or Python's triple quotes). If you want to use double quotes for everything, nothing is preventing you from doing that, but for those of us who don't want to have to hit shift dozens of extra times, it's still accommodating.

 

If it's simple enough, I'll just set it as a bunch of environment variables in an rc file and be done with it.

If I'm working with python or javascript, I'll just create a dict or object in a config.{py|js} file.

For CI pipelines and deployment jobs, I'm kinda used to YAML because CircleCI and I guess the support for multi-line values is quite handy.

Otherwise I guess I would go for JSON, but I haven't had to do that in ages.

 

Here's a poll I did last week. Most of the users preferred JSON

oh! I misspelled JSON

 

It's quite interesting because maybe the votes went to Jon just for fun 🀣

 
 

I would suggest using the simplest format you can think of, and not create a complex hierarchical file format if you donΒ΄t need it.

If you can make it line-based it will be easier to query, concatenate, edit and filter from a UNIX-style command-line.

 

I've never understood how JSON was ever accepted as anything except datav transfer notation. One of the biggest misteries in life. I think it was too much of a rebellious drive from the despised by many XML and soap for datac transfer. Suddenly XML was the root of all evil in software.

XML is a bit annoying but functional.
Yaml needs some consistency work. Also I've found be lost inside the structure. Sources are not always the most recognisable element.

 

Due to lack of real life choices, I have to choose YAML, and sometimes, *.js; but I like JSON because

  • Picky about quotes. Not being picky leads to unexpected behavior.
  • Picky about true, false

For anything that includes multi-line string, I would have to use YAML. Someone posted a nice tutorial a while ago... There is no alternative, if not for some indentation-based syntax...

 

I like YAML but it often adds quite a bit of overhead as it's not as universally supported as JSON (many languages will need a library, some basic text editors won't recognize it, you can't pass it directly to your front-end, you can't display it nicely in Firefox...).

So if I don't need the advanced features of YAML I usually stick to JSON. It's just a shame that JSON was conceived only as a data format and thus doesn't support comments and trailing commas, because it would have been a really good configuration format.

 

Honestly supporting comments is really make or break for our product right now.

 

INI files. I like to keep my config files as simple as possible and nothing is simpler than a basic key value structure

 
Classic DEV Post from Jul 30 '19

PublishTo.Dev: Scheduling article publishing on dev.to

Amara Graham profile image
DevRel at Wowza Media Systems. Tag Mod for #UX, #gamedev, #IBMWatson, #unity3d.