That Old, Faithful Friend Called jQuery
If you've been in web development long enough, you surely hold a special place in your heart for good old jQuery. I certainly do. I remember my early years perfectly, when all I needed to feel like a true architect of the web was to import that script from a CDN and start sprinkling dollar signs all over my code. $(".mi-clase").hide() and—boom!—magic. It was a simpler time, or at least that's what we wanted to believe.
The problem wasn't the tool, but what my projects eventually turned into. I still have nightmares about main.js files that exceeded three thousand lines, where finding the logic for a simple button was like looking for a needle in a haystack of chained selectors. The famous spaghetti code wasn't a warning; it was my daily reality. I manipulated the DOM directly, aggressively, and above all, without control. If I changed a in the HTML, half the application would fall apart because my jQuery selector could no longer find what it was looking for. It was a house of cards held together by a thread.
The Reality Check: My First Encounter with Angular
When I first heard that frontend development was becoming professionalized with frameworks like Angular, my first reaction was absolute rejection. "Why do I need TypeScript? What's a decorator for? Why do I have to compile code just to see a 'Hello World'?". I felt comfortable in my chaos, but the market and the complexity of the projects coming my way started pushing me toward the abyss of modern development.
My first contact with Angular (back then we were already moving from the old AngularJS to the new versions) was frustrating, I'm not going to lie. I felt like a junior all over again. I didn't understand why I had to create five files just to show a list of users. It seemed like excessive engineering to me. However, there was a moment of enlightenment, a mental click that changed everything: I understood that modern development isn't about manipulating elements on the screen, but about managing the state of the data and letting the framework handle the visual representation.
The Mindset Shift: From 'How' to 'What'
With jQuery, my head was always thinking about how to change a button's color or how to add a row to a table. I had to give step-by-step instructions: 'Find this element, create this other one, add this class, insert it here.' It was exhausting and prone to errors.
When I moved to Angular, I started thinking in components. The big revelation was realizing that HTML was no longer a static document that I modified from the outside, but a living template that reacted to my data. If my data said there were three users, the interface showed three rows. Period. I no longer had to go in with a brush painting every detail; I just managed the color palette (the data) and the framework did the dirty work.
The Hardest Parts to Master
It wasn't all sunshine and rainbows. The Angular learning curve is, to put it generously, a steep mountain. Here are a couple of things that really made me sweat:
- Dependency Injection: At first, it seemed like black magic. I didn't understand how a service just appeared out of nowhere in my constructor. It took me a while to grasp that the framework was the one managing the lifecycle of my objects.
- Observables and RxJS: This was, without a doubt, the toughest part. Moving from simple promises to reactive data streams blew my mind. I remember spending entire afternoons trying to understand why a subscribe wasn't returning what I expected. But once you understand the power of reactive programming, going back feels like trying to drive a car with wooden levers.
Was All the Effort Worth It?
Absolutely, yes. I'm often asked if I miss the speed of whipping something up with jQuery. My answer is that for a ten-minute prototype, maybe, but for sleeping soundly at night, I'll take Angular a thousand times over.
The transition taught me to be a better developer, not just because I learned a new tool, but because I learned software architecture. I learned to separate responsibilities, to write testable code, and to value the strong typing of TypeScript. I no longer cross my fingers every time I deploy, hoping a CSS selector didn't break the entire shopping cart logic. Now, I trust my code.
Sometimes I stumble upon my old code from 2014 and I get a shiver down my spine, but at the same time, I feel proud. It was necessary to go through that mud of selectors and global events to truly appreciate the elegance of a well-structured modular architecture.
Final Reflections and Advice
If you're at that point where your gut is telling you to make the leap but you're afraid of the complexity, my advice is: go for it. Don't try to learn everything at once. You don't need to be an RxJS expert on day one. Start by understanding components and data binding. The rest will come with practice and from the bumps you'll take against the browser console.
The web has evolved, and so have we. jQuery was a wonderful bridge that allowed us to cross the river of browser incompatibility, but today we are building skyscrapers, and for that, we need heavier and safer tools. It's not just a change of framework; it's a professional evolution that opens the doors to understanding how quality software is built today.