On the use of frameworks. Good or bad?
Join the DZone community and get the full member experience.
Join For FreeBeing an admin on a programming forum I often encounter people who believe that using any kind of framework is pretty much damaging to someone’s abilities as a software developer – they believe that this makes the developer look “less professional”. Some people do indeed believe that everything should be written from scratch, with no components used from other sources than themselves.
Mostly, this is caused by an absolutely false stereotype – frameworks are like 1-2-3 – there is no “real” programming involved. The developers only get the needed building blocks, put them together and it all works just fine, right off the bat. As interesting as this idea might be, it is not even close to truth.
The fundamental concept of a framework is that it basically it is just a set of pre-made libraries, that don’t cut off the regular programming tasks. Frameworks have the capability to simplify things, and I admit the fact that using a framework for desktop development, for example, instead of native programming can be easier, but once again, “easy” is a very blurry term and it varies from person to person. For example, you can write your own class to read XML files, parse through them and detect needed information. It is an interesting task and it is not that simple as it might seem. However, you can use a class that was integrated in a framework that does this thing for you. Now you could say – well this is exactly the point – developers who are just using pre-compiled components pretty much make themselves unaware of the actual process lying behind that library. Partially, I could agree with this. However, using a pre-made library lets the developer focus on the actual application rather than on some of the (somewhat) routine tasks. If we are talking about an experienced developer, then even with a framework being used he still understands the logic behind the method calls and if needed, will be able to implement similar functionality, and I am not talking about code monkeys here (the guys that write code without actually understanding its logic).
Using a framework doesn’t mean that no programming is required to build a working solution. It’s the complete opposite of that – frameworks require some additional knowledge on top of existing programming skills, since the developer needs to adapt existing functionality to fit a situation.
One of the skills that is very important for developers is the ability to reuse the things that have been tested and proven as working well in various situations. This means, that once such a component is present, the developer knows how to integrate it in the core of the existing (or planned) solution. This doesn’t necessarily mean that that component is developed by a third-party. It can be developed by the programmer himself, however the framework plays exactly the same role – it integrates the most useful components and allows the developers to reuse them.
Usually, people stating that frameworks make programmers “less professional” and programmers who write everything from scratch are “more professional” have little or no understanding of what programming is at its core. If you think about it, developers were using frameworks ever since first high-level programming languages appeared, although those can’t be compared functionality-wise to what there is now on the market. Developers who write native applications still use various libraries to interact with the system. That is a somewhat limited and very specialized framework, since it is bound to a specific system and/or configuration. However, the concept is the same. Today, if the developer is using any language, he is basically using a subset of libraries (a framework) bundled with the language. Therefore the argument becomes irrelevant.
The libraries that are bundled with modern frameworks (and it doesn’t matter whether it is a web or client framework) have a generalized purpose and tend to include some functionality that is as abstract as possible, therefore giving freedom to expand on them and build tasks applications with a broader platform/tool choice, not limited to only one project.
A major concern of some people can be the possibility of framework bugs, those that are not under direct control of the developer. There have been cases, when frameworks with a very limited user base contained bugs that appeared several years later after the application was published (looking at early 90s when frameworks weren’t really what we call them now). Today, there is still such a risk and bugs are still discovered. However, due to the fact that today major frameworks are extensively tested, constantly improved and have major user bases, these risks are reduced to the minimal possible, and if found, the fixes appear pretty fast.
A framework is not detrimental to programming skills, as long as the developer knows when and where to use and not just try to find ready-to-go solutions to be packed into the app.
Mostly, this is caused by an absolutely false stereotype – frameworks are like 1-2-3 – there is no “real” programming involved. The developers only get the needed building blocks, put them together and it all works just fine, right off the bat. As interesting as this idea might be, it is not even close to truth.
The fundamental concept of a framework is that it basically it is just a set of pre-made libraries, that don’t cut off the regular programming tasks. Frameworks have the capability to simplify things, and I admit the fact that using a framework for desktop development, for example, instead of native programming can be easier, but once again, “easy” is a very blurry term and it varies from person to person. For example, you can write your own class to read XML files, parse through them and detect needed information. It is an interesting task and it is not that simple as it might seem. However, you can use a class that was integrated in a framework that does this thing for you. Now you could say – well this is exactly the point – developers who are just using pre-compiled components pretty much make themselves unaware of the actual process lying behind that library. Partially, I could agree with this. However, using a pre-made library lets the developer focus on the actual application rather than on some of the (somewhat) routine tasks. If we are talking about an experienced developer, then even with a framework being used he still understands the logic behind the method calls and if needed, will be able to implement similar functionality, and I am not talking about code monkeys here (the guys that write code without actually understanding its logic).
Using a framework doesn’t mean that no programming is required to build a working solution. It’s the complete opposite of that – frameworks require some additional knowledge on top of existing programming skills, since the developer needs to adapt existing functionality to fit a situation.
One of the skills that is very important for developers is the ability to reuse the things that have been tested and proven as working well in various situations. This means, that once such a component is present, the developer knows how to integrate it in the core of the existing (or planned) solution. This doesn’t necessarily mean that that component is developed by a third-party. It can be developed by the programmer himself, however the framework plays exactly the same role – it integrates the most useful components and allows the developers to reuse them.
Usually, people stating that frameworks make programmers “less professional” and programmers who write everything from scratch are “more professional” have little or no understanding of what programming is at its core. If you think about it, developers were using frameworks ever since first high-level programming languages appeared, although those can’t be compared functionality-wise to what there is now on the market. Developers who write native applications still use various libraries to interact with the system. That is a somewhat limited and very specialized framework, since it is bound to a specific system and/or configuration. However, the concept is the same. Today, if the developer is using any language, he is basically using a subset of libraries (a framework) bundled with the language. Therefore the argument becomes irrelevant.
The libraries that are bundled with modern frameworks (and it doesn’t matter whether it is a web or client framework) have a generalized purpose and tend to include some functionality that is as abstract as possible, therefore giving freedom to expand on them and build tasks applications with a broader platform/tool choice, not limited to only one project.
A major concern of some people can be the possibility of framework bugs, those that are not under direct control of the developer. There have been cases, when frameworks with a very limited user base contained bugs that appeared several years later after the application was published (looking at early 90s when frameworks weren’t really what we call them now). Today, there is still such a risk and bugs are still discovered. However, due to the fact that today major frameworks are extensively tested, constantly improved and have major user bases, these risks are reduced to the minimal possible, and if found, the fixes appear pretty fast.
A framework is not detrimental to programming skills, as long as the developer knows when and where to use and not just try to find ready-to-go solutions to be packed into the app.
Framework
dev
Opinions expressed by DZone contributors are their own.
Comments