JSON is often hand-authored as small config formats (in which your use-case (a) is relevant*), but I have never seen it hand-authored for readable "content". F

JSON is often hand-authored as small config formats (in which your use-case (a) is relevant*), but I have never seen it hand-authored for readable "content". Firstly longform content is often rich-text; if that's hand-authored in something that's not a wysiwyg UI, it's typically a dedicated separate file (.html or .md) which may-or-may not be later programmatically compiled to JSON. For longform content that's not rich-text, and doesn't warrant a separate dedicated .txt file: how long is it? Do you really need multiline strings? The only real use-case I've seen is i18n string map files, where some translations can contain a newline or two, but these are an exception; the majority of strings in those files are short. ---- * On use-case (a), this is a personal preference but I tend to prefer referencing single independent executables in these use-cases, to the modern trend of having long unreadable bash one-liners in config files.