Angular Burnout
I had a feeling of dread I couldn’t shake during a long holiday. To sum it up in a single sentence: “I don’t want to code anymore.”
Maybe my passion finally dried up after all these years of programming? Time for something new.
But after returning home, and returning to programming, I realised the dread was more specific: “I don’t want to code in Angular anymore.”
I’ve been deep diving into Angular (v1 and 2+) for three years now, and I’ve had enough. After much thinking and many discussions, my conclusion:
There’s no need for Angular in 2018
“I just need to learn Angular, then I can easily jump between any Angular project.”
This is a myth. All decent-sized projects I’ve seen slowly become custom and unique over time. Starting with Angular does not guarantee the entire project remains purely Angular.
If a 3rd-party library is better than the Angular offering, developers shift over. Remember when UI-Router landed? Nobody used the official ngRouter. This would’ve happened in Angular 2+ too if the community hadn’t already swarmed React.
My last Angular project exploded to include a Redux store with reselect, HTTP requests piped through @ngrx/effects, and composing smaller utility functions instead of creating full-blown services. Could any Angular developer jump straight into this setup? Nope.
“Code endorsed by the Angular team is better quality and more stable than a bunch of random 3rd-party libraries thrown together.”
Angular has mostly settled now, but the early days saw huge breaking changes every month or two. It portrayed a lack of vision and focus, not stability.
The official documentation had this gem:
This is not quality.
The JavaScript community is energetic, active, and passionate. A group of random developers can deliver code that surpasses the efforts of the core Angular maintainers.
“I like that Angular makes choices for me, I don’t want to pick and choose.”
I get it. You want to style your React project, okay: CSS Modules or Styled Components? Or maybe Glamorous? Oh, Emotion looks nice!
Relying on what Angular provides is initially easier, but you can be locked into poor choices. TypeScript is forced on you, but it might be overkill for your needs (the non-TS version of Angular is still undocumented all these years later). RxJS observables for HTTP requests is also mandatory, but using Promises might be a better fit. Factories, providers, services, ngModules, zone.js, AOT compilation, the list goes on.
Many projects succeed without this baggage. Is it necessary? It’s a lot to learn, a lot to code, and a lot to maintain.
Embrace the light-weight libraries that do one thing, and do it well. Celebrate that the JavaScript community provides you with so many options you can pick the best for your needs.
React reignites the passion
In the past weeks I’ve used React to build this website (powered by Gatsby).
I can get into the flow and just code. Less uphill battles, more “just doing it.”
React is light in all the right places, and complex only when I need it to be. I start with little and build up. I choose the libraries that best fit my needs. Freedom and power.
I love tying together tiny stateless components. It barely looks like framework specific code, and is super quick to scaffold. Goodbye NgIf, NgSwitch, NgFor and all that nonsense. (Fun fact: adding else
to *ngIf
was a “new feature” in Angular v4 😖)
I have only scratched the surface of React, but I can’t deny this feeling. The developer experience is A+ so far. I’m back in the game!
It’s impossible to keep up with JavaScript.
You’re catching up every chance you get. Scrolling… reading… refreshing… skimming. You’re lost in 42 browser tabs of articles, tutorials, and GitHub repos. You bookmark a handful to check out later (or, never).
It’s overwhelming. There’s too much to know.
So I developed a system that easily keeps me up-to-date.