Forem: Ahmed Moustafa

Exploring Angular 17: A Glimpse into the Future of Web Development - Part 3

Ahmed Moustafa — Sun, 12 Nov 2023 20:35:46 +0000

In the third installment of our Angular 17 series, we delve into the transformative changes that shape the developer experience. Building on the groundbreaking Native Control Flow and Deferrable Views introduced in previous blogs, this post navigates through key evolutions in Angular CLI, moving to esbuild, and the powerful Signals mechanism.

Angular CLI Enhancement

Angular CLI undergoes notable changes in Angular 17, streamlining the development process. We explore how these changes enhance modularity, maintainability, and scalability, reflecting Angular's commitment to developer-friendly tools.

Angular 17's Simplifies SSR

With Angular 17, the process of integrating Angular Universal into your application has undergone a significant enhancement. Instead of the previous workflow that involved installing Angular Universal separately after creating a new application, Angular 17 streamlines the setup process.

Now, when you initiate a new Angular application using the ng new command, Angular 17 introduces a prompt during the application creation process. This prompt specifically asks whether you want to include Server-Side Rendering (SSR) in your application. This enhancement simplifies the integration of Angular Universal, allowing you to make this crucial architectural decision right at the beginning of the project setup.

Angular also introduced the new @angular/ssr package. This package serves as a replacement for the previous @nguniversal/express-engine package, offering equivalent functionality in a more streamlined manner. Notably, the @angular/ssr package stands out for its smaller size, enhanced speed, and improved usability. This evolution represents a commitment to refining and optimizing the Server-Side Rendering (SSR) capabilities within Angular, ensuring that developers can harness this powerful feature with greater efficiency and ease in their projects.

ng add@angular/ssr package

By incorporating this streamlined approach, Angular 17 ensures that developers can seamlessly choose to leverage the benefits of SSR from the outset, aligning with best practices for building modern, performant web applications. This improvement not only enhances the developer experience but also reinforces Angular's commitment to providing efficient tools and workflows.

Standalone components by default

The Angular CLI has adapted its default behavior to align with a component-centric approach. Now, when developers use the ng generate command, the Angular CLI automatically generates standalone components by default. This shift indicates a strategic move towards emphasizing components as the fundamental building blocks, placing them at the forefront of Angular development.

Angular 17 Unleashes esbuild

Angular 17 marks a significant leap forward in its build system, introducing a cutting-edge, esbuild builder that brings substantial performance improvements. This revamped builder, now automatically activated for new applications, boasts an impressive speed boost—up to 87% faster for hybrid rendering and 67% faster for client-side rendering compared to its predecessor.

Among its key features, the new builder embraces a modern output format using ECMAScript Modules (ESM), leveraging dynamic import expressions to facilitate efficient lazy module loading. This advancement not only aligns with contemporary JavaScript standards but also enhances the development experience for Angular users.

For existing applications, adopting the esbuild-based builder is a straightforward process. Developers need to make a simple adjustment in the angular.json file, specifying the esbuild builder for the build architect. This ensures that older applications can take advantage of the enhanced performance and features brought by the new build system.

...
"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:browser-esbuild",
...

In essence, Angular 17's revamped build system underscores the framework's commitment to staying at the forefront of web development technology. The introduction of the esbuild-based builder not only accelerates build times but also introduces a modernized development experience, setting the stage for more efficient and feature-rich Angular applications.

Signals are now stable

Indeed, the stability of Signals in Angular 17 marks a pivotal advancement in the framework's approach to tracking data changes. Initially introduced as a developer preview in Angular 16, Signals have now evolved into a stable feature, offering developers a more efficient alternative to traditional change detection mechanisms.

Signals represent a groundbreaking paradigm shift in the way Angular applications handle and track changes to data. Their efficiency lies in their ability to precisely detect and propagate changes, minimizing unnecessary checks and improving overall application performance.

