Skip to Content

The unspoken problem with frameworks

The more I work with Zend Framework and other frameworks (Rails, CakePHP, etc.), the more I come to a realization that there is a hidden cost to using a framework. That's the time it takes to learn the framework, and the amount of work needed to do something relatively simple.

Sure, there are good points about frameworks - code reuse, flexibility, etc. And most times these points outweigh the downsides. Especially on larger applications.

Take a simple task for instance. Like reading configuration information that will later be used to connect to an LDAP server. The LDAP connection has it's own host of issues, but just getting the config info should be nice and quick. Read a file, parse the data, store it somewhere it can be accessed later.

Doing it by hand results in a handful of lines. But those handful of lines may be inflexible under different but similar situations.

Doing it within a frame work also results in a handful of lines. BUT, those lines are spread out over a number of files. And each file and/or line takes time to learn about. Sometimes only a moment or two, other times it could be days as other concepts and assumptions have to be researched as part of the whole package.

In theory, once you got the code working, you don't need to worry about it again. But update the Framework to a newer version and the application may very well break. The methods used may have changed. The function interfaces may have changed, etc. And before you know it, every file in your application needs attention just so you can use the most recent version of the framework. In some cases this is forced on you in terms of "critical security updates" - no developer *wants* to leave their code unsecured...

But this is the life of a developer - weighing the pros and cons of techniques, frameworks, libraries, and/or procedures against business/application needs and timelines.