Deferable Views, Page Load Improvements Coming to Angular

Angular version 17, set to launch Wednesday, will introduce a new framework primitive called @defer that will allow developers to lazily load parts of their view. There’s also a new logo and a new website for developers.

“Deferrable views are a powerful tool, and it can be used to reduce the initial bundle size of your application, or even defer some of the heavy components that you might have in your page but are not immediately loaded or shouldn’t be immediately loaded,” said Simona Cotin, engineering manager for Google’s Angular team, during last week’s virtual JetBrain JavaScript Day.

Right now, developers can defer load entire parts of the application and configure specific routes to be lazy loaded. As a result, the application will be split into smaller chunks that will be lazily loaded when navigating to that specific route, Cotin explained.

“And all of this works out of the box today with Angular and lots of applications in production already use these mechanisms for lazy loading and improving their application performance. But we believe we can do more,” she said.

Deferred Loading as Part of Core Framework

Lazy loading of individual components is currently achievable by dynamic imports and a component outlet, but that can be complex and error-prone, she added. To make it better, the Angular team is introducing “an ergonomic and holistic approach to deferred loading that’s part of the core framework,” she said.

“So this year, we introduced a new framework primitive that’s called @defer that will enable developers to easily lazily load parts of their views,” she said.

It’s currently under the developer preview as part of version 17. @defer is now part of the core framework and deferred loading works across both client-side and server-side rendering, she added. It can be used in a component’s template to defer the loading of some dependencies within that template, Cotin said.

“To use this feature, you can declaratively wrap a section of your template in a @differ block, which also specifies the loading condition,” Cotin said.

She showed an example of defer loading a calendar component. The compiler extracts its content and lazy loads it when a particular trigger is fired, she explained. Developers can also define a timer so that the lazy loading happens after a specified duration, she said.

Deferrable views can be used in a component’s template to defer the loading of some dependencies within that template, she said. To use this feature, you can declaratively wrap a section of your template in a @differ block, which also specifies the loading condition, she said.

“You might also notice that we have a placeholder block, which will be displayed until the @differ trigger is met. We also have an interaction trigger and this basically listens to when the user interacts with the specified element through their click or key down events,” she said. “By default, the placeholder will actually act as the interaction element.”

Alternatively, developers can also specify a template reference variable as the element that triggers the interaction so, in her example, there’s a button and whenever the button is clicked, then it will start lazy loading the calendar component, she said. The variable that is referenced in the button is passed in as the parameter on the interaction trigger, she added.

There are other built-in triggers, including hover and the ability to define a timer that will trigger the lazy loading after a specified duration. Jessica Janiuk, a senior software engineer at Google, listed the options during a Monday Angular team webcast that covered some aspects of the upcoming release, as well as announcing a new Angular.dev website and new logo.

@defer is available under the developer preview as part of version 17.

Improving the Initial Load with Hydration

Another way to improve initial page load time is actually to do less on the client and more on the server, Cotin said. In versions 16 and 17, the Angular team has made “significant improvements to server-side rendering and static site generation or pre-rendering,” she said, in order to enable more developers to actually consider hybrid rendering their applications.

“One of the first steps in doing that was to enable full app hydration, and for those of you that aren’t familiar with hydration, hydration is the process that restores the server-side rendered application on the client,” she said. “This includes things like reusing the server side rendered DOM structured, processing the application state, transferring application data that was already retrieved on the server and any other processes that might be relevant.”

In version 16, they focused on implementing a better hydration solution for Angular that implements all of these best practices. In V 17, the team marked full app hydration as stable, so it’s exiting developer preview.

“We’re enabling hydration by default, when you use server-side rendering or a hybrid rendering,” Cotin said. “You can enable full app hydration in existing applications as well by adding client hydration to the bootstrap of your application. And as I mentioned, new hybrid apps will have this enabled by default.”

Hybrid Projects

The team also has made it easier to create a hybrid project: Developers will be asked when creating a new project if they’d like to enable server-side rendering and static site generation. The Angular command line interface will do all the work to scaffold the project with all of the necessary configurations, she said.

“The new hybrid projects also come with a new application builder, which is configured with pre-rendering and SSR. And my absolute favorite part of this new application builder, particularly for the server-side rendering and pre-rendering part, is that it drastically simplifies configuration,” she said.

Cotin then demonstrated that she was able to remove tens of lines of code worth of configuration from her Angular JSON file by moving from version 16 to version 17.

A Faster Builder

The application builder is built on top of ES Build as a bundler and Vite for dev serving. ES Build is also marked stable in the v17 and it will now become the default builder for any new project, she said. Additionally, all new projects will be standalone by default. The Webpack builder will continue to be supported, however.

The new application builder is providing up to 67% faster build times, she added.

Cotin also introduced Angular’s new control flow with a new syntax the team is calling the @syntax, which proved a little more popular in surveys than the original Svelte-like syntax.

Cotin discussed some changes that may not ship in version 17, including Angular signals. (Sarah Drasner has created an explainer demo of Angular signals.)

“This is a system that granularly tracks how and where your state is used throughout your application and it allows the framework to optimize the rendering updates,” Cotin said.

For more on Signals and other changes to Angular, check out, “The Angular Renaissance: Why Frontend Devs Should Revisit It.”