My Journey Back to Vanilla JS: Why Am I Doing This?
Hey everyone! Roberto here. I've been in the web development game for quite a few years now, and if you follow me a bit, you'll know I've sailed through some pretty diverse waters. I've been embraced by Angular, felt at home with React, explored the goodness of Vue, and of course, I've gotten my hands dirty with Node.js and its ecosystems. Each of these tools, frameworks, or libraries has offered us incredible solutions, accelerated our development, and allowed us to build increasingly complex and robust applications. They are, without a doubt, fundamental pillars of modern development. However, lately, I've realized something. Something that's made me slow down, look back, and ask myself if we aren't, at times, unnecessarily complicating things.
The Temptation of Abstraction
I think we've all, to a greater or lesser extent, fallen for the temptation of abstraction. Frameworks promise us structures, patterns, optimizations, and a way of thinking that, a priori, seems like the solution to all our problems. And often, they are. They get us out of jams, let us build fast, and give us a community to lean on. I have to confess, I've enjoyed those moments, the speed you get from a well-made React component, the structure Angular imposes, or the flexibility Vue offers. But I've also started to feel a kind of nostalgia. A call to the roots. A need to understand the engine, not just drive the car. And that's why I've decided to embark on a journey back. A journey to Vanilla JS. Pure, unadulterated JavaScript.
Why Now? The Reasons Behind the Return
I know what you might be thinking: "Roberto, are you crazy? Going back to Vanilla JS in the middle of 2024?". Maybe, but there are reasons that weigh on me. The first and most important for me is simplicity. When you work with Vanilla JS, you remove layers of abstraction. There's no separate virtual DOM to manage, no template system to interpret, no compiler in between hiding the JavaScript code that's actually running. You have the browser and your code. It's that straightforward. This allows me to better understand what's happening, how the DOM is being manipulated, how events are managed, how information flows. I feel my understanding of the browser and JavaScript at a deeper level is strengthening day by day.
Another advantage I'm rediscovering is performance. While modern frameworks are highly optimized, sometimes the overhead they introduce can be significant in small or medium-sized projects. With Vanilla JS, you have total control over what's running. You can optimize down to the last detail, ensuring only what's strictly necessary is loaded and executed. This translates, in many cases, into faster, lighter applications with lower resource consumption. It's not that frameworks are slow, far from it! It's that with Vanilla JS, you have the capacity to be excessively precise in optimization if you wish.
Furthermore, there's independence. You don't depend on the decisions of a community or the changes of an external library. Your code is yours, yours and the browser's. If React decides tomorrow to change how it does things, or Vue introduces a new API, you might have to adapt your project. With Vanilla JS, as long as the browser supports a feature, your code will keep working. It gives you a freedom and longevity that, for certain types of projects, is invaluable.
And, honestly, there's a component of continuous learning. The world of web development moves at a breakneck pace. New tools and paradigms are constantly emerging. I love staying up-to-date, but I also believe it's crucial to have solid foundations. Returning to Vanilla JS is, for me, about reaffirming those foundations. It's remembering why JavaScript is so powerful on its own, and how we can get the most out of it without adding unnecessary layers.
Challenges and Rediscoveries
I'm not going to lie, it's not all a bed of roses. Going back to Vanilla JS means facing challenges we had left behind thanks to the magic of frameworks. State management, for example, becomes a more manual exercise. You have to think carefully about how you're going to organize your data, how you're going to update it, and how you're going to reflect those changes in the user interface. No magic state hooks or predefined store systems. You have to build it yourself or, at most, rely on more basic patterns.
Modularity also requires more careful planning. Without a framework's module system, you need to think about how you're going to organize your code into separate files, how you're going to import and export functionalities. Although we have ES6 modules today, their integration and management in larger projects can require more initial effort than simply importing a component from a library.
And, of course, code reusability. While plain JavaScript offers many possibilities, creating reusable and maintainable UI components in isolation requires a discipline and design that, with the right framework tools, was sometimes taken for granted. Now, I have to think more about composition, about separation of concerns, about how to make my functions and code blocks as generic and powerful as possible.
But, paradoxically, these are the challenges that are proving most rewarding. They force me to think more, to be more creative, to seek elegant and efficient solutions. It's like rediscovering an artisan's tools after using modern machinery. You have to be more skilled, more precise, but the final result can be, in many ways, purer and more satisfying.
Does This Mean the End of Frameworks? Not at All!
I want to be very clear about this. This is not an anti-framework manifesto. Frameworks are fantastic tools and will continue to be essential for many projects. If you're building a complex enterprise application, an interactive dashboard with thousands of features, or a project that needs massive scalability, a well-chosen framework will likely be the best option. It will save you time, give you structure, and facilitate collaboration.
What I do believe, and what has led me on this journey, is that perhaps we've fallen into a kind of "framework dependency." We've gotten used to tools doing the heavy lifting for us, and in the process, we may have lost a bit of that deep understanding of how things work under the hood. My goal with this return to Vanilla JS is precisely to reconnect with that knowledge. It's like a musician who, having mastered synthesizers and effects, decides to return to the acoustic guitar to better understand the strings and the resonance of the wood.
Final Thoughts and the Future
This journey into Vanilla JS is teaching me a lot. It's making me a better developer, not because I'm using a "more advanced" tool, but because it's forcing me to think more fundamentally. It's reminding me of the intrinsic power of JavaScript and the browser. It's teaching me that simplicity isn't at odds with power; in fact, they are often two sides of the same coin.
What projects am I doing with Vanilla JS? For now, they are mostly personal projects, small utilities, or parts of larger projects where a framework feels excessive. I'm experimenting with Vanilla JS to build interactive user interfaces, to manipulate the DOM efficiently, and even to explore the browser's API in ways I hadn't previously considered.
If you're feeling that same curiosity, that same call to the roots, I encourage you to give it a try. You don't have to abandon your favorite frameworks overnight. Start small. Create a small utility, refactor a small part of your project, or simply dedicate some time to reading the native browser documentation. I assure you, you'll rediscover a world of possibilities and, above all, reinforce your understanding of what it means to build web applications in their purest form. This journey back to Vanilla JS is, for me, a form of growth. A way to better understand the craft. And, honestly, a way to enjoy web development even more. I'll keep you updated on how it goes!