The problem with black-box programming is that it's a trap. Far more often than anyone cares to admit, the black box implements functionality in an unreliable or inefficient manner. When you're dealing with code that you wrote yourself, you can correct that behaviour of the "grey" box. But with a third-party black box, all you can do is file a bug report and hope that someone can not only replicate the problem, but that they'll give it high enough priority to fix it before you retire or your project is cancelled.
The worst culprit for black box problems are frameworks of all kinds. Some say you're not a "real programmer" until you've written your own framework. I firmly believe that's true, because what is a reusable code base on a large project except a custom framework?
The difference between a custom framework and an off-the-shelf one is that your custom framework is designed and coded with your project in mind, to service the bulk of your project's needs while maintaining enough flexibility to deal with the exceptional cases of your project. A third party black box framework is pretty much never designed that way. It was designed to serve the needs of someone else's conceptual or real project, then tweaked and adapted to serve needs it wasn't originally designed for, and finally unleashed on an unsuspecting world as "the next big thing."
A pox upon frameworks, I say. Design a solid object model, code to it, use it, and get over the fact that you're going to have to write some code.
At least if you wrote the code, you can fix it. Without worrying about whether some upstream integrator will deign to consider your "fix" worthy of integration to the mainstream code. Without having to wait for someone else to replicate, analyze, prioritize, schedule, implement, and test a fix for your problem.
Realistically, any half decent custom framework isn't going to be more than 10% of your total code base anyhow. "Framework" is just a fancy term for what was called for decades "application library."