A Little History

Nine years ago, I first delved into AngularJS through a learning project recommended by a good friend at my grandmother’s funeral, as preparation for an upcoming job interview. The project was inspired by a parody my brother had come up with for a game, and thus, Drop Kicking Babies (v0.0.1-alpha) was born, built on Angular 1.3.14. At the time, I was a full stack developer in .NET, and hadn’t experienced work as a purely front-end developer. JavaScript was not to be trusted for occasional form validation, let-alone be used to create a full on interface to a web application. My little project didn’t use Node Package Manager or ES5—just plain JavaScript. I relied on libraries like jQuery, Bootstrap, and Howler for sound effects, which were hot-linked from various websites. Images were pulled from Wikimedia, and audio came directly from SoundBible. I even kept a separate attribution document, simply because I didn’t fully understand licensing or how to properly credit others back then.

I got the job, and it had a unique approach that combined both AngularJS and React 12 to address Angular’s performance issues at the time by leveraging React’s Shadow DOM. Over the course of the job, I learned SCSS, Jest, Jasmine, ES5, Webpack, Babel, Angular, React, animating SVGs, HTML Canvas, mobile app development, and communicating with various medical devices via Bluetooth. With React, I often had to bypass JSX and build components programmatically because dynamic forms were created and managed by Angular factories to serve the components. In reality, I wasn’t gaining traditional experience with either React or Angular the way most developers did.

At my next job, I didn’t work with React or Angular but instead used CanJS. However, in my following role, I was heavily exposed to a wide range of React-based technologies. React had evolved significantly, and adjusting to the new features was challenging at first. To get up to speed, I created a small project at home, focusing on understanding the new concepts—particularly hooks, selectors, and Redux. From that project, I gained a solid grasp of React Redux, Redux-Saga, state management, hooks, function components, and more.

JavaScript had also become more stable, reducing the need for polyfills, and I started enjoying the new features of ES6, like arrow functions, object destructuring, function generators, template literals, default parameters, and lazy loading. I also became adept at handling asynchronous operations with both async functions and promises. In addition to React, I worked with technologies such as React Leaflet for maps, Elastic Search, Docker, GoLang, Kafka, and AWS.

After that job, I started my own company and had a client where my React skills proved invaluable. I continued to refine my expertise, exploring other libraries like React Query, and I also discovered Figma, a tool used for mocking up user interfaces and web pages. This allowed developers to work from detailed design concepts, further enhancing my ability to implement UI and web designs efficiently.

Modern Angular

Now, here we are. Over the past year, I’ve had a few leads and inquiries from potential clients, but the majority of the work has centered around Angular. Given my extensive experience with React, I hadn’t really revisited Angular. However, it seems that opportunities for React have either decreased or become fiercely competitive, and I’ve noticed fewer leads in that area. As a result, over the past few months, I’ve been focusing on building small projects in Angular to hone my skills. I began by upgrading Drop Kicking Babies to Angular 16.

I’ve now begun a large project with Angular 18, but I’m starting to think I might be heading in the wrong direction. The main issue is that tasks seem to take much longer in Angular compared to React. Additionally, Angular feels like it has a lot of unmanageable complexity. I’ve spent a few months working with Angular, but without real-world experience or professional guidance, I’m not making significant progress in improving my skills.

Here are the reasons I find Angular challenging at the moment:

• Slower Development: Working with Angular often feels slower compared to React.
• Lack of Professional Exposure: I haven’t yet worked in a professional environment where modern versions of Angular are used extensively, which limits my practical understanding.
• File Structure: Angular enforces a specific way of organizing files, which can be restrictive.
• Error Masking: Angular’s reliance on TypeScript sometimes masks errors due to its strict typing, making it harder to diagnose issues with components and templates.
• TypeScript Complexity: While TypeScript offers many benefits, its challenges become evident when working with complex data structures. Angular’s heavy reliance on TypeScript can further complicate things. I can accomplish a lot with TypeScript, but there are times when even I struggle to define the exact structure I need or figure out how to extend an object with additional properties to support another interface, without having to first cast it as an unknown type.
• Dependency Management: Components in Angular often require numerous dependencies to function correctly, which can be overwhelming.
• Lifecycle Management: Angular’s lifecycle management involves adding multiple interfaces to your class, which can become cumbersome. In contrast, React’s useEffect hook simplifies lifecycle management.
• Separation of HTML and Logic: Angular separates HTML from presentation logic, making it challenging to track what’s happening or where issues arise.
• Decorators: Angular’s use of decorators like @Component feels unnecessary. It’s puzzling why a class can’t simply be a component without needing additional metadata.
• UI Components: Angular includes built-in UI components through Angular Material, whereas React relies on external libraries like Material UI (MUI) or BluePrint.
• Template Logic: Angular templates don’t allow JavaScript if/for logic directly; instead, they use Angular-specific directives like *ngIf and *ngFor, with limitations on their use.
• State Management: React’s state management through hooks, (state, memoization, context), or Redux is often simpler compared to Angular’s approach.
• Form Validation: Angular provides two methods for handling forms (Template-Driven and Reactive Forms) and manages form state as an object, which seems more complex than React’s state hooks and third-party validation controls.
• Subscriptions: Managing subscriptions in Angular for service calls and state changes feels excessive and adds bloat.
• Lazy Loading: Angular lacks a straightforward equivalent to React Suspense for lazy-loading components with default content.
• Component Reusability: Creating reusable components in Angular feels overly complex compared to React’s approach. I wouldn’t know where to start in separating parts of my application into a separate git repository, other than utility functions.
• Testing: I haven’t yet explored Angular’s testing mechanisms for components or services. With React, the platform is built-in with Jest, with the underlying Jasmine testing library.
• Dependency Injection: Angular’s requirement for dependency injection can feel awkward compared to simply importing what you need in React and mocking it during unit testing.
• Modules: Many solutions provided when troubleshooting online involve creating module files, which seems unnecessary or confusing given that my sample projects often lack them.

Use What You Know

I need speed, confidence, and the assurance that when I have an idea, I can bring it to life without spending hours troubleshooting or getting sidetracked trying to figure out why a directive isn’t working, even when the module is clearly imported as every online solution suggests. Small projects are good for learning, but not the big ones. With that in mind, I’m ready to switch everything over to React.