Why 2023 is the best year to learn Angular

Sergey Gultyayev
4 min readSep 10, 2023

One of the biggest downsides of Angular was its steep learning curve. On top of that at the early ages of Angular, the documentation wasn’t as good and many things you would learn from GitHub Wiki and Issues instead of the official documentation.

Photo by Drew Beamer on Unsplash

In 2023 we have a lot better documentation than ever before and it keeps improving towards being more friendly for beginners yet resourceful for seasoned developers.

Classes vs functions

Moreover, Angular’s codebase is becoming less and less bulky thanks to the transition from classes to functions for things that can be replaced with a simple function instead of a whole class with a decorator, interfaces etc. This helps us to have files with fever lines of code (LOC) while keeping all the features we may need in place!

One of the enablers for the aforementioned is the inject function which can be called from within any injection context (constructor, property initializer, factory function and inside runInInjectionContext helper function). This enables us to drift away from having to rely on the constructor for injection. Furthermore, we now can create functions instead of single-method classes! Less code = happier developers!

Change detection

Another resource of troubles and headaches even for experienced developers is change detection in Angular. In the beginning, when we learn Angular it’s hard to wrap our heads around it. Then, when we get a feeling that we understand how to live with it we tend to avoid this topic. But the problems are hard to avoid.

Why do we have change detection in Angular in the first place? Because in contrary to React we don’t have an explicit way to tell the framework that something has changed in the state and a re-render has to happen. Instead, DX was in the focus and so Zones had come to the rescue. They monkey patch browser APIs to keep track of asynchronous events and trigger change detection when those happen. This implies strict rules on when you can update something.

This is where the infamous ExpressionChangedAfterItHasBeenCheckedError comes from. When you get it it’s not because the Angular team hates you and wants you to suffer. Instead, they kindly warn you that if your state has changed during the re-render most likely you will end up in the infinite loop of re-renders. Because render should not cause any changes to the state. Sometimes, however, it is required and we have to use setTimeout to update the state outside of the change detection cycle.

There is more to that. Zone.js is not out of thin air. It adds almost 100 KB to the minified Angular bundle.

This spring we received Angular Signals in developers’ preview. And this is a game changer. Truly! In the future, it will enable us to run Zoneless Angular applications with laser-focused DOM updates. Each View (read DOM node) will independently update when its Signal value changes.

Not only will it make our applications lightning fast and lighter but also it will make the mental model of change detection stupidly simple.

When you update the signal — places where it’s used are updated. That’s it.

No more Default and OnPush strategies. No more async pipes and multiple requests because of its multiple usages in the template. The life gets easier!

Also, if you needed to have a derived state before you would have to create a setter or use the ngOnChanges and do the calculations inside. The more derived states the more setters/if-s in the ngOnChanges .

With Signal inputs, you will be able to use a computed to derive the state and that’s it. No need to use setters or the ngOnChanges . The code is easier to read and understand. They are not part of the current v16 release yet, but I expect them to land in the v17 this fall.

We also got afterRender and afterNextRender functions which allow us to schedule a callback for the time exactly specified by its name. It’s useful when you want to read an element’s rendered dimensions right after it has been created.

SSR

Now, the Angular team is also focusing on the SSR and has introduced the hydration in the developers preview. This makes Angular behave closely to Next.js when the DOM is loaded and then becomes “alive”. Before that, the whole app would “blink” as the whole DOM structure got removed and re-created on the client when the app loaded.

Another great addition is the incorporation of the SSR package into the Angular making it easier to spin a dev server with SSR which should come in v17.

Dynamic components

In the old times, when we wanted to create a component dynamically we used to add a component to the entryComponents array, create its factory and only then attach the component to a container. Furthermore, if you needed to pass it input properties you would have to store the instance of the component in a variable, assign the values, and trigger change detection if you are using OnPush. But that still would not trigger the ngOnChanges .

Now, you don’t need to have the entryComponents array thanks to the Ivy rendering engine. You don’t need to create a factory, you can create a component straight away. The setting of the inputs became way easier. We have a setInput method on the ComponentRef which will trigger the change detection and corresponding lifecycle hooks! How to use it you can read in the article from Netanel Basal.

These and many more changes have happened just in recent years while the v16 is the biggest release ever. It truly feels like a revolution in Angular development. What a great time to live in!

--

--

Sergey Gultyayev

A front-end developer who uses Angular as a main framework and loves it