It’s very common for us to find a new framework inside the JavaScript ecosystem. Almost every day we can spot a new one (for us or a newcomer), which claims to be the solution for all of our problems.
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.
Many times we use those libs and frameworks so much that we forget what’s behind - JavaScript. And it happened to me when I was starting my career as a front-end developer. When I’ve started to develop, I used a lot Boostrap and jQuery for everything. To build a simple page or a huge dashboard, I would put them as dependencies.
And, in a specific project I had a restriction for those dependencies - and it was when I realized that I didn’t know JavaScript, but only jQuery. I knew so much the jQuery’s functions that I wasn’t able to tell if they were from jQuery or native JS. For example, to query elements on the DOM, you’d use the following code:
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.
Today I see lots of developers excited about those new tools which surrounds front-end development, but they don’t know the power and simplicity of JavaScript in its “normal” state - even so after the evolution we’re seeing after the emerge of ES6 on 2015.
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.
