Hacker News Reader

Comment by Alex3917 | Hacker News Reader

With YAML I can never remember what's an object versus a list, string, or number, nor am I ever able to add new stuff to a YAML file and get it to parse correctly without first looking up the spec. And it's impossible to see where large objects start and end.

In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trailing comma.

The only good thing I can see about YAML is that it's super easy to convert and re-export to JSON.

View on HN

> In contrast, JSON is super intuitive and basically self documenting. The only real quirks are that you need to use double quotes, and objects can't have a trailing comma.

I'd expand the list of quirks... JSON lacks comments (both line-level and block level). Fine for data transport but super super bad for configuration files.

This hits home. Every time I've ever had to make the decision I've chosen yaml, for exactly this reason. Funny how the seemingly small things can be absolute show stoppers when it comes to making decisions in production.

In our JSON config files we do:

{ "ConfigKeyComment": "This is for blah blah blah", "ConfigKey": "Foo" }

Obviously this wouldn't work in all cases (you're putting more work on your parser to interpret unused keys basically), but if we're talking config files specifically, I see this as an acceptable approach since there's little chance you'll be parsing such files more than once each (plus, writing a simple tool to strip the comments out would be very trivial).

I've tried something similar but found it way too painful if the comments need to be long...

    # Never enable this config, because if you do the space-time
    # continuum will collapse into itself and the cloud servers
    # will disappear in a puff of steam. However, if you really
    # must enable it, remember that it's boolean and go read
    # TICKET-8675309 for the extensive list of side effects.
    TurboFactorRenoberation = false

...so people just end up writing stuff like:

    {
        "ConfigKeyComment": "TICKET-8675309",
        "ConfigKey": "TurboFactorRenoberation",
        "ConfigVal": false
    }

[edit]: formatting

That's not JSON anymore, that's pretty much enough to be considered a unique DSL. Scary that this is more or less required.

Almost all applications evolve their config files into unique DSLs over time. They may choose a generic serialization for the DSL's AST but it will end up being an underspecified application specific DSL regardless.

Interesting approach.

Maybe I'm lazy but avoiding increasing cost to commenting is one of the few absolutes I abide by. Often I find myself tired after a long stretch of code, trying to convince myself that's it's understandable on it's own.

This is one of those systematic rules I have to enforce to shutdown my lazy lizard brain.

edit: But I can see how highly structured comments could actually come in handy as well for viewing configs in a gui

>Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

-Douglas Crockford, creator of JSON

There is no issue using JSON with comments for a config file.

Or pipe through json5 which has other conveniences one might want like trailing commas.

I love json5, but it's not always an option.

Yes, but ITT we're talking about someone apparently having the option to pick which format they're using for config, and they'd use JSON if it wasn't for one dealbreaker.

Yes, except for the fact that ECMAScript has a syntax for comments, but not JSON. Standards matter.

Blurg, now every tooling pipeline that uses JSON needs to include a JSMin step...

If you're making comments for yourself in config files you control:

/\/\/.*/gm

https://regexr.com/3rbgb

"hello // syntax error"

You are 100% correct. For not single line comments, "//" in the datastructure, and everything else there are already well tested solutions for the problem. https://github.com/sindresorhus/strip-json-comments

My point is only that this isn't a big issue. I don't understand why so many see it as a large issue. Instead, projects use non-standard YAML or other problematic solutions only because "JSON doesn't have comments".

JSON5 supports comments, and is only slightly more complex than JSON. https://json5.org/

Most parsers will not support JSON5.

More like browsers can de-serialize JSON5 natively. writing a JSON5 parser is not difficult. It's just not part of most std libs in most languages, but I would argue that most std libs don't parse YAML either.

JSON5 is a good compromise.

Neither Chrome nor Firefox's JSON.parse accept JSON5. I'm not sure what browser API you mean.

For example,

  JSON.parse(`{"foo":"bar",}`)

throws a syntax error.

> Neither Chrome nor Firefox's JSON.parse accept JSON5. I'm not sure what browser API you mean.

This is a typo, I meant "can't" not "can". Off course browsers don't support JSON5 or my message makes no sense whatsoever.

The barrier here would be whether there's support in enough implementations to feel safe using it in the wild, which I'm guessing will take a while at the very least.

What’s incredible here is that we’re not at the beginning of programming, when we built temporary languages that ended up becoming forgotten. Web may be a final form of IT, Angular may be the « right », the final, the perfect way to build applications even in 50 years, just like HTML has become the final way to build websites for the last 25 years, JSON may make legacy, and my grandson might even struggle with parsers that still use JSON instead of this new tech called JSON5...

The popularity of transpilers might help overcome that barrier. IDE's and task runners can watch for file modifications and run a simple program to convert to the old format.

But I'm curious what you mean by "in the wild"? If you're using (producing) it, something needs to consume it, and you would probably have control over both in whatever project you were using it for.

If you're going to do this kind of thing why would you not add a standard date format

Just use a string and ISO 8601? “2018-03-25”

What's the timezone?

Do you need a time zone for dates?

Consider if I'm storing a user's (local) birthday on my server:

    {..., "birthday": "2018-03-25"}

If my server is located in New York City, and the user is in Sydney, then my server isn't going to wish them happy birthday in time.

