In reply to Andreas Nurbo.

@andreas: I haven't written a single line of javascript for my Customizer API implementation. It isn't required.

And keep in mind: Settings API and Customizer API are both used to expose settings to the end user for configuration. Options API and Theme Mods API are both used to store/retrieve settings to/from the database.

The Customizer API can be used with either the Options API or the Theme Mods API, with equal ease. You literally change one key in the $wp_customize->add_setting() args array, to change from the default (Theme Mods API) to the Options API. Everything else works exactly the same. But the Customizer API is much simpler out of the box, because unlike the Settings API, the Customizer API at least has the basic, most-used controls already in the API, and sanitizing is actually much simpler (and easier to follow/understand).

With the Settings API, you have to register the settings page, make sure user capabilities are correct, then build out the settings fields (with custom markup, because the API doesn't provide any of them), then configure the form submission, then build out the sanitization/validation callback.

The Customizer API cuts that work by at least half.