Why I Stopped Using Frontend Frameworks: Insights from a Decade of Web Development

Some time ago I had an interesting conversation with a colleague who championed Angular, claiming it speeds up web development. I have been building complex web services for over ten years, worked at Microsoft, Spotware in Cyprus, and now develop for a Silicon Valley startup. While I tend to follow trends, I feel like a dinosaur because, in my view, using frontend frameworks is meaningless despite their mainstream status.

In 2014 I dived into Angular, Knockout, and Backbone. If you want to know what I learned, why I stopped using them, and why I recommend you do the same, keep reading.

Angular has many problems, debugging being a major one. When undocumented errors occur, only Stack Overflow can rescue us, but we must also discover where the error originated. Backbone and Knockout have drawbacks too, yet many use them because their advantages outweigh the disadvantages, often unaware of alternatives.

Each module should perform a single function—an old principle. When a module does multiple things, it should be split. All existing frameworks violate this principle, and the “framework” approach itself imposes constraints while enforcing best practices that constantly evolve. For small teams, frameworks can help novices write disciplined code, but my advice is to follow best practices without relying on a framework.

Frameworks appear as large, hard‑to‑reproduce entities, yet they are merely collections of standard patterns. For example, Backbone models use the Observer pattern, also employed in Angular and Knockout data binding, yielding great results. The Observer pattern can be implemented in about 30 lines of JavaScript or obtained from countless libraries. Understanding these principles often lets us avoid writing any code; we can mentally map controllers, models, and views when implementing MVP in a small component.

From practice: I once interviewed for a Spanish company where I had to build a single‑page app for document creation within an hour, using only JavaScript libraries and no framework. The interviewers, seasoned professionals, could not grasp how I handled routing and complex interactions without a framework.

Learning frameworks forces you to relearn constantly as new solutions appear, eventually rendering parts of your experience obsolete. Learning principles, however, endures. I used a five‑year‑old library implementing the Observer pattern to create classes; the pattern never changed. Each library performs a single function well, unlike frameworks that replace components wholesale.

Programming has become a market victim, offering “magic” buttons that promise to solve all problems. Yet we grow accustomed to using them without truly decomposing complex issues. I would only use a framework when building a product that will never need maintenance; for services lasting a year or two, using a framework is essentially suicide, leading to more code than the framework itself and numerous workarounds.

You are not inventing the wheel; you are combining libraries based on real scenarios rather than predefined ways. While frameworks can be extended, relying on only 5% of their features forces you to write countless custom workarounds. Understanding architectural principles lets you craft solutions adaptable to changing requirements.

Programmers spend most of their time thinking, not typing. Reflecting on design patterns improves efficiency. For instance, we can implement promises in ten minutes, but the real value lies in the ideas behind them—hence my argument for learning architecture over frameworks.

P.S. This article aims to spark debate. Frameworks have advantages, but they can turn developers into “idiots.” Without a framework, you may face delays, yet focusing on the right architectural solutions makes problems simple and helps newcomers become great programmers.

A. Yes, I have used them. Their limitations outweigh their capabilities.

B. Yes, I have used them. Their capabilities outweigh their limitations.

C. It depends on the project.

D. No, I have never used them.