In reply to Jeff Chandler.

While it unfortunately started with the headline, these two comments are textbook examples of a false dichotomy.

Even if backwards compatibility were a sticking point (and I don't think it is), that's not a justification to not make an existing feature better. It's not going to be any more painful today to overhaul the customizer than it will be three years from now. Believing this is a bad assumption.

The customizer is incredibly well-designed from an architecture standpoint. It really is. It solved exactly the problem it was built to solve, and it does it really, truly well. It also did it to some fairly exacting design constraints. As a version 1, it needed to work perfectly with all themes out of the box. And to ease developers in, it needed to be primarily PHP-based. This was not our first modern foray into a JavaScript-heavy feature — for that, I'd go with distraction-free writing — but it was our first truly JavaScript-driven feature that developers would want and need to interact with. (This was before media, remember.)

But it still has a powerful JavaScript API under the hood, and that's an API that can only get stronger. A lot of the incremental improvements we're working on are also pretty low-level in terms of making it faster and more flexible. We've looked at all sorts of other improvements, and I'm not sure I've seen a single one ruled out as impossible. Well-designed features are great because it's easy to make major adjustments without a "clean break," even though you can end up with all of the benefits of such a move.