So maybe we could do:

    {..., "birthday": "2018-03-25", "location": "Sydney/AU"}

But at this point we might as well use a standardized time format (UTC) with a timezone offset. Maybe I'm thinking too far into it?

ISO 8601 has you covered:

   Year:
      YYYY (eg 1997)
   Year and month:
      YYYY-MM (eg 1997-07)
   Complete date:
      YYYY-MM-DD (eg 1997-07-16)
   Complete date plus hours and minutes:
      YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)
   Complete date plus hours, minutes and seconds:
      YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)
   Complete date plus hours, minutes, seconds and a decimal fraction of a second
      YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)
  where:

     YYYY = four-digit year
     MM   = two-digit month (01=January, etc.)
     DD   = two-digit day of month (01 through 31)
     hh   = two digits of hour (00 through 23) (am/pm NOT allowed)
     mm   = two digits of minute (00 through 59)
     ss   = two digits of second (00 through 59)
     s    = one or more digits representing a decimal fraction of a second
     TZD  = time zone designator (Z or +hh:mm or -hh:mm)

Wow, I can "just" use that, thanks. The problem is that JSON is an interchange format, meaning that I need to implement this serialization and deserialization quirk on every producer/consumer of my API (which, you know, avoiding is kind of the point of using a standard interchange format). Furthermore, because everything is a string, I can't unambiguously indicate something is meant to be a string in that format rather than a date.

The lack of template string support is a weird part of that.

JSON lacks comments (both line-level and block level)

    “_comment”: “blah blah blah”,

Simples

That doesn't work if you use a strict parser where superfluous fields are an error. It's quite rare, but there are good use cases for that kind of strictness.

Or when no fields are superfluous. For instance, when the code iterates over all the fields and does something with each, instead of just looking for known keys.

Or when the place you need to put the comment doesn't happen to be inside an object literal.

This is ugly.

> lacks comments [..] super super bad for configuration files

Not that that matters when applications take it upon themselves to re-save the config file in some kind of normalisation effort. Bye-bye comments, hope they're checked in somewhere.

I'm lookin' at you, kubernetes...

In contrast, JSON is super intuitive and basically self documenting.

Personally I've found the exact opposite when dealing with 'normal' people. Most people can get basic YAML, but unless they're a programmers (or at least know how to program) most people fail miserably at writing JSON by hand.

I agree with this. Our biz guys have to edit JSON config files regularly, and they're limited to basically just copying/pasting lines from existing files and editing the values. When they need to be able to do more, we end up building a UI for it and either storing the config elsewhere or writing the code to manage persisting their changes to the config.

See how much fun these people have trying to figure out why their application crashes because they put a tab instead of spaces into the YAML file.

We use a YAML linter before attempting to load the file. Provides detailed feedback to the user: "Tab found at line 17, column 23"

Also detects repeated hash keys. This is a very good compromise between user-friendliness and machine-friendly specification and serialization.

Thank you very much for YAML! It is a critical user-interceptable interchange mechanism at several companies that I have worked at.

JSON has too many rules regarding comma placement.

> objects can't have a trailing comma

This has caused me so much misery in the past, especially since none of the tools will tell you which line the offending comma is on. Great, somewhere in my thousand-plus-line JSON file is a tiny syntax error but you won't tell me where.

Ended up having to regex for them. Didn't do wonders for my trust in JS tooling.

From the command line:

    python -m json.tool < somefile.json

This will tell you where your file is messed up.

There is also https://github.com/zaach/jsonlint

Thanks for the tip :)

https://json5.org/

You use JavaScript a lot more than python, right?

Intuitive usually means "close to what I'm used to".

I actually use Python a lot more than Javascript. That's why the double quotes and the no trailing comma are always what get me.

Especially since leaving the trailing comma is considered the best practice in every other language.

JS added support for a trailing comma, and single-vs-double quote is a contentious topic in Python land!

Python dicts are a lot closer to JSON than YAML.

The real schism here, IMO, is Programmer Intuitive vs. Natural Language Intuitive.

Second this. I have used Python dict to write the default config file and JSON Schema to validate a user-supplied config file, which worked quite well in regard of that purpose.

Python objects and JSON are practically identical.

In what sense could this be true? Python objects support a whole host of behavior; JSON is a data format. Python dicts might be a closer analogy except Python keys can be anything that is hashable while JSON requires strings, and of course Python dict values can be any Python value; not just the JSON analogs.

I think you are purposely mis-interpreting me. Python dicts are practically, syntactically identical to JSON. Yes, python dict values can be any python value the same way JSON in JS can be any JS value. Point being, someone coming from python would see JSON as identical to a python dict. We can run around in semantic circles all day.

> I think you are purposely mis-interpreting me.

You misrepresented yourself by saying "object" when you meant "dict" and saying "practically identical" when you meant "vaguely syntactically similar". I wasn't trying to nitpick your semantics; I just had no idea that "Python objects are practically identical to JSON" meant "Python dicts are to Python what JSON objects are to JS, oh and also Python dicts have some syntactic similarlities to JSON" or whatever.

You sure are difficult. There is a non-trivial set of text that is both valid JSON and a valid python dict. Many people would consider the two very similar.

Reply on news.ycombinator.com