By leveraging Signals, developers gain a powerful tool for optimizing the performance of their Angular applications. The stability of Signals in Angular 17 underscores the framework's commitment to providing cutting-edge features that not only enhance developer productivity but also contribute to the creation of high-performing and responsive web applications.

Changes in Signals Behavior Unveiled in Angular 17

The refined behavior of Signals in Angular 17 represents a significant advancement in change detection efficiency. Unlike the traditional approach, where changes to data-bound elements trigger marking of all parent components as dirty, Signals in Angular 17 take a more targeted approach. Specifically, when a change occurs in a data-bound Signal, only the directly affected components—those that explicitly bind to this Signal—are marked as dirty.

This departure from the conventional methodology results in more granular and focused change detection. Notably, this behavior aligns seamlessly with the OnPush change detection strategy, offering substantial performance improvements. By reducing the scope of marked components to only those impacted by the Signal, unnecessary checks and updates are avoided, resulting in a more efficient and responsive application.

Enhanced Diagnostics for Signal

Angular 17 introduces a diagnostic feature aimed at improving code quality and catch potential issues. Specifically, a new diagnostic has been implemented to issue a warning if a getter call is overlooked when reading Signals in templates. This enhancement is designed to bring attention to situations where the absence of a necessary getter call might lead to unintended behavior or incomplete data retrieval.

By providing a warning in such scenarios, Angular 17 promotes best practices and helps developers identify and rectify potential oversights early in the development process. This proactive approach not only aids in preventing runtime errors but also contributes to a more robust and reliable codebase.

As we conclude this exploration of Angular 17's evolution, stay tuned for our next and final post in the series. In the upcoming installment, we'll unravel the remaining features of Angular 17, providing a comprehensive overview of the framework's latest advancements. Join us as we continue to uncover the cutting-edge capabilities that Angular 17 brings to the forefront of web development.

Exploring Angular 17: A Glimpse into the Future of Web Development - Part 2

Ahmed Moustafa — Thu, 09 Nov 2023 12:49:16 +0000

Delving further into our exploration of Angular 17 and its latest features, let's build upon our previous discussion about control flows and their practical applications, as outlined in the last blog post. Today, our focus shifts to the concept of defer loading. With Angular's known lazy loading modules in routes, a new avenue has opened up for developers: lazy loading components using the @defer block and its associated tools. The question now becomes, how can we leverage this capability effectively? In this blog, we will guide you through a step-by-step process, providing a comprehensive introduction to this powerful technique.

Block Types: Exploring Varieties and Use Cases

Angular 17 introduces a diverse array of block types, each serving unique purposes in optimizing development workflows. In this section, we will delve into each block type, examining their individual characteristics and discerning the ideal scenarios for their application. By understanding the nuances of these block types, developers can make informed decisions about their usage, ensuring efficient and effective implementation within their projects. Let's explore the intricacies of each block type and unravel the best practices for their incorporation.

The Defer Block: Unleashing Asynchronous Loading

One of the standout features introduced in Angular 17 is the Defer block, a powerful tool designed to enable lazy loading of content based on specific actions or events. This versatile block type facilitates the loading of components, directives, and other elements when needed, enhancing the overall performance of Angular applications. The Defer block, by its nature, ensures that its contents are loaded asynchronously, streamlining the user experience and optimizing resource utilization.

Usage of the Defer block is straightforward and intuitive. Developers can employ it as demonstrated below:

@defer (on idle) {
  <h1>Welcome To Page</h1>
}

By embracing the Defer block, developers can dynamically load content, enhancing the responsiveness of their applications and delivering seamless user interactions. Its ability to load components and directives asynchronously marks a significant stride in Angular's evolution, empowering developers to create high-performance, user-friendly web applications.

Defining Defer Block Triggers:

Conditional Logic

Within the realm of Defer blocks, developers have the flexibility to implement conditional loading using two distinct triggers: 'on' and 'when'. Each trigger serves a unique purpose, providing granular control over when the block content should be loaded.

