Why You Should Build Your Own Darn Framework (Usually)

I've always been a big fan of writing my own website frameworks. It's how I learned to code, writing and re-writing a specialized PHP framework in an iterative, agile-like development process. There have been times when I've worked within standard systems (Zend, Code Ignitor, Wordpress, etc) but I try to avoid them on personal projects. PHP has a lot of flexibility in terms of allowing a developer set their own standards and I have a very unique style and approach to custom projects that I bring to my code. Also, I have some issues with using a pre-built framework.

Too Much Functionality

Some frameworks are very abstracted out with functionality for multiple data source drivers and DOM helpers (cough cough Zend). While it is impressive how much thought went into these large, comprehensive frameworks, there is often far too much logic there for a standard web project. As an example, one of the previous systems I worked with (heavy-traffic, front-facing site) was based off of the Zend Framework. Each page load included over 300 scripts and ate up over 10MB. While there are ways to optimize Zend, using it for something as simple as a small website was like using a cannon to kill a mosquito - massive overkill to achieve a simple goal.

Not Enough Functionality

This is not as big of an issue to me as having a feature-heavy application. It's always easier to add code to a framework, extending the functionality, than it is to attempt to remove core files in an attempt to optimize. My issue here revolves on how you functionality is added. Most modern frameworks have dandy items called 'modules' or 'plug-ins' that give you the ability to build off of the core system in a controlled manner. The problem arises when you start messing with the core to add functionality, disallowing you from updating the framework. Which leads to my next issue...

Security!

The best type of security is an invisible infrastructure. You never want to expose your backend code to an end user. Once they understand the backend, they can easily engineer methods of breaking in and performing unexpected events. Public frameworks are not invisible - for the most part, anyone can download them and look at the source! The only chance you have at keeping a popular framework protected is with frequent updates. Bugs and security flaws need to be addressed immediately, and good frameworks have dedicated individuals keeping an eye on problems and updating a central source. However, if you update the core manually you run the risk of getting your copy of the framework out of sync with the master. Then you have to choose if you want to skip the update, overwrite your custom code, or rewrite your code after an update.

Inhibiting Professional Growth

As I stated before, I learned how to program by building my own system from scratch. With a humble start in Dreamweaver templates, I bumped into PHP and started creating custom templates and data storage methods with each new project I came upon. In fact, it was a good year or two before I even started using databases to keep my information saved in a standard, concise manner. I learned how to write frameworks from a very practical, iterative viewpoint. When I started working for SparkNET, the team collaboration and strict standards only strengthened my existing, homegrown system.

Because I did not start with a normal framework, I was never held back by thoughts and biases that most frameworks are built upon. In fact, since I have built so many customized applications and worked with a variety of standard frameworks I feel relatively well-rounded and balanced when it comes to providing a good solution for different needs. I've worked with different developers who were so tuned into a single framework that they ended up doing three to four times as much work to create an application then was needed. If they had stepped back or had been willing to try something new (or even create their own solution), they would have saved time and learned a few more techniques for future projects.

When to Use a Framework

There are good times to utilize a framework. If you have a team of developers who are familiar with the same public framework, it may be more efficient to use it than reinvent the wheel. Time constraints or a rushed project may make it necessary to start with a base system. Also, you might have a specific project that just makes sense to build within a well-known framework. However, if you have sufficient time and a unique application to build, especially one that will have high amounts of customization, there is no excuse not to build your darn framework. You'll have the correct amount of functionality, better security, and most importantly, be able to push the application and yourself (or your development team) to new levels.