Do not learn frameworks, learn architecture

    Some time ago I had an interesting conversation, a colleague actively defended Angular, said that it speeds up web development. I’ve been developing complex web services for more than ten years, I worked at Microsoft, at Spotware Systems in Cyprus, now I’m creating a startup application from Silicon Valley, and in general I follow trends. However, he felt like a dinosaur, because he did not see the point of using front-end frameworks up to that point, but it turned out to be the mainstream. The year 2014 was on, I plunged into the world of Angular, Knockout and Backbone, which came out of this, why I eventually refused them and recommend that my colleagues do the same - under the cut.

    We all know that Angular has a lot of problems, and one of the main ones is debugging. When undocumented errors appear, only stackoverflow saves, and then you have to look for what exactly happened, and most importantly, in which place. Backbone and Knockout also have their drawbacks, but many continue to use them, because their advantages cross out. And to be honest - because they do not see an alternative. And there is an alternative, they just forgot about it.

    Remember the old programming principle - each module must execute onefunction. If he performs two or more - it must be broken into pieces. Why so and why this adhere to those who wish can read for 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 the framework, forcing us to follow “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, or for a management panel with complex logic data administration and for a media site with high performance requirements. Best practices from there can be gleaned only if you are completely new to programming, then the framework disciplines. But I will give you other advice - 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. This is actually just a set of standard patterns . For example, the Observer pattern, it is used in Backbone models, in Angular and Knockout data bindings, and produces a rather large “Wow!”. But this is just a well-known long time ago pattern that can be implemented in JavaScript for 30 lines of code or download one of thousands of ready-made options (by the way, they are all the same, differ only in the name of the methods, since there is only one principle of the pattern). Other framework components are structured in a similar way. Often understanding the principle, you can generally write only zero lines of code, for example, implementing MVP within the framework of a small component, just mentally separate that these methods are the controller, these properties are the model, etc.

    An example from practice: once I was interviewed at a company in Spain. It was necessary to do a test task, in an hour in live-coding mode, create a one-page documentation application, as long as I can. I succeeded completely, in JavaScript with only modular libraries . Even a little time left to write tests. People did not understand how to implement page switching routing, complex interactive elements, and more in such a 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 when switching to a new solution, and they appear constantly, and most of your experience is erased . When you studyprinciples - they remain. I use a library to create classes written 5 years ago. A module injector, an observer implementation, 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”, this is a pattern, not a code. Patterns can be combined depending on the task, but they do not change. Another old principle is that the code can be supplemented, but not changed. Its justification can also be easily found in google or in the books of a gang of four. Following this logic, if a framework or library has a second version, a third, a tenth, some functions are deleted, some are changed - this is initially a vicious product.

    Programming is a victim of marketing. We are promised a magic button that will solve all our problems. Only the fee for this, that many people sit on it and are no longer able to lay out the complex into components, to separate the grains from the chaff. Do I use frameworks? Yes, when you need to create a product that you don’t need to maintain later. But complete suicide use them in a service that will live and develop at least 1-2 years. During this time, you write a lot more code than the whole framework includes, and you will encounter its limitations many times. The time that you spend writing crutches and fixing universal things for yourself would be more than enough for you to implement a set of only the necessary components instead of a clumsy framework. This is not cycling, you use libraries, but combine them according to the situation, and not in a single predefined way. In frameworks, extensions can also be connected, but what if I want to fetch Backbone models using 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 what features may arise. And in such situations, use Backbone? There will be what features may arise. And in such situations, use Backbone? There will be5% of its functionality , the rest is crutches and custom logic. At the same time, understanding the architectural principles, it is not difficult to create a solution that works best 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 with design patterns is good for efficiency. Usually I 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 as a rule, the ideas themselves are 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 intentionally provocative, there is good in the 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’s simple, if you pay attention to the right things, to architectural decisions, this is exactly the idea I wanted to convey. I hope the article will be useful, especially for beginners, and the approach described here will make them much more cool professionals in the future.

    Only registered users can participate in the survey. Please come in.

    Have you used frameworks on large B2C projects?

    • 16.4% I applied, there are more restrictions than opportunities 463
    • 30.9% Used, more opportunities than restrictions 872
    • 31.1% Each project has its own 878
    • 21.5% not used 607

    Also popular now: