The argument that most companies provide for using a specific framework is usually the following: Companies, especially corporates typically argue that using popular frameworks is useful because everyone knows how to use them. However, getting stuck in a specific framework has very real drawbacks.
The first drawback can be described as a framework limitation. When a framework limitation occurs , developers usually end up hacking the framework or seek to integrate other frameworks into the system. Usually these frameworks are not intended to work with the framework that they are being paired with . This is especially the case with backend frameworks and the more frameworks that you introduce, the harder it is to patch vulnerabilities
So what is the solution? Well, it is quite simply really. Produce ANSI standard code and comment as much as possible. ANSI Standard code is built into the .net framework from Microsoft. Microsoft has always used the ANSI standard for nesting and their IDE actually provides you with visual indicators for this.
Use several Specific Task Frameworks and classes to achieve a specific goal that does not result in your backend environment becoming to deeply integrated with your application.
With MVC Backend frameworks this is the specific case. Fortunately we have PHP. Standard PHP can be extended using pecl or composer classes. Unlike node.js or other backend frameworks that integrate heavily into your environment and possible also act as web servers themselves in certain cases, PHP can be easily replicated on other servers without much difficulty as the environment is standard.
Developers discovered this quite quickly when developing backend frameworks. They sought to produce what I consider to be a band aid patch in the form of software that creates portable environments that can move the entire server to a new location and keep it intact. They also allow users to download entire environments with the integrated platforms for use on virtual machines and other…Unfortunately, this makes building your applications even more complex and the time that you use setting up these portable environments, configuring them and writing compliant code simply results in time lost in productivity and overly complex integrations with other applications.
This is the reason why that when I build an application, I try to keep the environment as simple & clean as possible , often altering only a few default settings and trying to write code as close to the default language as possible.
In the early nineties conventions were set up which are universal and are still used religiously today in order to structure applications and code in a way that it is logical and can be easily followed. The idea that using a GP framework is the only way to produce productive code is not only false but counter intuitive. The larger the framework, the more code you end up writing and the more complex the environment becomes in regards to backend programming.
Furthermore, when using GP frameworks you end up losing performance, executing code that does not need to be executed at runtime and when you upgrade the framework for security purposes you end up having to rewrite code which is lost during the update.
Another band aid patch is then put in place to help developers to retain as much of their old code as possible and buy them time to change it. This is the silly method of retaining commonly used code from the previous framework and deprecating it over a period of time (over several updates) while insisting that the developers use the new methods.
This causes bugs, forces the developer to continuously check the integrity of their code. Websites break if code has been missed by the developer and this causes further bloat that affects performance, pushing up maintenance costs for the client
This is why our moto is “horses for courses”. You should only be executing the code that does a specific function without having to switch off the other bulk for performance purposes.
Every tweak that you have to make for a GP framework (of which there are many) reduces productivity and increases the cost for the client.
This is why I use specific Task frameworks such as WordPress which does not integrate into you environment and while they share commonalities with GP frameworks, they are built to be portable and run on a default LAMP stack. The standard PHP stack that forms the basis of all PHP installations.
There is one interesting GP framework out there that I do like and that is codeigniter. It is a powerful framework that has a lot of commonality with wordpress in regards to portability and simplicity. However, wordpress is more then just a framework as it is also an application which has 1000’s of free and premium extensions that can be modified by you, the developer.
One might ask the question, well if it has all been built then it is not innovation…Well, General Purpose frameworks are not innovative by nature. The provide only industry standard compliant code.
That argument in itself is counterintuitive and should give you even more motivation to move on from them.
Complex environments are actually harder to maintain and to follow when new developers join the ranks and the old developers leave.
Some frameworks are simply not compatible with certain GP frameworks especially if these frameworks are “tightly coupled” which effectively is a term that means restrictive.
You cannot easily innovate with a General Purpose framework as they are built to industry standard for handling common tasks. You will be winning very few awards for your software when using a General Purpose (GP) backend framework.
In order to use a General Purpose framework, you need to learn the core language first, thus by studying multiple Specific Task frameworks, thereafter, you simplify your work load for any developer that follows in your footsteps… as all developers using the language of your framework know how to write that language.