Don't learn the framework, learn the architecture

A while ago, I had a very interesting conversation. A colleague stood up to support angular, saying angular accelerated the pace of web development. I have been developing complex web services for over 10 years, working at Microsoft and working for Spotware in Cyprus. I am currently writing applications for a start-up company in Silicon Valley. In general, I will follow the trend. But I feel like a dinosaur, because in my opinion the use of the front-end framework does not make sense, but it is proven to be mainstream. In 2014, I invested in the world of angular, knockout and backbone. If you want to figure out what I got from it, why stop using them and recommend that you do the same, then welcome to the next look.

We all know that angular has a lot of problems, debugging is one of the main problems. When a non-documented error occurs, only StackOverflow can save us. But we should also find out what's going on and what's most important to find out where it happened. Backbone and knockout also have shortcomings. However, many people are using them because their merits are more important. To tell the truth, they didn't see any other choice. But we have a choice, but we forget it.

Should each module only perform one function, do you remember this old rule? If a module performs two or more functions, we should split it into different parts. We can find a number of reasons why we do this and why we should stick to it. In any case, all existing frameworks violate this principle. Moreover, the "framework" approach itself violates this principle. The framework gives us a certain limit, and it allows us to follow best practices. Best practices are also evolving, and for a small-scale team of developers, they may not know which practices are better suited for a small page, a management panel that contains complex logic for data management, or a multimedia site with high-performance requirements. Use the framework to constrain and standardize your code only when you are a novice programmer. My advice is to use best practices, but don't use frames. Let me explain why this is so.

The framework looks like something very large and difficult to reproduce. But it's just a collection of some standard patterns. For example, the Observer pattern is used in the backbone model, and it is also used in angular and knockout data binding, which results in a very good effect. But the observer pattern is just a well-known pattern, we can implement it with 30 lines of JavaScript code, or download one from thousands of out-of-the-box implementations (by the way, they are all the same except for the method name, because the principle of the pattern is the same). Other builds of the framework are implemented in a similar way. After understanding these principles, there are times when we don't have to write any code. For example, when we implement MVP in a widget, we can divide the methods into controllers, divide attributes into models, and so on.

An example from practice: I attended a job interview with a Spanish company where I had to complete a test within one hours, in the form of an online encoding. This task is to create a single-page application for the document. I use JavaScript to do this task, where only the libraries module is used. I even have time to write some tests. They don't understand how I implement routing without using frames, and complex interaction elements and many other things. They have been in the industry for more than 10 years of senior people, but they are only learning specific solutions, not principles.

Learning frameworks, you have to re-learn, learn new solutions that are emerging, and some of your experience will eventually become worthless. But when you learn the principles-principles are not changed. To create a class, I used a class library written five years ago, and the implementation of the observer pattern has not changed. Each class library performs only one function and performs well. I have never thought of replacing one component with another as a framework. Because the observer is the observer, it is a pattern, not a code. We may combine different patterns according to the task, but the pattern will not change. Another principle is that we can extend the code, but we can't modify it. We can find the corresponding basis on the Internet, or in the book "Gang of Four". Under this principle, if your brother frame or library has a second, third or tenth version, some features will be deleted and other functions will be modified, which will result in some product bugs. The only good reason to modify the code is to adapt the new browser, but the public method should not be modified under any circumstances.

Programming became the victim of the market. They provide us with a "magic" button that promises to solve all of our problems. But as a result, we're getting used to it, but it's not going to break down complex problems and separate wheat from the shell. Am I going to use the frame? I use frames only when writing a product that will not be maintained in the future. But if the framework is to be used in a service that will last for at least one or two years, it is a purely suicidal act. In the meantime, you'll be writing more code than the entire framework, and more than once you're faced with the limitations of the framework. The time you spend writing various workarounds may be more time than implementing a large number of necessary components without using the framework.

You're not inventing the wheel. In fact, you do use class libraries, but you combine them based on real-world scenarios rather than predefined ways. One might say that the framework can also be extended. But what if I wanted to get the backbone model based on my API, or not get them at all? Or do I want to get them from local storage? What if we have complex update logic that relies on time and markup, and we should send the same model pool to another server after getting it? You will never know. Should we use backbone in this case? We will only use its 5% function, the rest are various workarounds and custom logic. At the same time, after understanding the architectural principles, it is not difficult to create a solution that adapts to each task and allows it to respond to changes in requirements.

As we all know, programmers are not typing at most of the time, they are thinking, thinking in design patterns can help improve efficiency. When I look for some interesting architectural solutions, I often read about the public methods of some new class libraries. If its implementation is not very clear, I will look at the code, but here is a principle, the idea is the most important. For example, we can finish promises within 10 minutes, but it works, and that's exactly why I'm telling you not to learn the framework but to learn the architecture.

P.S: This article is about hope to cause controversy. Of course, the framework has a certain advantage, but it can make a person into a "fool". If you don't use the framework, you can't solve the problem, and it's a shame to delay it for days or weeks. In fact, if we focus on the right things, in the architectural solution, it becomes very simple. That's what I'm trying to tell you. Hopefully this article will help newcomers, and hopefully the approach described here will make them very cool programmers in the future.

Have you ever used a framework in a large-to-consumer project?

• Yes, I have used it. These frameworks are more restrictive than they are capable of.
• Yes, I have used it. These frameworks are more capable than their limits.
• Depends on the project.
• No, I haven't used them.

from:http://blog.jobbole.com/97897/#comment-155631

Don't learn the framework, learn the architecture