What I learned from 3 years of AngularJS

Life before Angular

Once upon a time I was a part time web developer. By that I mean I wrote some HTML, added some horribly organized CSS and sprinkled a little magic jQuery around to get that Web 2.0 dynamic feel. It was a world of full page postbacks with massive blocks of $(document).ready() and dozens of event handlers attached to DOM nodes. It was unorganized and nearly unscalable, but I was writing web apps and I was loving it.

The web platform is an amazing space for creating great applications. Everyone has a browser and the entry cost of HTML, CSS and jQuery is very low. Today there are more web application stacks than you can seemingly discover in a lifetime, but it wasn’t always like that (at least not for me).

After the server side MVC explosion, everything seemed to revolve around how to design web apps on the server with routing, dynamic HTML scripting, and well organized libraries of maintainable code. It seemed like a well oiled machine delivering HTML into your browser only to be augmented by JavaScript that resembled a bolt on afterthought.

For me, jQuery came along and immediately made sense. JavaScript and all of the nuances that went along with it were complicated. jQuery made things easier, made browsers compatible and the plugin libraries were powerful. I used jQuery and enjoyed the power and flexibility, but I still struggled to understand and develop complex applications on the client side of the web. And to top it all off, I didn’t even really know JavaScript.

But then came Angular

Angular changed everything for me. It filled the gap between a glorified scripting environment and a full fledged application platform that was testable, well organized, expressive, and powerful. I began to create server side apps that were a single page designed to spin up my hammer in a world full of nails.

I got pretty good with Angular. I embraced large code bases of JavaScript, er, Angular, and I felt like I was in the golden age of web development. I advocated for Angular at my job and, to my surprise, they agreed. We wrote and we continue to write large, complex web applications that are truly enterprise scale. Angular was the thing that made me understand how powerful JavaScript as a language was and how amazing things could be done abstracted away in a world that didn’t even seem like the web.

But even with a stack as robust and well engineered as Angular, it wasn’t without its limits. When I started with it, there wasn’t a lot of guidance around how to organize your file structure or how best to organize your code inside of components. At times, I ended up with tons of logic in controllers or data structures being cached and manipulated in scope that was woven around every building block of my applications. That led to tests that were huge, complex and nearly impossible to keep up to date as changes were made.

Eventually, I learned how to minimize these things. Razor thin controllers that did nothing except provide some basic data to the application. I learned that services and isolated directives were the best places for managing data and doing web things. Eventually, I started to understand why Angular did the things it did. I forced myself to learn more about JavaScript because I lived in that world so much of my time.

A Thought Transformation

And then a funny thing started happening. Angular started to feel heavy. I started to feel more comfortable working closer to the browser. Suddenly Angular felt like a luxury sedan when I started to want a sports car. It had a smooth ride and at times you didn’t even feel like you were driving, but then again, you didn’t feel like you were driving!

When you work with Angular, you are really learning the API and conventions that make up the framework. It hides you behind this wall and asks you to tell it what you want in its own way, then does the heavy lifting. It’s powerful, but kind of unfulfilling. I started to wonder if becoming an Angular developer meant becoming less of a JavaScript and web developer.

I mean, after all, we’re web developers, right? That means being able to do meaningful things outside of any one framework or library. Doesn’t that mean being able to use the full power of HTML 5, CSS 3 and ES5 or 6 by just sitting down in a text editor and serving up the things that you write? At the end of the day, libraries will always be used and it’s nonsense to think otherwise, but really learning the foundational areas of web development makes you realize how powerful it can be standing on its own.

Happily Ever After?

I still use Angular every day to make cool things on the web (it still pays the bills after all). But I don’t use Angular the same way that I used to. I started to think about ideas that aren’t necessarily native to Angular and how to elegantly weave them into it. Things like Reactive JS and the incredibly expressive nature of its functional patterns. Things like ReactJS and a unidirectional data flow with immutable data and small, composable objects. These ideas can be used to change the structure of your applications and make them better. Make them easier to reason about and maintain. And if you’re still married to Angular 1.x, you can combine it all to evolve your approach.

But for me, Angular 1.x has had its moment and fulfilled its purpose. It proved that the client side browser world can provide a platform for a full fledged application. It brought structure to a wild west platform. Largely any problem domain that was dominated by the compiled language world can now be handled with JavaScript and Chrome. Angular has moved me from web development framework button pusher to someone that wants to master every part of ES6. I want light libraries that augment the languages rather than take over. I’m a better web developer now because of Angular and now is the right time to leave it. Ironic I guess.