Do not learn frameworks, learn architecture
Some time ago I had an interesting conversation, a colleague actively defended Angular, saying that it speeds up web development. I have been developing complex web services for more than ten years, I worked at Microsoft, at Spotware Systems in Cyprus, now I am creating an application for a startup from Silicon Valley, and in general I’m following trends. However, I felt like a dinosaur, because I did not see the point of using front-end frameworks until that moment, but it turned out that this is already mainstream. It was 2014, I plunged into the world of Angular, Knockout and Backbone, what came of it, why I refused from them and recommend to my colleagues to do the same - under the cut.
We all know that Angular has a lot of problems, and one of the main issues is debugging. When undocumented errors appear, only stackoverflow saves, and then you have to look for what exactly happened, and most importantly in what place. Backbone and Knockout also have their drawbacks, but many continue to use them, because their virtues negate them. And to be honest, because they do not see an alternative. And there is an alternative, just forgot about it.
Remember the old programmer principle - each module must perform one function. If he performs two or more, he needs to be broken apart. Why and why stick to this anyone can read themselves in a huge number of open sources. So all existing frameworks violate this principle. I will say more, the “framework” approach itself violates it. The framework pushes us into frames, forcing us to follow the “best practices”, only the best practices are constantly evolving and a small group of creators are simply not able to know which practices are universally suitable for a small promotional page with animation and for a management panel with complex logic data administration and for a media site with high performance requirements. Best practices from there can be learned only if you are completely new to programming, then the framework disciplines. But I will give you another tip - take the best practices, but leave the framework aside from work. I will explain what I mean.
It seems that the framework is something big that is incredibly difficult to reproduce. In fact, this is just a set of standard patterns . For example, the Observer pattern, it is used in Backbone models, in Angular and Knockout data-binding, and produces a rather large “Wow!”. But this is just a well-known pattern that can be implemented in JavaScript in 30 lines of code or download one of thousands of ready-made options (by the way, they are all the same, they differ only in the name of the methods, since the principle of the pattern is one). Other components of the framework are similar. Often, understanding the principle, you can generally write only zero lines of code, for example, implementing MVP within a small component just to mentally share that these methods are the controller, these properties are the model, etc ...
')
Example from practice: once I was interviewed in one company in Spain. It was necessary to make a test task, in one hour in the live-coding mode, to create a one-page documentation application, as I have time. I managed to completely, in JavaScript with only modular libraries . Even there is not much time to write tests. People did not understand how it is possible to implement routing with page switching, complex inactive elements and more during such time without frameworks. These are guys who, like me, have been in the industry for 10 years, but they studied specific solutions, not principles.
When you study frameworks, you need to relearn yourself when moving to a new solution, but they appear constantly, and most of your experience is erased . When you learn principles, they remain . I use the library to create classes written 5 years ago. Module injector, implementation of the observer, written around the same time. Each of them performs exactly one function and performs it well. I have never had the desire to change one component to another, as happens with frameworks, because the “observer” is the “observer”, it is a pattern, not a code. Patterns can be combined depending on the task, but they do not change. Another old principle - the code can be supplemented, but not changed. His rationale, too, can easily be found in google or in the books of the gang of four. Following this logic, if a second version appears in a framework or library, the third, tenth, some functions are removed, some are changed - this is initially a vicious product. The only good reason for changing the code is to adapt to new browsers, but the public methods should not change at all.
Programming becomes a victim of marketing. We are promised a magic button that will solve all our problems. Only payment for this, that many sit down on it and are no longer able to lay out the complex on the components, to separate the wheat from the chaff. Am I using frameworks? Yes, when you need to create a product that will not need to be later supported. But complete suicide to use them in the service, which will live and develop at least 1-2 years. During this time, you write a code much more than the entire framework includes, and you will repeatedly encounter its limitations. The time that you spend on writing crutches and fixing universal things for yourself would be more than enough for you to implement a set of just the right components instead of a cumbersome framework. This is not a bicycle industry, you use libraries, but combine them according to the situation, and not in a single predetermined way. In frameworks it is also possible to connect extensions, but what if I want to get Backbone models in my API. Or do not fetch at all. Or pick up from localStorage. And if there is still a complicated logic of updates, depending on the date and flags. And after the fetch, you need to send the pool of the same model to another server. You never know what features may arise. And in such situations, use Backbone? There will be 5% of its functionality , the rest - crutches and custom logic. At the same time, understanding the architectural principles, it is not difficult to create a solution that works as well as possible specifically for this task. And make it resilient to changing requirements, flexible.
It is known that most of the time the programmer does not print, but thinks . And thinking design patterns is useful for efficiency. I usually read the public methods of new libraries in search of interesting architectural solutions . If the implementation of something is not clear - I can see the code, but the ideas themselves are usually important. For example, promises are implemented in 10 minutes, but what is the effect. Therefore do not learn frameworks, learn architecture.
PS: The article is deliberately provocative, there are some good in frameworks, but they cultivate ignorance. It's a shame when a person cannot solve a problem without a framework and gets stuck in work for days and weeks. In fact, it is simple, if you pay attention to the right things, to architectural solutions, this very idea was to be conveyed. I hope the article will be useful, especially for beginners, and the approach described here will make them much steeper professionals in the future.
We all know that Angular has a lot of problems, and one of the main issues is debugging. When undocumented errors appear, only stackoverflow saves, and then you have to look for what exactly happened, and most importantly in what place. Backbone and Knockout also have their drawbacks, but many continue to use them, because their virtues negate them. And to be honest, because they do not see an alternative. And there is an alternative, just forgot about it.
Remember the old programmer principle - each module must perform one function. If he performs two or more, he needs to be broken apart. Why and why stick to this anyone can read themselves in a huge number of open sources. So all existing frameworks violate this principle. I will say more, the “framework” approach itself violates it. The framework pushes us into frames, forcing us to follow the “best practices”, only the best practices are constantly evolving and a small group of creators are simply not able to know which practices are universally suitable for a small promotional page with animation and for a management panel with complex logic data administration and for a media site with high performance requirements. Best practices from there can be learned only if you are completely new to programming, then the framework disciplines. But I will give you another tip - take the best practices, but leave the framework aside from work. I will explain what I mean.
It seems that the framework is something big that is incredibly difficult to reproduce. In fact, this is just a set of standard patterns . For example, the Observer pattern, it is used in Backbone models, in Angular and Knockout data-binding, and produces a rather large “Wow!”. But this is just a well-known pattern that can be implemented in JavaScript in 30 lines of code or download one of thousands of ready-made options (by the way, they are all the same, they differ only in the name of the methods, since the principle of the pattern is one). Other components of the framework are similar. Often, understanding the principle, you can generally write only zero lines of code, for example, implementing MVP within a small component just to mentally share that these methods are the controller, these properties are the model, etc ...
')
Example from practice: once I was interviewed in one company in Spain. It was necessary to make a test task, in one hour in the live-coding mode, to create a one-page documentation application, as I have time. I managed to completely, in JavaScript with only modular libraries . Even there is not much time to write tests. People did not understand how it is possible to implement routing with page switching, complex inactive elements and more during such time without frameworks. These are guys who, like me, have been in the industry for 10 years, but they studied specific solutions, not principles.
When you study frameworks, you need to relearn yourself when moving to a new solution, but they appear constantly, and most of your experience is erased . When you learn principles, they remain . I use the library to create classes written 5 years ago. Module injector, implementation of the observer, written around the same time. Each of them performs exactly one function and performs it well. I have never had the desire to change one component to another, as happens with frameworks, because the “observer” is the “observer”, it is a pattern, not a code. Patterns can be combined depending on the task, but they do not change. Another old principle - the code can be supplemented, but not changed. His rationale, too, can easily be found in google or in the books of the gang of four. Following this logic, if a second version appears in a framework or library, the third, tenth, some functions are removed, some are changed - this is initially a vicious product. The only good reason for changing the code is to adapt to new browsers, but the public methods should not change at all.
Programming becomes a victim of marketing. We are promised a magic button that will solve all our problems. Only payment for this, that many sit down on it and are no longer able to lay out the complex on the components, to separate the wheat from the chaff. Am I using frameworks? Yes, when you need to create a product that will not need to be later supported. But complete suicide to use them in the service, which will live and develop at least 1-2 years. During this time, you write a code much more than the entire framework includes, and you will repeatedly encounter its limitations. The time that you spend on writing crutches and fixing universal things for yourself would be more than enough for you to implement a set of just the right components instead of a cumbersome framework. This is not a bicycle industry, you use libraries, but combine them according to the situation, and not in a single predetermined way. In frameworks it is also possible to connect extensions, but what if I want to get Backbone models in my API. Or do not fetch at all. Or pick up from localStorage. And if there is still a complicated logic of updates, depending on the date and flags. And after the fetch, you need to send the pool of the same model to another server. You never know what features may arise. And in such situations, use Backbone? There will be 5% of its functionality , the rest - crutches and custom logic. At the same time, understanding the architectural principles, it is not difficult to create a solution that works as well as possible specifically for this task. And make it resilient to changing requirements, flexible.
It is known that most of the time the programmer does not print, but thinks . And thinking design patterns is useful for efficiency. I usually read the public methods of new libraries in search of interesting architectural solutions . If the implementation of something is not clear - I can see the code, but the ideas themselves are usually important. For example, promises are implemented in 10 minutes, but what is the effect. Therefore do not learn frameworks, learn architecture.
PS: The article is deliberately provocative, there are some good in frameworks, but they cultivate ignorance. It's a shame when a person cannot solve a problem without a framework and gets stuck in work for days and weeks. In fact, it is simple, if you pay attention to the right things, to architectural solutions, this very idea was to be conveyed. I hope the article will be useful, especially for beginners, and the approach described here will make them much steeper professionals in the future.
Source: https://habr.com/ru/post/253297/
All Articles