Frameworks are essential tools for building modern and scalable applications. They offer a set of features and software standards that make development easier, allowing developers to worry about code structure. Furthermore, frameworks are frequently updated to incorporate the latest trends and technologies, which means that applications built use tools with greater resistance to the most robust and secure.
Programming an app these days without using a framework would be like a house without using a beam support system. You can do that, but it's much more difficult and risky, and a house will likely not be built to the standards and features of a framework.
Every major developing language has a set of frameworks available, each with different features. The most popular framework for Python is Django, for example and you probably already heard about JavaScript's more famous library, React. Every single one of them are made to solve the same problem: How I use this amazing language without repeat myself, or how us developers like to say, develop without DRY (don't repeat yourself).
But before I follow the normal flow of this text, I want to make a pause and use a question to catch a detour: So, one time a friend from another job segment question me something like this: Ok, Marcel, I understand the Why to use a framework, but if I don't want use it? If I want develop an App to do some X, Y, Z things only with the native language?
The short answer: you can. The long: I shouldn't. I explain why:
If you don't want to use a framework, you need to start thinking about how you will solve the problem without, again, DRY. For example, if your app will use a database, like a spreadsheet, you will need to create the connection with the database, do some query and show the result for the user. If you don't want to use a framework, you will need to write this code by yourself. But wait, there is more: when you create this connection, you need to think about the security, because if you don't do it, your user's data will be exposed. And if you think this is only a problem with the database, you're wrong: this problem will follow you in the all app, because you need to think about the security in the all requests, in the all responses and in the all steps of the user flow.
So, if you don't want to use a framework, you need to think about the problem in a different way, because if you don't do it, you will need to literally reinvent the wheel.
When you use a framework, you're using a set of best practices and patterns already defined and improved by the community. That's right! Someone already invented the wheel, database requests like fetchs, security patterns, and so so much more. And this is amazing, because you don't need to think about it, only focus on your code, or even better the problem that you came to solve in the first place.
If you use a framework, you will have a better organization in your code, and this is important, because a good code organization means better maintenance and better scalability. When you don't have a good code organization, your code will be a mess, and this is not a good thing, because a mess code is a code that is difficult to understand and difficult to change. And believe me girl, YOU WILL CHANGE A LOT OF THAT STUFF OVER THERE.
And the frameworks follow the principle of convention over configuration, which means that you will have a better development velocity, because you will need to write less code to do the same things.
So... In short, you need to use a framework mostly because:
- It's easier to maintain and scale an application when using a framework (complete this for me: don't repeat...);
- A framework defines a set of best practices and patterns that will make your life easier (Someone already invent the wheel!!!);
- A framework follows the principle of convention over configuration, what means that you will need to write less code (again, less repetition: more problem-solving);
- And finally, because a framework will make your code more organized (and a good code organization means better maintenance).
"I got it Marcel... But just for asking, there's some downside to this? It can't been all that good... Where does the framework fail?"
"Good point my friend! Like everything in life, there's some price to pay for this utopia that is using a framework. This price is the learning curve. When you're starting to use a framework, you will need to learn about this new set of tools, and this can be difficult and time-consuming. But believe me: the price is worth it."
I remember when I start to understand Redux and VueX. Boy! I spend some time to catch the tail of these things, but when I finally see the problem that they could solve in just 5 or 10 lines of code, I realize that frameworks rock, even having a downside of has to learning almost another programming language.
Top comments (4)
react is not a framework, it is a library
This is such a tired argument about semantics.
Yes React is technically a library. That's great. But it almost always encompasses the entire application, tightly coupling with every part of the codebase, forcing you to write your code in a way that adheres to React's rules. It might as well be a framework.
And even if React is a library and not a framework, all of the points made here still apply so why is it necessary to point this out?
Agreed! Thanks for bring that out, Jack! My intention it is to help beginners in development to understand the role of frameworks at very entry level, and not confuse them about semantics.
Yes it is. Thanks for that 🙏