The 'when' condition comes into play when developers want to load the block content based on the evaluation of a specific variable. By harnessing the power of 'when', developers can dynamically determine the loading behavior, aligning it with the variable's state. This approach ensures that content is loaded precisely when the predetermined conditions are met, optimizing the application's performance and responsiveness.

Incorporating these conditional triggers within Defer blocks empowers developers to create dynamic and context-aware loading scenarios. Whether it's based on user interactions or specific variable states, the conditional triggers 'on' and 'when' provide a nuanced approach to content loading, enhancing the overall user experience. This level of flexibility represents a significant enhancement in Angular 17, enabling developers to craft highly adaptive and responsive web applications.

In this scenario, let's consider a practical example where we aim to display a header element after a delay of 3000 milliseconds. To achieve this, we introduce a variable called showWelcome, which we set to true after the specified delay. Leveraging the power of the Defer block with the 'when' condition, we can conditionally render the element when the showWelcome variable evaluates to true.

export class AppComponent {
  showWelcome = false;

  constructor(){
    setInterval(() => this.showWelcome = true, 3000);
  }
}

In the HTML template, we utilize the Defer block with the 'when' condition to dynamically display the header element based on the state of the showWelcome variable:

@defer (when showWelcome) {
  <h1>Welcome To Page</h1>
}

let's dive deeper into the versatile triggers offered by the 'on' condition within the Defer block. The 'on' condition provides developers with a plethora of options, allowing for highly customized and interactive user experiences. Here, we will explore the diverse ways in which the 'on' condition can be utilized

on idle: The 'on idle' condition is a strategic trigger within the Defer block, specifically designed to capitalize on moments when the browser is not preoccupied with high-priority tasks. This condition activates content loading during periods of low activity, ensuring that resources are utilized efficiently.

@defer (on idle) {
  <h1>Welcome To Page</h1>
}

on viewport: The 'on viewport' condition introduces a dynamic loading mechanism within the Defer block, designed to enhance user experience by optimizing resource allocation. This trigger is activated when the user scrolls to the specific area on the web page where the block is intended to be visible. Upon detecting the user's interaction through scrolling, the block is then loaded, ensuring that content is rendered precisely when it becomes visible to the user.

@defer (on viewport) {
  <h1>Welcome To Page</h1>
}

on interaction: The 'on interaction' condition within the Defer block introduces a nuanced approach to content loading, focusing on user engagement as the primary trigger. When applied, this condition detects user interactions with the @placeholder block content. In practical terms, in this case the @placeholder is a required block.

@defer (on interaction) {
  <h1>Welcome To Page</h1>
}
@placeholder{
  <button>Show Welcome</button>
}

on hover: The 'on hover' condition within the Defer block offers a loading mechanism that responds to user behavior. Specifically, this trigger activates the loading of content when the user hovers over the designated @placeholder block content. In this case the @placeholder is a required block.

@defer (on hover) {
  <h1>Welcome To Page</h1>
}
@placeholder {
  <button>Show Welcome</button>
}

on immediate: The 'on immediate' condition within the Defer block represents an instantaneous loading trigger that comes into effect as soon as the web page finishes loading. This condition ensures that designated content within the Defer block is loaded promptly and efficiently, minimizing any delays in presenting essential information to users.

@defer (on immediate) {
  <h1>Welcome To Page</h1>
}
@placeholder {
  <button>Show Welcome</button>
}

on timer(amount): The 'on timer(amount)' condition within the Defer block introduces a sophisticated loading strategy based on precise timing. When applied, this trigger initiates the loading of content once a specified timer reaches completion.

@defer (on timer(200ms)) {
  <h1>Welcome To Page</h1>
}

`@placeholder` Block: Seamless Content Presentation for a Polished User Experience

In Angular 17, the @placeholder block emerges as a key feature, addressing the challenge of displaying content in scenarios where the defer block content is not immediately visible. Unlike the defer block, which loads content conditionally, the placeholder block ensures that a designated content is displayed in place of the defer block until it becomes visible. This approach eliminates any empty spaces or absence of content, providing users with a smooth and uninterrupted browsing experience.

