Is this even a debate anymore???
I remember in 2012 whilst working for a online media company this question was asked. They’d been operating a PHP based website for a couple of years which was built from the ground up using OO concepts and a proprietary framework designed and built by the then tech lead.
For months we’d be struggling to deliver a few big features as well as maintaining the website and patching up known issues. It was easy to see that delivery wasn’t streamlined enough and that this was causing bottlenecks to the business’ operations so as expected we were asked to produce an analysis and provide solutions. One of these solutions on paper was to move the entire application onto a framework at which time the top three were Zend Framework, CodeIgniter and WordPress. Our analysis bore a number of pros and some cons in regards to moving to a framework including the following.
Speed of delivery:
PHP Frameworks are made up of a collection of finely tested, modularised and standards-compliant components which can be re-used in any number of projects regardless of project type. This means that for every new project you can include these components or reuse these components for any new feature which requires it.
Why re-invent the wheel? Even if you think your wheel is better, these existing wheels have been written, reviewed and tested by scores of developers and have more interest and eyes watching than your component ever will – and that’s a good thing.
PHP is still the most widely used programming language for websites, and as such, has a huge developer community behind it. Frameworks also have a large community following since, as a developer, you’d only ever tend to choose one or two frameworks to see through to mastery. One of the benefits of using a PHP framework to support or develop your application is that automatically gain the support of the community. Basically a widespread group of fussy, nit-picking, smart, collaborative and inspired individual who pay great attention to detail and ensure that the components you use are fit for purpose. The community will also move to improving and keeping components up-to-date as time goes by and with so many people using these components, any issues or bugs will be reported and resolved quickly.
Security (Regular updates):
Frameworks will strive to stay relevant by ensuring that components are well maintained and that any issues are fixed promptly and bugs squashed immediately. Another top-priority focus for frameworks is security. Ok-features that have tight security are awesome whilst awesome features with poor security are a complete waste of time! Frameworks also tend to do a good job of keeping in sync with programming language updates and other technological advancements so that you don’t have to. This includes security patching and implementing newer security measures where possible. Because this is a focus of the framework, you have a lot less work to do. Aside from ensuring that the framework covers all your key security requirements, you’re good to go.
In any given application you can expect a lot of under-the-hood features that not only deal with what your user sees and does, but also keeps things operational and secure in the background. As a developer you can’t just focus on the feature that has been requested – there are other considerations that have to been taken such as “how will this feature be maintained”, “which background processes should be associated with this feature”, and “what will ensure that this feature is working the way it has to”? These considerations can add a lot of scope to a feature and then the thing you expected to take a short amount of time suddenly becomes more of an epic than a feature. This type of thing is very common and it introduces a lot of complexity to a project. However, with a framework a lot of these considerations have been taken and the solutions for these are baked in to the features/components of the framework thus removing a lot of the complexity from your project. Also the way that components or ‘modules’ if you will, are kept inside frameworks are well separated and modular, therefore keeping things tidy, extendable and maintainable.
Standards are a way that programming languages enforce control, consistency, maintainability, security and quality. Standards kind of allow a shared expectation experience for development groups and communities. They set a base-level for code readability and approaches to writing code. For PHP the governing body for standards production and maintenance is the PHP-FIG group. Although these standards are more recommendations than hard-rules, they’ve been thought about, tested and unanimously agreed on by groups of established PHP projects and renowned experts. Because of this, existing and new (Framework) projects see the importance of these standards and adhere to them, ensuring that they reap the full benefits of taking the recommended actions as will their users. It takes a lot more effort and time to ensure that code is standards compliant so if you are building and maintaining your own proprietary framework this is one important aspect that sadly is often overlooked. Using a framework removes the need to do this yourself. Also, working with a framework that is highly standards compliant also improves your knowledge and ability as a developer.
How about updating an existing project to use a framework!?
Now lets talk about upgrading an existing application to use a framework. In my own PHP career this has rarely been a requirement; Migrating a non-framework based application or one that uses a custom built framework to a community backed one like Symfony or Laminas?! No, rather what I have come across more often is migrating an application that uses some individual components from a framework to use more or all of that framework in order to improve the codebase and take advantage of the support gained. There is also upgrading an old unmaintained version of a framework based app to use a newer version or migrating away from one framework to a better one. Either way the follow considerations are required:
- Cost/time requirements to do the migration – Migrating to a framework is no easy task. it takes time and money and expertise. You should fully understand how much this will cost to implement and maintain moving forward before doing it.
- Benefits of migrating to the Framework – Are your expected benefits in the list above? Will reducing technical debt ensure that the business operation continues with minimal interruption and risk? You should know and understand the benefits thorough before committing to this.
- Business objectives and direction – Sometimes as devs we lack business understanding. What is important for us may not be that important for the business. What this means is that regardless of what benefits may be gained from migration to a top framework, the business may just have a different direction in mind. Little can be done about this but it’s important to understand it.
- Risk assessment – This goes hand-in-hand with understanding the benefits. You also have to understand the risks. For example moving to a top framework without the long expertise require to maintain or work on it is pointless. How about if the framework is costly to maintain? How much does it cost in developer terms to work on this particular framework compared to what we have? Will it break the bank?
Be it a new application that you are building or an old one that you are thinking of migrating, the benefits of utilising a framework like Symfony has benefits that far outweigh the cons. However, that is predominantly and technical viewpoint. There is also a commercial and business viewpoint to consider. That being said I think it’s safe to say that we’ve reached an age where no one should be building each module or component of their application from scratch. The time, cost and security risks of doing so far outweigh the of using a community project (if selected with care). Anyway as always the answer lies with you. Think carefully and do you own assessment before jumping in. I’m sure everything will pan out went.