Love-Hate Relationship with Frameworks

There are some titanic-sized caveat that applies any time you start having the "there's a more direct way of doing this", or "this doesn't fit the framework" conversations.

Whether or not you agree with the philosophy of many of the existing frameworks, the people who are writing them develop, think, and live at a higher level of abstract thinking than most developers. If you look at the total pool of developer talent available, only a small portion ever write a successful framework? Why is that? Because writing a framework that is, at the same time, flexible, fast, and powerful is incredibly difficult.

I can't tell you how many times I've sat across from the table and listened to someone tell me how their problem doesn't fit pattern X. In most cases it's true there is a more direct way to accomplish a task, but patterns aren't designed to provide direct solutions, they're designed to structure your code in a way that makes it modular and easy to maintain.

When you deviate from the path, you better have a good reason, because you're often trading a lot of things that aren't immediately apparent: abstraction, consistency, maintainability, and portability.

When people start working around the public API by calling private methods it's because the framework is being used in a way that wasn't planned for. If we could adapt the public API to provide the required functionality then the framework would over time become more adaptable. The issue then becomes a social one, how to organise and consolidate the customisations that everyone makes. Github uses the forking and pull request functionality to address exactly this issue. It allows developers to maintain a version of a framework with their own customisations. Any of these customisations that would be useful to enough other developers can then be incorporated into the original framework.