At first place, we need to know what is a framework: put simply, a framework is an abstraction to solve recurring problems using a generic solution/approach. In many places you’ll find a similar definition for libraries.
But, the main difference between a lib and a framework is its scope. Consider React and Angular - the first is a library to build user interfaces; the second is a framework to build SPAs. The difference between them is their scope - inside Angular you’ll have routing, services and its helpers; and inside React you won’t have any of it, but only if you install other libs to accomplish what you want, and those libs will only do what is inside their scope.
var element = $('.element'); // or var element = jQuery('element');
But, this function is from jQuery, which will render the native JS code:
var element = document.querySelector('.element');
Beyond the selectors, it will happen to add/remove classes and other attributes, event listeners, API calls, and many other cases.
And that was the time when I started to really learn JS and how everything worked - I saw jQuery source code to know what all of those functions worked and how they used the JS native code, I learned about clojures and IIFEs… And, since then I started to follow the what’s inside this article’s title:
No framework is the best framework.
Of course, there are cases which will be easier and simpler to use a lib or a framework to solve a problem - it would save you time and effort, and we won’t rebuild the wheel every day. Have you ever thought about writing for yourself the same front-end routing code for every single project you work on? It’s not hard, but there are a few libs which do it for you, and your effort is to use them the right way.
But, there will be cases in which the usage of a lib or a framework would only put unnecessary complexity in your codebase. I always take the example of Developer Titles: I’ve made it using VanillaJS (JS in its “pure form”) with Webpack as my bundler.
If I used React, or Vue, or any other hype my codebase would became larger and complex, it would increase the number of dependencies, increase the building time… And I see those increasings as unnecessary - our plain old JS can handle it by itself.
In the last couple of years I had the luck to know great developers - by changing my job, or going to meetups, or even knowing friends of friends. And due to this contact I’m focusing on those simple, well-written things over those projects with high complexity which solves nothing.
Talking this way would seem that I condemn some tools, but I don’t. I just want to say that we, developers, should always focus on simplicity - having the KISS Princple in our heads when we’re developing.
If we focus on simplicity, explicity and solving the problem, the chance of overengineering will decrease dramatically, and we’re creating a code that will be simple for other people maintain; even because we’re always writing code for other people, not for ourselves or machines.