The @placeholder block accommodates a wide range of DOM nodes, allowing developers to choose content that best suits the context of their applications. Importantly, the content within the placeholder block is eagerly loaded, guaranteeing swift presentation to users without noticeable delays.

Moreover, the placeholder block includes an optional parameter: 'minimum'. This parameter defines the minimum duration for which the placeholder content should be displayed before transitioning to the defer block content. By specifying this minimum time, developers can prevent flickering effects, ensuring a stable and visually appealing transition between the placeholder and defer block content.

@defer (on hover) {
  <h1>Welcome To Page</h1>
}
@placeholder (minimum 10s) {
  <h1>Loading Page</h1>
}

`@loading` Block: Ensuring Smooth Transitions and User Experience

In Angular 17, the @loading block proves invaluable for managing content transitions, especially when waiting for the defer block to be triggered. Similar to the placeholder block, the loading block serves as an interim solution, displaying content until the defer block content becomes available. This approach prevents users from encountering empty or unresponsive spaces, ensuring a seamless and engaging user experience.

The @loading block offers enhanced flexibility with two optional parameters: 'minimum' and 'after'. The 'minimum' parameter defines the minimum duration for which the loading block should be displayed before transitioning to the content of the defer block. This duration ensures a stable display period, mitigating any flickering effects that might occur during rapid transitions.

Additionally, the 'after' parameter allows developers to set a threshold time. If the defer block content takes longer to load than the specified 'after' duration, the loading block should be visible, indicating to users that the application is still processing their request. This deliberate delay prevents premature transitions, maintaining a consistent user interface and preventing disruptive flickers.

@defer (on timer(200ms)) {
  <h1>Welcome To Page</h1>
}
@loading (after 1s; minimum 100ms) {
  <h1> Loading Page</h1>
}

`@error` Block: Handling Errors with Grace and Precision

In the intricate landscape of web development, errors can occasionally disrupt the seamless flow of content loading. To address these hiccups, Angular 17 introduces the @error block, a versatile tool designed to handle errors gracefully and provide users with meaningful feedback in case of loading failures.

The @error block steps in when errors occur during the loading process of the defer block's content. In situations where the intended content encounters issues—such as network problems, server unavailability, or other unexpected errors—the @error block ensures that users are presented with appropriate, user-friendly content rather than facing a blank or confusing interface.

Developers can craft custom error messages or display helpful instructions within the @error block, guiding users on how to proceed or providing context about the encountered issue. By doing so, developers enhance the user experience, transforming potential frustrations into opportunities for user engagement and understanding.

@defer (when showWelcome===welcomeMessage) {
  <h1>Welcome To Page</h1>
} 
@placeholder (minimum 10s) {
  <h1>Loading Page</h1>
}
@error {
  <h1>Error While Loading Page</h1>
}

Prefetching with Defer: Optimizing Resource Readiness

Angular 17 introduces a powerful feature in defer scenarios: prefetching. This functionality enables developers to proactively preload the necessary resources required for the defer block before they are actually needed. By doing so, applications can ensure that these resources are readily available, minimizing loading times and enhancing overall performance.

Prefetching operates seamlessly, employing familiar triggers such as 'on' and 'when', mirroring their usage in defer blocks. This consistency in triggers streamlines the development process, allowing developers to apply the same logic and conditions used in defer blocks to prefetching scenarios.

By strategically prefetching resources, developers can anticipate user interactions, loading content in advance to create a responsive and fluid user experience. This approach ensures that users encounter minimal delays when interacting with various elements, fostering a sense of immediacy and enhancing overall satisfaction.

@defer (when condition; prefetch when otherCondition) {
  <h1>Welcome To Page</h1>
}

@defer (when condition; prefetch on timer(1s)) {
  <h1>Welcome To Page</h1>
}

