YAML, better for configuration files than JSON

Many projects use JSON as a configuration file , the most obvious example is the npm and yarn use the package.json file . Of course, this is more because JSON and JS are inextricably linked.

However, JSON is actually a * * * very bad * * * configuration language. Don’t get me wrong , I actually like JSON . It’s a relatively flexible text format, easy for both machines and humans to read, and a very good format for exchanging and storing data. But as a configuration language, it has its shortcomings.

Problems with JSON

Lack of comments

Annotation is definitely an important feature for configuration languages. Annotations can be used to mark different configuration options, explain why a particular value is configured, and more importantly, to use different configurations for testing and debugging when you need to temporarily comment out part of the configuration. Of course, if you just use JSON as a data exchange format, then you do not need to use comments.

We can add comments to JSON in a number of ways. One common method is to use special keys in objects as comments, such as “//” or “__comment”. However, this syntax is not very readable, and in order to include multiple annotations in a single object, it is necessary to use a unique key for each annotation. If your application needs to use JSON for configuration, then that’s fine, but it does create some extra work.
Some JSON libraries allow comments to be used as input. For example, Ruby’s JSON module and enable the JsonParser.Feature.ALLOW_COMMENTS feature of the Java Jackson library can handle JavaScript-style comments . However, this is not the standard way, and many editors do not handle comments in JSON files correctly, making it more difficult to edit them.

Overly strict

The JSON specification is very strict, which is why it is so easy to implement a JSON parser, but in my opinion, it also affects readability and to a lesser extent writability.

Low signal to noise ratio

Compared with other configuration languages, JSON appears very noisy. JSON’s many punctuation does not help readability, in addition, the object is almost always a key is an identifier, so the quotation marks of the key is actually redundant.
In addition, JSON requires braces to surround the entire document, so JSON is a subset of JavaScript, and is used to define different objects when sending multiple objects in the stream. However, for configuration files, the outermost curly brackets are not really useful. Comma’s between key-value pairs are also unnecessary in configuration files. Usually, there is only one pair per line, so it makes sense to use line feeds as separators.
Speaking of commas, JSON doesn’t even allow them at the end. If you’re going to use a comma after each key-value pair, then you should at least accept the comma at the end, because it makes it easier to add new entries, and it’s also clearer when you do a commit diff.

Long strings

Another problem with JSON as a configuration format is that it doesn’t support multi-line strings. If you want to escape a string by a new line, you must use “\n”, or worse, if you want a string to be displayed on a separate line in the file, you’re out of luck. If you don’t have a long string in your configuration, then it’s not a problem. However, if your configuration entry includes long strings, such as project descriptions or GPG keys, you may not want to just use the “\n” escape instead of a real newline character.


The JSON specification defines a number as a finite floating-point number of arbitrary precision expressed in decimal. The JSON specification defines numbers as arbitrarily finite floating-point numbers expressed in decimal. However, if you need to use hexadecimal representation or to represent infinity or NaN equivalents, then TOML or YAML will handle them better. ``json { “name”: “rsshub”, “version”: “0.0.1”, “description”: “Make RSS Great Again!”, “description”: “Make RSS Great Again!”, “main”: “index.js”, “scripts”: { “start”: “node index.js”, “docs:dev”: “vuepress dev docs”, “docs:build”: “vuepress build docs”, “format”: “prettier "/. {js,json,md}" –write”, “lint”: “eslint "/.js" && prettier-check "**/. {js,json,md}"” }, “repository”: { “type”: “git”, “url”: “git+” }, “keywords”: [ “RSS” ], “gitHooks”: { “pre-commit”: “npm run lint” }, “author”: “DIYgod”, “license”: “MIT”, “bugs”: { “url”: “” }, “homepage”: “”, “devDependencies”: { “eslint”: “5.2.0”, “eslint-config-prettier”: “^2.9.0”, “eslint-plugin-prettier”: “^2.6.2”, “lint-staged”: “^7.2.0”, “Prettier”: “^1.13.7”, “prettier-check”: “^2.0.0”, “vuepress”: “0.13.0”, “yorkie”: “^1.0.3” }, “dependencies”: { “art-template”: “4.12.2”, “axios”: “0.18.0”, “axios-retry”: “3.1.1”, “cheerio”: “1.0.0-rc.2”, “co-redis”: “2.1.1”, “crypto”: “1.0.1”, “form-data”: “^2.3.2”, “git-rev-sync”: “1.12.0”, “googleapis”: “32.0.0”, “iconv-lite”: “0.4.23”, “json-bigint”: “0.3.0”, “koa”: “2.5.2”, “koa-favicon”: “2.0.1”, “koa-router”: “7.4.0”, “lru-cache”: “4.1.3”, “path-to-regexp”: “2.2.1”, “readall”: “1.0.0”, “redis”: “2.8.0”, “rss-parser”: “3.4.2”, “twit”: “2.2.11”, “winston”: “3.0.0” }, “engines”: { “node”: “>=8.0.0” } }

### What is YAML?
> YAML (YAML is not a markup language) is a very flexible format, almost a superset of JSON, and has been used in well-known projects such as Travis CI, Circle CI and AWS CloudFormation.
In addition to **support for comments**, **line breaks**, **multi-line strings**, **naked strings**, and **more flexible type systems**, YAML also supports **reference files** to avoid duplicate code.  
The main disadvantage of YAML is that the specification is very complex, and there may be inconsistencies between different implementations.  
It treats indentation as part of a strict syntax (similar to Python, Lua, etc.), which some people like and others don't. This can make copying and pasting very cumbersome.  
This can make copying and pasting very difficult.

# html lang
language: en
# main menu navigation
  Home: /about
  About: /about
  Archive: /archives
  Tags: /tags
# Miscelaneous
favicon: /favicon.ico
# stylesheets loaded in the <head>
- /css/style.css
# scripts loaded in the end of the body
- /js/script.js