I had an interesting conversation some time ago. A colleague of mine stood up for Angular and said that it fastened web development. I’ve developed complex web services for more than 10 years, used to work for Microsoft, and also Spotware Systems in Cyprus. As for now, I create an application for a strartup from the Silicon Valley. All in all, I follow the trends. But I felt like a dinosaur, as I saw no sense in using frontend frameworks, and it turned out to be mainstream. It was 2014, and I plunged into the world of Angular, Knockout and Backbone. If you want to find out what came out of it and why I stopped using them and recommend you to do the same, welcome under the cut.
We all know that Angular has a lot of problems, and debugging is one of the main ones. When undocumented errors occur, only stackoverflow can save us. But we should also find what has happened and, most importantly, where. Backbone and Knockout also have drawbacks. However, a lot of people use them, as their advantages are more important. To be honest, they see no alternative. Although, there is one, but we forgot about it.
Remember the old principle that each module should perform just one function? In case it performs two or more functions, we should divide it into parts. There are plenty of available sources to find out why so and why we should stick to it. Anyway, all the existing frameworks violate this principle. Moreover, a “framework” itself approach violates it. A framework keeps us within certain limits and makes us follow best practices. Only best practices keep developing and a small group of developers simply cannot know what practices suit better for a small promo page, as well as for a management panel with a complex logic of data administration, or a media website with high performance requirements. But a framework disciplines you only if you’re new to programming. My advice is to use best practices and keep frameworks away from work. Let me explain what I mean.
It seems that a framework is something big and difficult to reproduce. But it’s just a set of standard patterns. For instance, the observer pattern is used in Backbone models, as well as in Angular and Knockout data binding, and it produces quite a «Wow!» But it’s just a well-known pattern that we can implement in JavaScript in 30 lines of code, or download one of the thousands of ready-made options (by the way, they’re all the same and differ only in the method name, as the pattern principle is the same). Other components of frameworks are built in a similar way. Understanding the principle, we can often write zero lines of code. For example, when we implement MVP within the limits of a small component, we can mentally divide that these methods are the controller, and these attributes are the model, etc.
An example from practice: I had a job interview for a company in Spain, where I had to finish a test within an hour, in the live-coding mode. The task was to create a single page application for documentation. I performed the task in JavaScript, using module libraries only. I even had time to write tests. They couldn’t understand how I implemented routing, as well as complex interactive elements, and plenty of other things, without using frameworks. They are the guys who have been in the industry for 10 years, just like me, but they studied specific solutions rather than principles.
Studying frameworks, you have to relearn, moving to new solutions that appear all the time, and a part of your experience will be erased. But when you learn principles — they stay. To create classes, I use a library written 5 years ago, the implementation of the observer written around the same time. Each of them performs just one function, and performs it well. I never wanted to change one component to another one, as is the case with frameworks, because the «observer» is the «observer». It is a pattern, not code. Patterns can be combined depending on the task, but they do not change. Another old principle is that code can be supplemented, but not changed. It’s no problem to find its proof on the Internet, or in the books by the Gang of Four. Following this logic, if a framework or a library has a second, third, or tenth version, some functions are removed, others are changed, which makes such product defective. The only good reason for the code change is the adaptation for new browsers, but public methods should not in any way change.
Programming becomes a victim of marketing. They promise us a magic button that will solve all of our problems. As a result, people get used to applying it and cannot decompose complex things, separate the wheat from the chaff. Do I use frameworks? Only when it's not required to maintain a product in future. But it’s a complete suicide to use them in a service that will live and grow for at least a year or two. During this time, you will write more code, than that of the entire framework, and face its limitations more than once. The time you will spend on writing workarounds and improving things for yourself would be more than enough to implement plenty of necessary components instead of the slow framework. You are not inventing the wheel. In fact, you do use libraries, but combine them depending on the situation, and not in a predefined way. Frameworks can also work with extensions, someone may say. But what if I want to fetch Backbone models according to my API, or not fetch them at all? Or maybe I want to get them from the localStorage? What if there’s a complex logic of updates, depending on the date and flags, and we should send a pool of the same model to another server after the fetch? You never know. Should we use Backbone in such situations? There will be only 5% of its functionality. The rest will be workarounds and custom logic. At the same time, understanding the architectural principles, it’s not difficult to create a solution that will be the best for this very task, and make it resistant to requirement changes, make it flexible.
It is known that most of the time a programmer does not type, but thinks, and thinking in design patterns is useful for efficiency. I usually read public methods of new libraries when I look for interesting architectural solutions. If the implementation is not clear, I can look at the code, but, as a rule, ideas are the most important part here. For instance, we can implement promises within 10 minutes, but what’s the effect? That’s exactly why I’m telling you not to learn frameworks, but the architecture.
P.S.: The article is intentionally provocative. Of course, frameworks have certain advantages, but still, they cultivate ignorance. It's a shame when someone can not solve a problem without a framework and gets stuck in work for days and weeks. In fact, it’s really simple if we pay attention to the right things, to architectural solutions. That’s what I was trying to tell you about. Hope this article will be useful for beginners, and the described approach will make them cool programmers in the future.
Have you ever used frameworks for large B2C projects?
- Yes, I have. There are more limitations, than capabilities.
- Yes, I have. There are more capabilities, than limitations.
- Depends on the project.
- No, I haven’t