In the dynamic realm of web development, Angular 17's Defer blocks emerge as a game-changing solution, revolutionizing how content is loaded and interactions are handled. By leveraging an array of triggers such as 'on', 'when', and specialized conditions like 'on hover' and 'on viewport', developers can craft intuitive, responsive, and user-friendly applications. The introduction of placeholders, loading blocks, and error blocks further refines the user experience, ensuring seamless transitions and robust error handling. Additionally, Angular 17's prefetching capabilities enable proactive resource loading, minimizing delays and enhancing overall performance. Stay tuned for the next blog, where we will delve deeper into the remaining features of Angular, promising an exciting journey into the future of web development.

Exploring Angular 17: A Glimpse into the Future of Web Development - Part 1

Ahmed Moustafa — Tue, 07 Nov 2023 09:08:21 +0000

In the ever-evolving world of web development, staying updated with the latest technologies and frameworks is crucial. Angular continues to redefine the way developers build web applications. With Angular 17 on the horizon, set to be released in the week of 06-11-2023, according to the official Angular documentation, the community is abuzz with anticipation. In a recent statement, Minko Gechev, from the Angular dev team, expressed his excitement, saying,

Angular 17 will have the highest qualitative impact on DevEx we've ever delivered!

He highlighted three groundbreaking features expected to reshape the developer experience:

Deferrable Views
Native Control Flow
Escuild and Vite

In this blog series, we will look at these features in-depth, exploring how they have transformed in Angular 17 and how developers can leverage them to create powerful web applications.

Angular control flow – Part 1

Angular 17 is knocking on the door, promising a bunch of groundbreaking features that will redefine the way developers interact with the framework. One of the most anticipated enhancements is the introduction of Angular Control Flow. This article will dive into what this feature entails and explore how it transforms our approach to writing conditional statements in Angular applications.

The Evolution of Conditional Statements

Remember the days of *ngIf, *ngFor, and *ngSwitch? Well, brace yourselves because Angular 17 is shaking things up. Angular Control Flow introduces a paradigm shift, allowing developers to write if, for, and switch statements as blocks directly in HTML, thanks to what Angular calls the "@-syntax."

Angular community developers might recall an alternative syntax proposed in the RFC called the "#-syntax." However, after conducting a community survey, Angular opted for the widely preferred "@-syntax."

But why angular decided to change to this syntax? This question is answered in the angular RFC. They explained that the review of the development experience highlighted microsyntax-based control flow as having significant weaknesses compared to syntaxes in other frameworks. As for the timing and why now, This is the summery about what they have in the RFC:

In our ongoing efforts to implement the Signals RFC, we recognized that the existing control flow directives designed for zones would not function in applications without zones. To solve this, we needed a new reactive control flow system for zoneless applications. Although we contemplated modifying the existing directives to support zoneless applications, we dismissed this option due to the risk of unintentionally breaking every existing Angular application, given their dependency on these directives. Additionally, attempting to accommodate both signal and zone-based patterns within a single directive was deemed too complex and inefficient to manage. We also considered creating new reactive control flow directives exclusively for signal components but decided against it to avoid unnecessary distinctions between signal and zone components. Consequently, we opted for a different approach: developing a built-in control flow system for templates. This solution serves the dual purpose of supporting zoneless and signal-based applications while also addressing long-standing user experience issues associated with structural directives.

Configuring Angular Control Flow

To utilize the new control flow, a minor tweak in the tsconfig.json file is required. Add the following property under angularCompilerOptions:

{
  "angularCompilerOptions": {
    ....
    "_enabledBlockTypes": [
      "if", "switch", "for"
    ]
  }
}

Exploring Control Flow in Action

If-Else Statement: In previous versions, *ngIf served its purpose but had limitations. With Angular 17, the if-else statement becomes more intuitive and readable.

@if (condition){
  <div>The condition is true</div>
} @else if (condition2){
  <div>The second condition is true</div>
} @else {
  <div>Both conditions are false</div>
}

For Loop Statement: The new NgFor introduces the @for block. Remember to include a trackBy parameter. Additionally, you can use the @empty block to handle empty iterable.

