"Too much magic"? That sounds more like a lack of understanding than anything else. There's no magic. The primary purpose of frameworks is to remove boilerplat

"Too much magic"? That sounds more like a lack of understanding than anything else. There's no magic. The primary purpose of frameworks is to remove boilerplate and allow the developer to focus on what's actually important. There are many routes to this: convention, introspection, etc. The whole point of a framework is to appear "magical", but it's still just code, and ultimately, generally easy to pick apart how it does its magic. I'd even argue that gaining that understanding, and the ability to discover that understanding, is far more important than any particular framework: the understanding drives the ability to both make use of whatever framework you're investigating, but more interestingly, to apply that knowledge across frameworks and domains. If you want to "leapfrog" relatively "static" frameworks, you must understand how "magic" is constructed and utilized, and make use of it. At that point you might as well be using the framework. Leapfrogging demands new knowledge and new comfort levels.