Last week we talked about application shelf life an aspect of PHP development that often goes overlooked. This week let’s talk about how the web development framework you use contributes to the shelf life of your app and the profitability of your web application.

Photo provided by Jonas Bengtsson

Why use a framework in the first place?

PHP, as a language, is pretty strong language for web development right out of the box. Other languages like Python, Perl, and Ruby were designed for more general scripting, and not specifically for building web apps. When people started using these scripting languages for web development it quickly became obvious that there were certain things that all web apps would need to be able to do like managing sessions, routing, connecting to databases, etc. Having a toolbox of tricks ready to go greatly speeds up development. Thus, the dawn of web development frameworks.

The main goal of all web frameworks is to improve the developer’s ability to get ordinary things done so we can focus on the primary goals of what we’re building.

Why so many frameworks?

The reason we have so many frameworks to pick from – especially in the PHP community – is because lots of people have different ideas on where to draw the line between framework and the actual application logic. We’ve got huge frameworks like, Laravel, Cake PHP, medium sized frameworks like CodeIgniter and Kohana and small / micro frameworks such as the Fat Free Framework.

Standard trade-off argument: learning curve vs efficiency

On the surface, when you start looking into web frameworks, the general understanding is that the larger frameworks like Laravel – complete with code generators, unit testing, etc. – has a meaningful learning curve, but once you learn it you are really efficient as a developer. For example, boilerplate stuff that you normally have to type up can be auto-generated for you with quick command line scripts. It might take a month of regular use or more to really understand and master a large web development framework, but once you learn it, you can be really efficient as a developer.

On the other end of the spectrum is the case for The no-framework PHP framework. The idea being that PHP, without any additional layers of abstraction, is all you need to build MVC apps. Using this approach you will have a lean app that only includes what you need; free from all of the cool (but not needed) features of larger frameworks. While this is certainly possible, if you always start your apps totally from scratch with no frameworks or libraries you are going to find yourself re-implementing a lot of things over and over every time you build an app.

Among developers, the popular trend seems to be in favor of the first approach. Spend the time upfront to learn the framework, then enjoy the ride. Find a comprehensive, general purpose framework like Laravel (or Ruby on Rails) learn it, use if for everything you ever work on, and enjoy all the efficiencies that come along with the package. But I suggest:

[Tweet “There’s much more to a successful app than a fancy framework”]

Clients can get hurt by large frameworks

A couple years ago we were about to start development on a fairly good sized project and I wanted to give Laravel a try. I heard a lot about how nice the framework was and I was ready to start up a brand new project. The problem was it was just before the release of Laravel 4. I was reading about all the great new enhancements to the framework and how v4 was a dramatic improvement over v3. I really wanted to use v4 but it wasn’t ready. I also knew that if I built on v3 there would be a meaningful upgrade process to start using v4 once it was released. So, what do you do? Ask your client to wait on their project while we wait for the latest enhancement to our favored framework to go live?

This is another example of how large frameworks shorten the shelf-life of your application. Suppose we had built the app on v3 and handed the project over to the client, then next year they want some enhancements done. Now we’ve got the following problems to deal with:

• Find developers still familiar with the old version of the framework
• Spend time / money upgrading the framework (for no new end user features)
• or… Stick with the old framework and try to find old versions of other packages you might be using through composer.
• Eventually the old version will stop being supported and security becomes an issue

If you are the consultant building this app, you’re going to need to explain to your client why they need to spend money to rework stuff under the hood for no end user value. Then you need to explain why you caged them into this problem.

Ripped up and ripped off

One approach that tends to happen is that the developers find that it’s too tedious and expensive to migrate a large app onto a whole new version of the framework. Instead, they just rip out the parts of the project that need updating and roll their own solution. The end result is a hacked up mess of home grown updates woven into an outdated web framework. Furthermore, the problem is compounded because now it is even harder, basically impossible, to upgrade to the latest version of the framework. The code base gets ripped up and the client feels ripped off.

So beware, somebody will probably end up eating the cost of using a large framework by either having to go through a comprehensive upgrade and testing cycle at your own expense or by losing productivity working in an old and outdated framework.

[Tweet “Upfront productivity vs. Long-term maintenance costs. #PHP #Frameworks”]

The irony of large frameworks

It is common to hear that if you’re just building a small app then you can use a small framework. But if you’re going to build a large app then you really need a robust framework that can really take care of all the things you need to tackle. The problem is that the bigger the app is the more difficult it is to migrate to new versions of your framework. In practice, you are likely to find that you have to pick the latest version of a framework when you start building the app, and then that’s just what you have… Forever.

[Tweet “Large frameworks are one of the most limiting factors of large apps as they age. #ironic”]

As your app ages, the framework you picked to save you time and money up front may be the most limiting feature of your app.

Small and modular wins the race

The solution we have adopted for the last three large apps we’ve built is to use a small framework that can elegantly handle the bare-bones basic stuff like routing, views and templates, and a simple ORM. Then pull in a handful of packages from composer for things like database migration management and background jobs. The end result is a very lean app that only has code for things we actually need and use.

Fat Free Framework

Back in the summer of 2011 I wrote a review of PHP Frameworks and why we picked the Fat Free Framework. All of those reasons still apply today. The philosophy of the Fat Free Framework is stated nicely on their site saying:

The philosophy behind the framework and its approach to software architecture is towards minimalism in structural components, avoiding application complexity and striking a balance between code elegance, application performance and programmer productivity.

Keys to working with small PHP frameworks

When you pick a small PHP framework there are a few challenges to overcome, especially if you are working in a team.

Establish a structure for your app

The main issue is that the framework doesn’t have any built in organization for structuring your app. This is great because it let’s you set things up the way you need / want, but it’s also a challenge to make sure all of your team members know where to put their code and how to wire things up.

Adhere to a coding standard

While larger frameworks might already have a set of coding standards in place, when you build on top of a micro-framework you are relatively free to set your own standards. It doesn’t so much matter what standard you pick, but you do want everyone on your development team to have the same style. Our internal policy is to adhere to the PSR-2 coding style. While PSR-2 is a very popular and clean coding style, it’s certainly not the only one. For example, if you do a lot of WordPress development you may want to review the WordPress PHP Coding Style Guide.

Find common packages

While you are always free to change and upgrade the packages you use, it is generally helpful if you can keep a core set of common packages in place for all your apps. For example, managing database migrations. We use phinx. It’s been really nice for us, it’s entirely separate and independent from Fat Free Framework so upgrading Phinx has no impact at all on our production app in terms of having to upgrade our web framework. It’s a really nice package for managing changes to your database. We install Phinx into our app via composer, and everything works great. There is no point in constantly asking your development team to learn new packages if they don’t need to. So establishing a standard set of “go to” packages for common things has been helpful.

Build your own library

There have been a few things we have commonly needed in our F3 (Fat Free Framework) apps that are not part of the framework. For example, we have a BaseController class that we extend for all of our controllers. We have an AuthController that extends the BaseController for use when authentication is required to access a resource. We have a Navigation Menu and Menu Items for being able to manipulate the navigation or our apps dynamically – like based on the level of access a user has. We have a handful of other common classes as well. These are relatively simple, home grown classes that we can maintain and enhance as needed.

Conclusion

There are certainly pros and cons to frameworks, not matter which one you choose. We have discussed the issues we’ve faced with large frameworks, how large frameworks can end up costing big dollars over time, and how we were able to overcome many of these issues by using a small framework, composer packages, and our own home grown library. Hopefully it was interesting for you. If so, please share it with your friends. If you have any questions or want to dig deeper, please leave a comment and we’ll talk more. Thanks for reading 🙂