<ul>
  @for (item of items; trackby item; let i = $index){
  <li>{{ item }}: {{ index }}</li>
  } @empty {
  <li>items is empty</li>
  }
</ul>

Switch-Case Statement: NgSwitch gets a cool upgrade with the @switch block. Handle your switch cases elegantly:

@switch (name) {
  @case ('foo') {
    <span>name: foo</span>
  }
  @case ('bar') {
    <span>name: bar</span>
  }
  @case ('foo bar') {
    <span>name: foo bar</span>
  }
  @default {
    <span>unknown</span>
  }
}

Migrating my project to the new control flow

Transitioning from our old code to Angular's new features can be daunting. Thankfully, the Angular team has our back. They've created a helpful migration script, just like they've done for other features in the past. The following script is based on the guidelines provided in the pull request available as of the writing of this article. So, fear not; we've got a clear path to follow!

ng generate @angular/core:control-flow

Angular 17's Control Flow feature marks a significant leap forward in Angular's evolution. By simplifying conditional statements, developers can enhance readability and maintainability in their applications. With this powerful addition, Angular continues to empower developers, making complex tasks more straightforward and more intuitive. Embrace the future of Angular development with Control Flow and unlock new possibilities in your web applications.

Stay tuned for more insights into Angular 17 and the exciting innovations it brings to the world of web development!

Angular Budgets: Keeping Your Application Performant and Responsive

Ahmed Moustafa — Wed, 17 May 2023 20:45:17 +0000

Get ready to dive into the wacky world of Angular budgets! In this hilariously informative blog post, we'll be exploring the budgetary roller coaster that awaits every Angular developer. From the penny-pinching 'bundle' budget to the resource-hungry 'maximum' budget, we'll unravel the mysteries behind each budget type. Hold onto your funny bones as we navigate through budget limitations, busting them wide open with clever tricks and tips. It's time to turn those budget blues into budget LOLs as we embark on this comedy-filled adventure into the realm of Angular budgets!

Angular: More Than Just Geometry, It's the Hipster's Choice for Web Apps!

Angular, the superstar of web development, has stolen the hearts of developers worldwide with its ability to build fancy web applications. But hey, as these apps grow bigger and more complicated, they can start acting like divas, causing sluggish response times and giving users a "meh" experience. Imagine waiting forever for a website to load - it's like watching paint dry, but way less exciting!

Why The Need for Speed?

Research shows that people have the patience of a goldfish when waiting for websites to load. They want it fast, like flash-fast! Slow-loading sites are a recipe for disaster, causing users to throw tantrums and abandon ship faster than you can say "JavaScript." So, to keep users engaged and prevent them from unleashing their inner Hulk, it's crucial to turbocharge your Angular applications for speed and performance.

Show Me the Money

Enter the superhero called Angular Budgets! They're like those strict teachers who keep things in check. These budgets allow developers to set limits for different aspects of their app, such as size, performance, and responsiveness. Think of it as setting boundaries for your code, like a parent telling their kids, "No, you can't have ten extra scoops of ice cream!"

One major culprit for slow websites is those chunky JavaScript bundles. With Angular budgets, you can put them on a diet! Developers can monitor and control the size of these bundles, preventing them from getting bloated and slowing down the app. It's like keeping your app on a treadmill, ensuring it stays fit and fast!

But wait, there's more! Angular budgets also act as a superhero sidekick for preventing performance issues. As your app grows and evolves, it may gain a few extra pounds, affecting its performance. With Angular budgets, you can be like a detective, constantly tracking your app's size and performance metrics. If it starts acting up, you'll catch it red-handed and take the necessary measures to whip it back into shape.

But how to know my current bundle size?

To determine your current bundle size in an Angular application, you only need to build your Angular application.

ng build 
or 
ng build --prod

And here you go, a nice table that contains our bundles.

It's time to dive into the wild and wacky world of bundle files! We all know that understanding these bundles is the secret sauce to optimizing our app's performance, and it's like cracking a code that unlocks the magical powers of speed and efficiency.

Like a Box of Chocolates, Except They're Bundles!

Main Chunk:
The granddaddy of them all! This chunk holds the fundamental logic and functionality of our app, and it's like the boss who decides how the initial view gets rendered. But fear not; we have tricks up our sleeves like lazy loading and code splitting to make this chunk lean and mean. Say goodbye to sluggish loading times!
Polyfills Chunk:
The superhero of old browsers! This chunk swoops in during the production build to ensure compatibility with those ancient browser beasts. It's like a bridge that fills the gaps in browser capabilities, making our app work seamlessly across different environments. No browser left behind!
Runtime Chunk:
The master of ceremonies at runtime! This chunk plays a critical role in bootstrapping and initializing our app, and it's like the glue that holds all the other code together. To boost performance, we can slice and dice this chunk into smaller, bite-sized pieces. Think of it as serving an app buffet with manageable portions. Yum!
Styles Chunk:
The fashionista of our app! This chunk gathers all the CSS styles used in our Angular masterpiece. It's the second-largest file in the production build, but no worries, we have style optimization tricks up our sleeves. We'll shake those trees and purge unused styles, making this chunk slimmer than a supermodel on a diet. Hello, fast loading times!
So, fellow developers, armed with the knowledge of these quirky chunks and their sizes, we can work our magic. It's time to optimize our Angular app and achieve performance greatness! But wait, there's more! We have a secret weapon called webpack-bundle-analyzer. This tool lets us visualize our bundle sizes in a way that would make even Picasso jealous. We'll unravel the mysteries behind our bundle composition and unlock valuable insights. Get ready to analyze like never before!

Budgets Under the Microscope

Now, let the bundle bonanza begin as we embark on an epic journey of optimizing our Angular bundle sizes. Together, we'll create a performance masterpiece that will make users go, "Wow!" So, strap on your developer capes and let's rock those bundles!

To utilize webpack-bundle-analyzer effectively, we need to begin by installing it. Follow these steps to incorporate this tool into your Angular project:

Open your terminal or command prompt and navigate to your project's root directory.
Execute the following command to install webpack-bundle-analyzer as a development dependency:

npm install --save-dev webpack-bundle-analyzer

Then we can run another build with a flag —stats-json

ng build --stats-json 
or 
ng build --prod --stats-json

After running this command a cool file will be generated in the dist folder called stats.json this file contains the data for all the dependencies that are being used by our application. To visualize it we can run this command.

webpack-bundle-analyzer ./dist/${project-name}/stats.json

And voila you will see this nice view of our project bundles.

Alrighty, let's dive into the bundle fun! Check it out, my friends. The main bundle is strutting its stuff at a whopping 237.46 kb, with a crew of 91 cool modules. Now, picture this: our talented developer decides to add some pizzazz to our app with the one and only Angular Material. They go all out and bring in the MatBadgeModule and the MatDatepickerModule. Oh yeah, our app is dressed to impress!

But how will our stats look like? Let's run the build again and check how it looks like.

Now, let's take a look at our main bundle. It has grown to a size of 318 kb, accompanied by a team of 134 modules. Don't worry, though - we're still within acceptable limits, and all these modules are being put to good use. We're keeping things balanced and staying on track with our budgets.

But hey, hold on to your hats, because there's a twist in our story! Our design got a makeover, and our clever developer decided to swap out the date picker for a simple text box. The MatFormFieldModule came into the picture to add some flair to our new text box. However, in the rush of excitement, our developer forgot to remove the MatDatepickerModule from our app.module imports. Oops, we all make mistakes!

So, let's take a closer look at our stats and see what happened. As we dig into the numbers we found that we are at 397 kb, we might notice a little surprise waiting for us. Ah, there it is! The MatDatepickerModule, still hanging out in our imports, even though it's no longer partying in our HTML. It's like an eager guest who missed the memo that the date picker moved out of the app. Let's give it a gentle reminder to find its way back home.

Making Your App Run Faster Than a Caffeine-Infused Unicorn!

Alright, let's stop here and approach this bundle situation with a relaxed vibe. It's time to do some detective work and figure out why this is happening and how we can solve it. We all know that projects can vary in size, and sometimes it feels like making the main bundle smaller is as tricky as finding a unicorn in the wild. But worry not, my friends, because we've got some handy solutions up our sleeves.

First up, we've got code splitting. It's like breaking our code into bite-sized pieces, making it more digestible. By doing this, we can keep our main bundle in check and improve its performance. It's like serving smaller portions of code goodness.
Next, let's give a shout-out to tree-shaking. No, it's not about violently shaking trees (although that would be quite the spectacle). It's about shaking off any unnecessary code branches, like shedding those extra layers in winter. We want our bundle to be lean and efficient, so we'll get rid of anything that's not pulling its weight.
Now, it's time to optimize our dependencies. Think of it as a mini makeover for our code. We'll tidy things up, make sure our dependencies are playing nicely together, and trim any excess baggage. It's like decluttering our code closet.
And guess what? We've got a superhero called the bundler optimizer. It swoops in to save the day, making our bundle shine brighter than a disco ball. This magical tool knows all the tricks to optimize our code and make it perform like a rockstar. It's like having a secret weapon in our coding arsenal.
Last but not least, let's talk about minimizing those Angular polyfills. They're like the support crew for older browsers, ensuring our app can strut its stuff across different platforms. But hey, let's keep them light and nimble, just enough to get the job done without stealing the spotlight.
Now that we've got a handle on budgets, bundles, and sizes, let's ease into the world of configuration. It's time to adjust the settings and find that sweet spot for our projects. So grab a cup of your favorite beverage, put on some relaxing tunes, and let's dive into the art of configuration. It's all about finding that perfect harmony between our code and the magic that makes it run smoothly. Let's do this with a chilled-out mindset!

Now How can I change the budget limits for my project?

To configure angular budgets you need to open the angular.json file of your project.

"architect": {
…        
"build": {
          "configurations": {
            "production": {
              "budgets": [
                {
                  "type": "initial",
                  "maximumWarning": "500kb",
                  "maximumError": "1mb"
                },
                {
                  "type": "anyComponentStyle",
                  "maximumWarning": "2kb",
                  "maximumError": "4kb"
                }
              ],
            },
    }
}

Alright, fellow adventurer! Let's dive into the marvelous world of Angular budgets and unravel the mysteries of different budget types. It's like exploring a treasure trove filled with exciting size measurements that'll make your coding heart flutter with joy.

The Wild Variety Show of Angular's Budget Types!

bundle: It's like putting a size tag on a specific bundle, so you know exactly how big it is. It's like giving each bundle its own fashionable outfit and making sure it fits just right..
Initial: Think of it as the VIP of sizes, representing the js file that's essential for bootstrapping your application. It's the star of the show, the one that gets everything started. Make sure it's not too big, or else your app might take longer to get off the ground..
allScript: the size of all your application scripts combined. It's like a scrumptious buffet of code, where you can keep an eye on the total size of your script feast. Watch out for any code gluttony!
all: the size of your entire application. It's like weighing your app on a cosmic scale and seeing how it measures up. Keep an eye on this one to make sure your app doesn't become too heavy to handle.
anyComponentStyle: It's the size of any component's stylesheet, like a fashionista's wardrobe. Make sure those styles are looking fabulous without weighing down your app.
anyScript: It's like a wildcard, capturing the size of any of your precious scripts. It's like herding all the code cats and keeping them in check.
any: the size of any file that tickles your coding fancy. It's like a magical size measurement that can apply to anything you desire. Keep an eye on this one if you want to monitor the sizes of all things great and small.

With these marvelous budget types, you have the power to track and control the sizes of anything your heart desires. Set your desired sizes for the warning and error cases, like setting the boundaries for your code playground. It's like being a size superhero, ensuring your app stays in tip-top shape. So go forth, my friend, and conquer those budgets with a sprinkle of coding magic!