You open your code editor, create an HTML table, and try to render one million rows. The browser freezes. The tab crashes. Your Monday just got worse.

You need to display large amounts of data in a grid without killing the browser. The trick is simple: don’t render what the user can’t see.

This is where virtual scrolling comes in. Instead of creating a DOM element for every single row, you only render the rows visible on screen, plus a few extra. The user scrolls smoothly through millions of records, each new batch loading in as needed, and the browser stays fast and responsive.

Let’s do it together! Today, we will build a Super Bowl Dashboard in Angular. We will see how to handle one million viewers using Progress Kendo UI for Angular Grid. We will start with a simple table, see why it fails and then fix it using virtual scrolling and server-side data fetching.

Let’s make this work in a real project.

Setting Up the Project

First, create a new Angular application by running the command:

ng new superbowl-dashboard

Navigate to the project:

cd superbowl-dashboard

Now install the Angular Grid. The ng add command handles dependencies and theme configuration for us:

ng add @progress/kendo-angular-grid --skip-confirmation

This installs the grid package and its peer dependencies and sets up the Kendo UI default theme.

Once the installation is done, we need to activate our Kendo UI license. This step removes the watermark and unlocks all the features.

Don’t have a license? Don’t worry! You can get a completely free trial with no credit card required, so you can follow along and build the dashboard without worrying about the watermark.

To do this, download the license key file from your Telerik account. Then, run this command inside your project folder:

npx kendo-ui-license activate

Because the Kendo UI Grid is so robust, it includes many features that can slightly increase the initial bundle size. We need to prevent Angular from throwing a “bundle initial exceeded maximum budget” error when we run or build an app. Open the angular.json file and increase the budgets config for the initial type to around 5MB for warnings and 10MB for errors.

Perfect! We have a fresh Angular project with Kendo UI Grid installed and styled. Now let’s generate our Super Bowl viewers’ fake data.

Generating One Million Viewers

Before we start with the grid, we need data. We’ll create a single service that handles everything: generating fake viewer data for client-side demos and simulating a paginated server API for server-side scrolling.

To create the service, open the terminal and run the following Angular CLI command:

ng g s services/viewer

First, we will define a simple Viewer interface so our grid knows what fields to expect. Then, our service will include a generateViewers method to create mock data, and a fetchPage method that simulates a paginated server API. We won’t use fetchPage right away, but it will be ready for when we implement server-side virtual scrolling later.

Don’t worry too much about the exact implementation of the helper methods; the main idea here is not how to generate fake users, but how to create a grid capable of supporting massive amounts of data without breaking a sweat!

Open src/app/services/viewer.ts and add the following:

import { Injectable } from "@angular/core";

export interface Viewer {
  id: number;
  username: string;
  watchTimeMin: number;
  isLive: boolean;
}

export interface PagedResult {
  data: Viewer[];
  total: number;
}

const ADJECTIVES = [
  "Swift",
  "Lucky",
  "Bold",
  "Chill",
  "Epic",
  "Happy",
  "Lazy",
  "Wild",
  "Cool",
  "Fast",
];

const NOUNS = [
  "Fan",
  "Eagle",
  "Tiger",
  "Bear",
  "Wolf",
  "Hawk",
  "Fox",
  "Lion",
  "Shark",
  "Bull",
];

@Injectable({ providedIn: "root" })
export class ViewerService {
  private readonly TOTAL_VIEWERS = 1_000_000;

  generateViewers(count: number, startId = 0): Viewer[] {
    const viewers: Viewer[] = [];

    for (let i = 0; i < count; i++) {
      viewers.push({
        id: startId + i + 1,
        username: `${this.randomFrom(ADJECTIVES)}${this.randomFrom(NOUNS)}${this.randomBetween(1, 9999)}`,
        watchTimeMin: this.randomBetween(1, 240),
        isLive: Math.random() > 0.08,
      });
    }

    return viewers;
  }

  /**
   * Simulates a server API call with pagination.
   * Uses a small delay to mimic real network latency.
   */
  async fetchPage(skip: number, take: number): Promise<PagedResult> {
    await new Promise((resolve) => setTimeout(resolve, 80));

    return {
      data: this.generateViewers(take, skip),
      total: this.TOTAL_VIEWERS,
    };
  }

  private randomFrom<T>(arr: T[]): T {
    return arr[Math.floor(Math.random() * arr.length)];
  }

  private randomBetween(min: number, max: number): number {
    return Math.floor(Math.random() * (max - min + 1)) + min;
  }
}

Each viewer has a fun auto-generated username (like SwiftEagle4821), their watch time and a live status. The fetchPage method is an async function that simulates a paginated API with a small delay to mimic network latency. We’ll use generateViewers first and come back to fetchPage later.

With our service ready, let’s see what happens when we try to render all these viewers at once.

The Problem: Rendering All Rows at Once

Let’s try to do it and experience the problem firsthand. Open src/app/app.ts and replace its content:

import { Component, inject, signal } from "@angular/core";
import { CommonModule } from "@angular/common";
import { ViewerService, Viewer } from "./services/viewer";

@Component({
  selector: "app-root",
  standalone: true,
  imports: [CommonModule],
  templateUrl: "./app.html", 
})
export class App {
  private viewerService = inject(ViewerService);
  viewers = signal<Viewer[]>([]);

  loadViewers(count: number): void {
    const data = this.viewerService.generateViewers(count);
    this.viewers.set(data);
  }
}

Now, let’s open our template file, src/app/app.html and add a few buttons for 1K, 10K and 100K viewers. These buttons will call our loadViewers() method to quickly generate different amounts of fake data.

Finally, we’ll use the <kendo-grid> component in our template. The key property to pay attention to is [data]="viewers()", which tells Kendo UI to read from our reactive signal and constantly display the list of viewers.

<h1>Super Bowl Viewers Dashboard</h1>
<p>Connected viewers: {{ viewers().length.toLocaleString() }}</p>

<div class="actions">
  <button (click)="loadViewers(1_000)">1K Viewers</button>
  <button (click)="loadViewers(10_000)">10K Viewers</button>
  <button (click)="loadViewers(100_000)">100K Viewers</button>
  <button (click)="loadViewers(1_000_000)">1M Viewers</button>
</div>

<div class="grid-container" style="height: 600px; overflow: auto;">
  <table border="1" style="width: 100%; border-collapse: collapse;">
    <thead>
      <tr>
        <th>#</th>
        <th>Username</th>
        <th>Watch (min)</th>
        <th>Live</th>
      </tr>
    </thead>
    <tbody>
      @for (viewer of viewers(); track viewer.id) {
      <tr>
        <td>{{ viewer.id }}</td>
        <td>{{ viewer.username }}</td>
        <td>{{ viewer.watchTimeMin }}</td>
        <td>{{ viewer.isLive ? 'Yes' : 'No' }}</td>
      </tr>
      }
    </tbody>
  </table>
</div>

Now we can run our app. Go to the terminal and execute the following command:

ng serve

This will start the local development server. Once it finishes compiling, open your browser and navigate to http://localhost:4200.

Click “1K Viewers” and it feels smooth. Click “10K Viewers” and you will notice a significant lag.

Now click “100K Viewers” … and watch the browser scream for help. The page will freeze, the scroll will be jumpy and you might even get the “Page Unresponsive” dialog.

We have seen the problem: standard HTML tables and simple loops cannot handle huge datasets. When you click the 1M Viewers button, the browser stops working.

OK, but how can we fix this?

The Solution: Angular Grid withVirtual Scrolling

If you read about Kendo UI, you know the Kendo UI Grid, but before we to start to use it, I want to explain “virtual scrolling.” Think of virtual scrolling like a camera moving over a big stadium. You only see the seats in the camera frame, maybe 50 seats. The stadium has 1,000,000 seats, but the camera doesn’t need to show all of them at once. It only shows what is visible.

Kendo UI Grid does exactly this with one property: scrollable="virtual". Let’s use it.

First, update your app.ts. We need to import KENDO_GRID and remove the CommonModule because the grid will handle everything now:

import { Component, inject, signal } from "@angular/core";
import { KENDO_GRID } from "@progress/kendo-angular-grid";
import { ViewerService, Viewer } from "./services/viewer";

@Component({
  selector: "app-root",
  imports: [KENDO_GRID],
  templateUrl: "./app.html", 
})
export class App {
  private viewerService = inject(ViewerService);
  viewers = signal<Viewer[]>([]);

  loadViewers(count: number): void {
    const data = this.viewerService.generateViewers(count);
    this.viewers.set(data);
  }
}

Now, let’s update src/app/app.html. We will replace the standard <table> with the <kendo-grid> component:

<h1>Super Bowl Viewers Dashboard</h1>
<p>Connected viewers: {{ viewers().length.toLocaleString() }}</p>

<div class="actions">
  <button (click)="loadViewers(10_000)">10K</button>
  <button (click)="loadViewers(100_000)">100K</button>
  <button (click)="loadViewers(1_000_000)">1M</button>
</div>

<kendo-grid
  [data]="viewers()"
  [height]="600"
  scrollable="virtual"
  [rowHeight]="36"
  [pageSize]="50"
>
  <kendo-grid-column field="id" title="#" [width]="70"></kendo-grid-column>
  <kendo-grid-column field="username" title="Username" [width]="180"></kendo-grid-column>
  <kendo-grid-column field="watchTimeMin" title="Watch (min)" [width]="110"></kendo-grid-column>
  <kendo-grid-column field="isLive" title="Live" [width]="70"></kendo-grid-column>
</kendo-grid>

Why Does This Work?

We added three important properties to the <kendo-grid> to make it fast:

1. scrollable="virtual": This tells Kendo UI: “Don’t create all the rows at once. Only create the ones the user can see right now.”
2. [rowHeight]="36": The grid needs to know exactly how tall each row is. This helps the grid calculate the scroll position correctly.
3. [pageSize]="50": This is how many rows Kendo UI keeps in the DOM. A good tip: set this to 3 times the number of rows visible on your screen.

Now, if you click the buttons, you will see that a page with 10,000, 100,000 or even one million viewers scrolls smoothly. The browser is fast because only ~50 rows are in the DOM at any time.

Kendo UI Grid does all the hard work for the rendering.

But there is one more problem. We fixed the rendering, but we are still loading one million records into the browser’s memory. For a real app, loading 1,000,000 records at once is a bad idea. It uses too much RAM and it is slow to start.

What if we want to show one million users in real-time without using all the RAM? Let’s use the final solution: Server-Side Data Fetching.

Server-Side Data Fetching with Endless Scrolling

Here’s the reality: the Super Bowl has 120 million viewers. We can’t load all of them into the browser at once. Instead, the grid should fetch data page by page as the user scrolls , loading only what’s needed, when it’s needed.

Kendo UI Grid supports this out of the box with the scrollBottom event. When the user scrolls to the bottom of the current data, the grid fires this event, and we simply fetch the next page and append it. Let’s build it!

Generate a new component by running the command in the terminal:

ng g c components/live-grid

Open src/app/components/live-grid/live-grid.ts and replace the content with:

import { Component, inject, signal, ChangeDetectionStrategy } from "@angular/core";
import { KENDO_GRID } from "@progress/kendo-angular-grid";
import { ViewerService, Viewer } from "../../services/viewer";

@Component({
  selector: "app-live-grid",
  imports: [KENDO_GRID],
  templateUrl: "./live-grid.html",
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class LiveGrid {
  private viewerService = inject(ViewerService);

  isConnected = signal(false);
  loading = signal(false);
  viewers = signal<Viewer[]>([]);
  pageSize = 1_000;

  connect(): void {
    this.isConnected.set(true);
    this.loadMore();
  }

  onScrollBottom(): void {
    if (this.loading()) return;
    this.loadMore();
  }

  private loadMore(): void {
    this.loading.set(true);
    
    this.viewerService.fetchPage(this.viewers().length, this.pageSize).then((result) => {
      this.viewers.update((current) => [...current, ...result.data]);
      this.loading.set(false);
    });
  }
}

The logic here is straightforward. First, connect() starts the process by fetching the initial data page using loadMore(). Then, whenever the user scrolls to the bottom of the grid, the (scrollBottom) event fires, triggering onScrollBottom() to fetch and append the next chunk of data to our viewers signal.

To make this work in the UI, we just need to set scrollable="scrollable" on our Kendo Grid to enable endless scrolling, and bind our loading signal to show a skeleton animation during the fetch.

Now let’s build the template in src/app/components/live-grid/live-grid.html to tie all of this together:

<h2>Live Server Feed</h2>
<p>Viewers: {{ viewers().length }}</p>

<button (click)="connect()" [disabled]="isConnected()">Connect to Live Feed</button>

@if (isConnected()) {
<kendo-grid 
    [data]="viewers()" 
    [height]="600" 
    scrollable="scrollable"
    [loading]="loading()"
    (scrollBottom)="onScrollBottom()">
    <kendo-grid-column field="id" title="#" [width]="70"></kendo-grid-column>
    <kendo-grid-column field="username" title="Username" [width]="180"></kendo-grid-column>
    <kendo-grid-column field="watchTimeMin" title="Watch (min)" [width]="110"></kendo-grid-column>
    <kendo-grid-column field="isLive" title="Live" [width]="70"></kendo-grid-column>
</kendo-grid>
}

Wire the component into the app. Update app.ts:

import { Component } from "@angular/core";
import { LiveGrid } from "./components/live-grid/live-grid";

@Component({
  selector: "app-root",
  imports: [LiveGrid],
  templateUrl: "./app.html",
})
export class App {}

And src/app/app.html:

<h1>Super Bowl Viewers Dashboard</h1>
<app-live-grid />

Run ng serve, open http://localhost:4200 and click “Connect to Live Feed.”

You’ll see the grid load the first 1,000 viewers. Now scroll down. When you reach the bottom, the grid fetches the next 1,000 viewers and appends them and the loading skeleton appears briefly while data is being fetched. Keep scrolling, and watch the viewers counter grow until it gets to 1,000,000. Yeah!!

Recap

We saw the problem: rendering thousands of rows at once makes the browser freeze. Then we added Kendo UI virtual scrolling with scrollable="virtual". This is the secret to showing large datasets without crashing.

Finally, we used server-side data fetching with the (scrollBottom) event. The grid loads data page by page. This keeps the memory usage low and the experience smooth.

In your next challenge don’t worry about the data, Kendo UI Grid makes it easy. With a few properties, your dashboard can handle millions of rows. ✌

Give it a try for free!

Try Kendo UI for Angular

Happy coding!

Source Code: https://github.com/danywalls/kendo-grid-large-app

I’ve been developing software for more than 15 years, and the industry never stops changing. Choosing a framework is a strategic decision that must fit the time we are building in.

Building apps in 2026 is very different from 2015, 2020 or even 2025. Today, picking a UI library is more complex than before. We are no longer just building simple “forms and tables”; we are building AI-powered experiences. As developers, we now work with AI agents like Cursor and Copilot, and our UI library must be ready for AI from day one.

The best Angular library does not just save time with CSS or provide basic typical components; it must provide components and tools to help AI and agents understand our code better, saving tokens, time and money for your company, and also help the entire team to work better.

But as always, the best way to explain the importance of this choice is to look at a real-world situation.

The Scenario

Imagine you were just hired by a startup. You must deliver a complex platform quickly to compete in the market, but your app is modern in the AI era, so it needs more than basic grids and buttons. It will also have complex calendars, real-time charts, chat interfaces and anything needed to perform in accordance with modern user expectations … and it needs to help our new teammates (AI coding agents) work better and faster.

In this situation, your UI library is not just about delivering on time. It is about providing a tool that can help you ship your project, support your team with very stable code and provide complex features so you don’t have to build everything from zero. You need a library that is already “AI-ready,” with components made for AI agents and chat interfaces.

I can tell you, from experience, picking the wrong library can mean months of extra work and watching your competitors launch while you are still fixing basic things.

Today, we are going to dive into each framework, showing its strengths and weaknesses, and finally my recommendation for each scenario.

1. Kendo UI for Angular

In the scenario we described, the Progress Kendo UI for Angular component library is your best all-in-one framework. When the deadline is close and the project is high-priority, you do not have time to build everything from scratch.

Why Kendo UI Is the Best Tool for Projects

• Built for speed: With 120+ components (Grid, Excel, Charts, Scheduler, etc.) and ready-to-use Page Templates, you will be assembling your app quickly. You can save weeks of work and focus on the important parts of your code while an entire team at Progress manages the upkeep of your component library.

• MCP Server: Kendo UI is an AI-ready framework for developers and agents to increase productivity. Today, every hour (and token) is valuable. The Kendo UI MCP Server helps your AI agents (like VS Code or Cursor) write better code by following Kendo UI best practices that come directly from the team that built the software, reducing hallucinations and allowing your developers and agents ship code fast yet with the highest quality.

• AI-ready Angular components: Add intelligent features quickly with components like AIPrompt, SmartPaste or AI features in the Grid. This makes your app look modern with very little effort.

• ThemeBuilder: Avoid wasting time on CSS. You can import design tokens from Figma and get your style right the first time without writing thousands of lines of code.

• Expert help: The tier-based support plans give you peace of mind. If you have a problem at a critical moment, you have a team of professional engineers to help you, not just a public forum (but the community support is also robust!).

Pro tip: You can try Kendo UI for Angular completely free for 30 days, no credit card required. It’s the fastest way to prove to your team that you can meet that “impossible” deadline.

But what if you are looking for Google’s official baseline? That brings us to our next pick.

2. Angular Material

Angular Material is the official UI suite maintained by the Angular team. It implements Google’s Material Design and is often the first choice for developers looking for a standard, predictable foundation. While it’s the community baseline, in 2026, many projects find its rigid structure a limiting factor.

If you’ve ever worked in an Angular project, you’ve probably used it. It’s the industry standard for a reason, but standards aren’t always enough for every project.

• The Good: It is very stable. Because it is built by the same team that makes Angular, it always works with the latest versions. It follows Google’s Material Design and looks clean and professional.

• The Cons: The customization is difficult. If you need a unique look for your brand, you will spend a lot of time fighting with CSS. It also lacks advanced components for big data, like high-performance Grids or Calendars.

• My Feedback: I have seen many teams spend weeks trying to make Material look different. Also, Material lacks complex tools like a Scheduler or a Gantt Chart. If your project needs more than just basic forms, I recommend Kendo UI. It gives you 120+ advanced parts that are ready for big business needs, saving you the work of building them yourself.

If Material feels too rigid and you need a massive variety of “out-of-the-box” gadgets, you might want to consider our next option.

3. PrimeNG

PrimeNG is one of the well-known libraries in the ecosystem with a collection of components. While its catalog is extensive, navigating its many options can require a significant investment in terms of styling and consistency in larger apps.

• The Good: Their variety is unmatched. PrimeNG has many components from simple buttons to complex organization charts.

• The Cons: Maintaining a perfectly consistent visual style across many complex components can become tricky in large-scale projects. The styling system can sometimes feel overwhelming when you need deep, unified brand customization.

• My Feedback: Kendo UI provides more than just a framework. It offers tools like ThemeBuilder, Figma kits, MCP tools and AI-ready components to provide a smooth developer experience.

Now, if your project is heavily focused on data and complex dashboards, check out the next player in the game.

4. Syncfusion Angular

Syncfusion is an enterprise-focused suite that offers a wide range of specialized components.

• The Good: Their charts and grids are powerful. They are a good choice for data-heavy applications and dashboards.

• The Cons: The API does not always feel like standard Angular, which makes it harder to learn. It is also difficult to customize the components to match a Figma design. This is a framework built for developers, but real-world projects need to include the whole team.

• My Feedback: We should not waste time manually syncing Figma styles with components. I prefer Kendo UI because it is designed for developers, designers and AI agents. This provides a smooth experience for everyone on the team.

Speaking of data apps, sometimes you don’t need a full suite. If your app is 90% tables, then you should take a look at the next one.

5. AG Grid

AG Grid is a specialized library almost entirely focused on data grids. It’s a common choice for applications where tabular data is the main focus, though it requires pairing with other libraries for common UI elements like buttons and modals.

• The Good: If your application is 90% tables, this is a great choice. Its performance with very large datasets is good.

• The Cons: The real world is not only a grid. You will still need to find and style other libraries to solve other scenarios in your app, often resulting in a UI with inconsistent styles that is hard to maintain.

• My Feedback: AG Grid is powerful, but it is only one part of what you’ll need. Kendo UI gives you that same grid power in a unified system. This means your Grid, Buttons and Charts all share the same style and logic. Plus, Kendo UI has built-in PDF and Excel exporting that works perfectly without extra work.

But what if you need that speed in more than just tables? Let’s see the next option.

6. Ignite UI for Angular

Ignite UI for Angular is focused on data visualization and performance. It’s often used in scenarios where real-time charts are a priority, though its ecosystem is smaller than other major players.

• The Good: Great charts and a very fast rendering engine, especially for real-time data.

• The Cons: The ecosystem and community are smaller than the large libraries on this list. This can make it harder to find help for specific problems. Also, similar to AG Grid, in the real world our apps are more than a dashboard. They work with a combination of features that take time to build by yourself.

• My Feedback: Unlike Ignite UI, Kendo UI has Building Blocks that can solve common scenarios like login, register, forgot password, etc. Kendo UI has a very large community and professional support. This means you can always get help when you are stuck, making it a safer choice for important projects.

If you’re already familiar with the DevExpress environment from other platforms, then you’ll feel right at home with our next pick.

7. DevExtreme Angular

DevExtreme Angular by DevExpress has its roots in traditional software development, carrying over patterns from WinForms and ASP.NET. This makes it a familiar choice for teams coming from a more classical enterprise background, though its developer experience can feel a bit dated for modern web standards.

• The Good: Perfect for developers who already use DevExpress and need complex reporting tools and traditional business components.

• The Cons: It can feel a bit “old” in terms of how you write code. Changing the CSS to meet modern web standards is often a difficult and long task.

• My Feedback: To avoid the old code patterns of DevExtreme, Kendo UI offers a clean, modern architecture. It helps you build fast without creating messy code that is hard to fix later.

For those who prefer a clean, minimal design system like Ant Design, there’s a popular community implementation you should know about.

8. NG-ZORRO

NG-ZORRO is a community-driven implementation of the Ant Design system for Angular. It’s aimed at developers who want a ready-made aesthetic for dashboards. However, its community-based nature means it lacks the dedicated professional support found in commercial suites.

• The Good: It creates beautiful and professional-looking interfaces immediately. Excellent for internal tools where speed is important.

• The Cons: It is very strict about its design. If you need to change the style or keep the same look across React or Vue teams, you will find it limited.

• My Feedback: Community libraries like NG-ZORRO are good until you find a difficult bug. In a startup, time is money. Kendo UI enterprise support gets you help from the engineers who actually built the tools. This professional protection is why big companies prefer Kendo UI.

If your focus is less on “fancy” and more on extreme accessibility and enterprise clean-room aesthetics, then check this out.

9. Clarity Design System

Clarity is a design system developed by VMware. It was built for their own internal products and emphasizes a specific enterprise-style UX. While it’s highly focused on its specific patterns, customizing it to fit a broader range of brand identities can be a challenge.

• The Good: Strong focus on user experience and accessibility. It is built by VMware, so it is proven to work well for complex business tasks.

• The Cons: The look is very specific to VMware. It is difficult to change the style for a brand that wants to look unique.

• My Feedback: Clarity is very accessible, but it is hard to change. If your designers use Figma, Kendo UI is a much better choice. Progress Kendo UI provides Figma UI Kits that match the components exactly. This means your developers can build exactly what the designers created without mistakes.

Finally, if you are the type of developer who loves full modularity and building your own patterns like LEGO, you’ll love our final pick.

10. Taiga UI

Taiga UI is a library that focuses on modularity and a TypeScript-first approach. It’s designed for developers who enjoy building their UI piece by piece, though this modularity often means a slower development cycle compared to more pre-integrated solutions.

• The Good: It uses modular principles, making it perfect for developers who want to build their own patterns from zero.

• The Cons: Building a complex business dashboard this way is a slow process. In a startup, you don’t have months to build every part; you have weeks to launch.

• My Feedback: Taiga UI is fun for small experiments, but for real business, you need speed. Kendo UI gives you the same modular power but with 120+ ready-to-use components. You don’t have to build the “LEGO blocks” yourself. Kendo UI gives you the whole castle ready to use.

Recap

Today, building software is a team effort. It is for designers, developers and AI agents. Choosing a framework that thinks about all these factors is the key to a successful product.

In 2026, picking a framework is a strategic decision that defines the success of your project. Choosing Kendo UI for Angular means giving your team the best tools for modern development. With features like the MCP Server, ThemeBuilder and AI-ready components, Kendo UI for Angular helps you build applications faster and handle future challenges.

Do you want to try it?

Download Free Trial

AI-powered code generation has become a significant part of how developers build user interfaces. The 2025 Stack Overflow Developer Survey found that 84% of developers are now using or planning to use AI tools in their development process.

Original AI adoption has been through tools like code autocompletion and chat-based assistants, but agentic UI tools take things further. Rather than suggesting the next line of code, they can take a natural language prompt and produce working, styled UI code in seconds.

However, not all AI generation tools are created equal. The quality of the output, how reliably it builds on the first attempt, how fast it runs and how well it handles things like accessibility and theming can vary quite a bit between tools. These differences matter because a tool that requires a large number of follow-up prompts to correct errors or produce code that doesn’t match the original requirements isn’t truly saving us time.

In this article, we’ll look at a head-to-head comparison between two agentic UI generation tools: the Progress Telerik Agentic UI Generator which includes the Blazor Agentic UI Generator for .NET/Blazor and the Kendo UI Generator for Angular and React, and the Syncfusion Agentic UI Builder. We’ll walk through the results of extensive testing across multiple frameworks, covering output quality, performance, stability, accessibility, theming and more.

How the Comparison Was Conducted

To make this comparison as fair and thorough as possible, both tools were tested across multiple frameworks using two evaluation approaches.

Blazor/.NET

On the Blazor/.NET side, 23 prompts were run through the Telerik Agentic UI Generator and the Syncfusion Agentic UI Builder. These prompts ranged from simple single-component requests to complex multi-section layouts like e-commerce catalog pages and CMS admin dashboards. Each prompt’s output was rated on a 0 to 7 scale:

• 0-1: Doesn’t build or crashes with no UI
• 2-3: Partially renders, major sections broken
• 4: Renders but requires multiple prompts to clear build or runtime errors
• 5: Renders but doesn’t match prompt requirements in several areas
• 6: Mostly complete, minor issues
• 7: Fully matches requirements

The evaluation also tracked how many prompts were needed before the output could successfully build and render, as well as the time (in seconds) from initial prompt submission to output generation.

Angular and React

For Angular and React, a dedicated evaluation was conducted comparing the Kendo Agentic UI Generator against the Syncfusion Agentic UI Builder. Rather than scoring individual prompts, this evaluation focused on a technical comparison of the tools themselves. By running many prompts and examining the context returned by each tool, the analysis compared how each MCP server helps the AI agent arrive at its output across categories like layout, styling, accessibility, documentation and component handling.

Output Quality and Reliability

This is the category where the gap between the two tools becomes immediately clear.

Across the 23 Blazor prompts, the Telerik Agentic UI Generator consistently produced complete, requirement-matching output on the first attempt. The Syncfusion Agentic UI Builder told a different story. It experienced five failures where no usable UI was generated at all, and several other prompts that required follow-up prompts to fix errors before the output could even build. Let’s look at a couple of examples.

Failures

The very first prompt asked both tools to build a login screen with email/password validation and an admin dashboard with a sidebar menu, key metrics and recent activity.

Prompt: “I have created an empty application that now needs a login screen and an admin dashboard. Add a login form with email/password fields and validation. After a successful login, redirect to an admin dashboard page featuring a sidebar menu and a main content area displaying key metrics and recent activity.”

The Telerik Generator produced a fully working output on the first attempt.

The Syncfusion Builder returned an error along the lines of: Error. This response is truncated because it is too long. Try rephrasing your question. No UI was generated at all.

The second prompt told both tools to create a monitoring dashboard with system health KPIs, a log stream panel, charts for API response times and requests per service.

Prompt: “Create a new page using the existing top navigation and footer. In the middle, add 3 rows with 3 responsive columns each. The top row shows system health KPIs for CPU, memory and error counts. The middle rows include a Log Stream panel, a line Chart of API response times and a bar chart of requests per service. The bottom row contains a Deployment History table, an Alerts panel and a list of open tickets.”

The Telerik Generator again produced a fully working output on the first pass.

The Syncfusion Builder hit the same truncation error.

These are the kinds of prompts that represent real-world use cases. A login screen with a dashboard and a monitoring page with multiple data panels aren’t unusual requests.

Errors Requiring Follow-ups

Not every issue is an error during the generation process. Some prompts produced output that needed additional work to get running.

We fired a prompt to ask for a product catalog page with a responsive layout, product cards, a filtering toolbar and expandable detail views. The Telerik Generator handled it cleanly on the first attempt. The Syncfusion Builder hit an error about a missing component parameter and needed a second follow-up prompt to fix it.

Prompt: “Create a product catalog page with a responsive CSS layout. The layout should display product cards. Add a toolbar with filtering options, and expandable detail view for each product that work seamlessly on mobile, tablet, and desktop.”

The first output by the Telerik Blazor generator:

The final output from Syncfusion, after the necessary follow-up prompt:

The Syncfusion Builder’s errors in these cases often involved referencing component parameters that don’t exist, which may suggest the tool’s AI agent is working with less reliable component information during generation.

Partial Results

Not all issues showed up as crashes or errors needing follow-ups. Let’s look at an example of a prompt that was made which involved a theming request.

Prompt: “Generate a custom theme for a corporate blue and green color scheme with high contrast accessibility requirements.”

The Telerik Agentic UI Generator created the output matching the requirements.

The Syncfusion Builder did create a custom theme, but the expected theme wasn’t applied to the output.

The Bigger Picture

Even when we set aside the failures and only look at prompts where the Syncfusion Builder produced something usable, the outputs still frequently fell short of the original requirements.

On the Angular and React side, the findings were consistent. While the final rendered UI sometimes appeared similar at a glance, the most significant differences were in how each tool’s MCP server helped the agent arrive at that output. The Kendo Generator’s tools consistently delivered more relevant, targeted context to the AI agent, filtering results to what was actually needed for the prompt. The Syncfusion Builder’s tools returned broader, less filtered responses, often including full component prop lists and governance rules regardless of what was asked.

Performance

Speed matters when we’re iterating on UI designs with AI. Waiting several minutes for a complex layout to generate can significantly slow down the development flow.

Across the Blazor evaluation, the Telerik Generator was consistently faster. The speed advantage was most noticeable on complex layout prompts. For example, on a complex e-commerce catalog page with filtering, sorting, responsive breakpoints and pagination, the Telerik Generator completed in about 799 seconds while the Syncfusion Builder took 908 seconds.

There was one outlier where Syncfusion was notably faster (a simpler single-component case), but across the full set of 23 prompts, the speed advantage consistently favored Telerik.

Accessibility

Accessibility is often treated as an afterthought, but for enterprise applications, it’s a requirement, not a nice-to-have!

The Kendo Generator includes a dedicated accessibility tool (#kendo_accessibility_assistant) that retrieves WCAG 2.2 Level AA guidelines as a mandatory step in the generation process. It also fetches component-specific accessibility requirements for each component used in the output. This leads to every piece of generated UI having accessibility considerations baked in from the start.

From what we can gather, and at the time of writing, the Syncfusion Builder doesn’t have a strong accessibility tool like the #kendo_accessibility_assistant.

Theming, Layout and Documentation

Beyond output quality and speed, the Angular and React evaluation revealed some important architectural differences in how each tool handles theming, layout and documentation.

Theming

Theming is more than color selection. The Kendo UI Generator produces a complete design system from a single prompt, including colors, typography, spacing scales, border radius, elevation and shadows. The Syncfusion Builder’s style tool is limited to component state colors and semantic colors. Typography, spacing and elevation aren’t reachable through it, so the generated output may look right in terms of color but lack the design coherence that holds a full application together.

Layout

Layout is also where a notable dependency difference comes in. The Kendo UI Generator uses a self-contained layout system built on its own CSS utilities, introducing no external dependencies. The Syncfusion Builder relies on Tailwind CSS, injected into every project, and works from a catalog of 265+ prebuilt blocks. When the desired layout doesn’t match a catalog entry, the result approximates what was asked for.

For teams already using Tailwind, this might feel natural but for projects on a different CSS framework (Angular Material, for example), adding Tailwind on top can introduce style conflicts. This can also be a potential blocker for organizations that restrict third-party dependencies.

Responsiveness follows a similar split: the Kendo UI Generator has a dedicated phase with explicit breakpoint reasoning, while the Syncfusion Builder inherits responsive behavior from Tailwind’s defaults without any first-class responsive logic of its own.

Documentation

Documentation plays a bigger role in output quality than it might seem, since it directly shapes how well the AI agent understands the components it’s generating. The Kendo UI Generator injects relevant documentation chunks directly into every component tool call, including API references with full type signatures. The Syncfusion Builder treats documentation as a separate tool, triggered only by specific keywords. At the time of the evaluation, results from this tool were inconsistent and the service had been unavailable for over 24 hours for both Angular and React.

One other important observation from the Angular and React evaluation: the Kendo UI Generator customizes its workflow per prompt using confidence scores, including only the tools and instructions relevant to each request. The Syncfusion Builder runs the same fixed sequence for most prompts regardless of complexity, and its component tools return the full prop list and approximately 250 lines of governance rules on every call. The result is that the Kendo UI agent operates on targeted, preprocessed context while the Syncfusion agent carries a heavier payload for every request.

Wrap-up

The comparison across Blazor, Angular and React tells a consistent story with these agentic UI generators. The Progress Telerik Agentic UI Generator outperforms the Syncfusion Agentic UI Builder across output quality, reliability, performance, accessibility, theming, layout and documentation.

On the Blazor side, the Telerik Generator had zero full failures across 23 prompts while Syncfusion had five, along with a consistent speed advantage on complex prompts and more reliable first-pass output. On the Angular and React side, the advantages show up in the underlying architecture, where the Kendo Generator’s tools consistently deliver cleaner, more relevant context to the AI agent.

Get started with AI-empowered development. The Kendo UI and Telerik AI tools are ready. And they come as part of the free trial of the component libraries.

Try Now

For more information on the Progress Telerik Agentic UI Generator, check out the following resources:

• Telerik Agentic UI Generator for Blazor
• Kendo UI Generator for Angular
• Kendo UI Generator for React

The full comparison data referenced in this article is available for download:

• Telerik UI for Blazor Agentic UI Generator vs Syncfusion Agentic UI Builder Comparative Evaluation (XLSX)
• Kendo Agentic UI Generator vs Syncfusion Agentic UI Builder (XLSX)

Summary FAQs

What Do These Tools Do?

What Telerik Agentic UI Generator Is

According to the Progress Telerik website, the Telerik Agentic UI Generator for Telerik and Kendo UI libraries is an intelligent development tool delivered through the Model Context Protocol (MCP) Server that enables UI generation from natural language prompts. Once configured and authenticated, you can use the Agentic UI Generator tool (#telerik_ui_generator) together with the available specialized MCP assistants.

What Syncfusion Agentic UI Builder Is

According to the Syncfusion site, Syncfusion’s Agentic UI Builder is designed to work inside an IDE to generate UIs, dashboards or pages with Syncfusion components with natural language commands. Syncfusion uses MCP integration to access component APIs, prebuilt UI blocks, styling configurations, icon libraries and code generation.

Why Does MCP Matter in Both Products?

Both brands’ tools use Model Context Protocol (MCP) servers to connect AI applications directly to the software specs for the individual library. This means that the AI is informed on component documentation, best practices, workflows and tooling provided by the UI library, so the AI can create a user interface more in line with how the library was designed to work. It should result in better outputs than if an AI were cobbling together an interface without guidance.

Learn more about the individual MCP servers:

• Telerik UI for Blazor MCP Servers
• Kendo UI for Angular MCP Servers
• KendoReact MCP Servers
• Syncfusion EJ2 React MCP Server
• Syncfusion EJ2 Angular MCP Server
• Syncfusion Blazor MCP Server

Are Prompt Libraries Included?

Telerik and Kendo UI Generator Prompt Libraries

Yes! Prompt libraries are included for the Kendo UI and Telerik AI UI Generator tools:

• Blazor: https://www.telerik.com/blazor-ui/documentation/ai/agentic-ui-generator/prompt-library
• React: https://www.telerik.com/kendo-react-ui/components/ai-tools/agentic-ui-generator/getting-started
• Angular: https://www.telerik.com/kendo-angular-ui/components/ai-tools/agentic-ui-generator/prompt-library

Syncfusion Agentic UI Builder Prompt Libraries

Yes! Prompt libraries are included for the Syncfusion Agentic UI Builder tools:

• Blazor: https://blazor.syncfusion.com/documentation/mcp-server/agentic-ui-builder/prompt-library
• React: https://ej2.syncfusion.com/react/documentation/mcp-server/agentic-ui-builder/prompt-library
• Angular: https://ej2.syncfusion.com/angular/documentation/mcp-server/agentic-ui-builder/prompt-library

Building accessible components is one of those things we know we should do, but often skip because it feels overwhelming. We need to read about accessibility tips and tricks and a lot of documentation.

You start with a simple dropdown menu, knowing you need to handle keyboard navigation, ARIA attributes, focus management and screen reader support. Before you know it, your “simple” component has 200 lines of accessibility code you’re not even sure is correct. (Unless you’re using the Progress Kendo UI for Angular library, which has accessibility baked in for you. )

What if I told you there’s a way to get the accessibility magic you need, regardless of component library, with full control over your styling with the magic of Angular Aria?

But what is Angular Aria? Let’s make a small intro.

What Is Angular Aria?

Think of Angular Aria as a collection of accessibility superpowers for your components, but instead of manually implementing keyboard navigation, ARIA attributes and focus management, you import a directive, add it to your HTML and, boom, your component is accessible.

The Angular team built these directives following the W3C Accessibility Guidelines, so you don’t have to become an accessibility expert to build compliant components.

Hold On, What About Angular Material?

Great question! If you’ve been using Angular for a while, you’re probably thinking: “We already have Angular Material. Why do we need another library?”

Here are the key differences:

Angular Material gives you complete, prestyled components. They look great out of the box, but they come with Material Design opinions baked in. If you want a button that doesn’t look like a Material button, you’re going to fight the framework.

Angular Aria gives you headless directives—just the accessibility logic, zero styling. You get all the keyboard navigation, ARIA attributes and screen reader support, but you control every pixel of how it looks.

Think of it this way:

• Angular Material: It is plug and play, looks good, works immediately, but everyone has the same result. If you were building a physical doorway to your business, it would look like all other businesses, just with your business name on the sign.
• Angular Aria: This tool is more like the ramp to your front door, enabling anyone to access the business entrance, while allowing you to choose the awning, the window display and the door color.

So when should you use each one? We’ll dive deeper into that later in the article, but here’s the quick answer:

• Use Angular Material when you need to ship fast and Material Design works for you.
• Use Angular Aria when you have custom design requirements and need full control.

Remember, accessibility isn’t optional anymore. It’s a legal requirement in many countries, and, more importantly, it’s the right thing to do.

But implementing accessibility correctly is hard. You need to know:

• Which ARIA attributes to use (and when)
• How keyboard navigation should work for each pattern
• How to manage focus properly
• How screen readers interpret your markup

Angular Aria handles this complexity for you. You focus on the HTML structure, CSS styling and business logic, and Angular Aria takes care of accessibility.

But, as always, the best way to learn is by building something. Let’s do it!

Set Up the Project

First, create a new Angular application. In your terminal, run the following command (be sure to have Node.js installed).

npx @angular/cli@latest new angular-aria-demo

When CLI prompts stylesheet format, pick CSS.

  - **Which stylesheet format would you like to use?** → CSS

Now, navigate to your project and add Angular Aria:

cd angular-aria-demo
npm install @angular/aria

That’s it. We now have a fresh Angular project with Angular Aria installed. Let’s build something accessible!

Building an Accessible Toolbar

Let’s build a text formatting toolbar, the kind you see in rich text editors. This is a perfect example because it looks simple but has surprising accessibility complexity.

Using the CLI, generate a new component editor-toolbar:

ng generate c components/editor-toolbar

Perfect! Open the component with your editor, and import Toolbar, ToolbarWidget and ToolbarWidgetGroup directives provided by @angular/aria/toolbar.

  import { Component } from '@angular/core';
  import { Toolbar, ToolbarWidget, ToolbarWidgetGroup } from '@angular/aria/toolbar';
  
  @Component({
    selector: 'app-editor-toolbar',
    templateUrl: './editor-toolbar.component.html',
    styleUrl: './editor-toolbar.component.css',
    imports: [Toolbar, ToolbarWidget, ToolbarWidgetGroup],
  })
  export class EditorToolbarComponent {}

Now it’s time to build the HTML structure. We create a div container with the directive [ngToolbar], which works as the main container. We also need ToolbarWidget to use with individual buttons and ToolbarWidgetGroup for groups of related buttons.

In the following HTML, we use every directive with divs and button elements. Copy it and paste into the editor-toolbar.html.

  <div ngToolbar aria-label="Text Formatting Tools">
  <div class="group">
   <button ngToolbarWidget
           value="undo"
           type="button"
           aria-label="undo">
     Undo
   </button>
   <button ngToolbarWidget
           value="redo"
           type="button"
           aria-label="redo">
     Redo
   </button>
 </div>

 <div class="separator" role="separator"></div>

 <!-- Text formatting group -->
 <div class="group">
   <button ngToolbarWidget
           value="bold"
           type="button"
           aria-label="bold"
           #bold="ngToolbarWidget"
           [aria-pressed]="bold.selected()">
     Bold
   </button>
   <button ngToolbarWidget
           value="italic"
           type="button"
           aria-label="italic"
           #italic="ngToolbarWidget"
           [aria-pressed]="italic.selected()">
     Italic
   </button>
 </div>

 <div class="separator" role="separator"></div>

 <!-- Alignment group (radio buttons) -->
 <div ngToolbarWidgetGroup
      role="radiogroup"
      class="group"
      aria-label="Text alignment options">
   <button ngToolbarWidget
           role="radio"
           type="button"
           value="align left"
           aria-label="align left"
           #leftAlign="ngToolbarWidget"
           [aria-checked]="leftAlign.selected()">
     Left
   </button>
   <button ngToolbarWidget
           role="radio"
           type="button"
           value="align center"
           aria-label="align center"
           #centerAlign="ngToolbarWidget"
           [aria-checked]="centerAlign.selected()">
     Center
   </button>
   <button ngToolbarWidget
           role="radio"
           type="button"
           value="align right"
           aria-label="align right"
           #rightAlign="ngToolbarWidget"
           [aria-checked]="rightAlign.selected()">
     Right
   </button>
 </div>
</div>

The final step is adding some CSS styles to make it look nice. Open the editor-toolbar.css and paste the following style:

  [ngToolbar] {
 display: flex;
 gap: 8px;
 padding: 8px;
 background: #f5f5f5;
 border-radius: 4px;
}

.group {
 display: flex;
 gap: 4px;
}

.separator {
 width: 1px;
 background: #ddd;
}

button {
 padding: 8px 12px;
 border: 1px solid #ddd;
 background: white;
 border-radius: 4px;
 cursor: pointer;
}

button[aria-pressed="true"],
button[aria-checked="true"] {
 background: #007acc;
 color: white;
}

Perfect, we just added HTML, CSS and Angular Aria directives. To test it, open the app.html and add <app-editor-toolbar></app-editor-toolbar>, save changes and run your app.

ng serve
Initial chunk files | Names         | Raw size
main.js             | main          | 10.50 kB | 
styles.css          | styles        | 95 bytes | 

                    | Initial total | 10.59 kB

Application bundle generation complete. [0.641 seconds] - 2026-01-25T10:16:33.843Z

Watch mode enabled. Watching for file changes...
NOTE: Raw file sizes do not reflect development server per-request transformations.
  ➜  Local:   http://localhost:4200/
  ➜  press h + enter to show help

Try to use your toolbar with your keyboard. You’ll find it works, and we didn’t have to write any code for keyboard navigation logic (like: Arrow keys, Home, End), focus management, ARIA role attributes, screen reader announcements or selection state management. All of that complexity? Gone.

The ngToolbar, ngToolbarWidget and ngToolbarWidgetGroup directives handle all of that automatically.

We now have a fully accessible toolbar that works with keyboard navigation and screen readers, and we only wrote the HTML structure and CSS.

Angular Aria provides directives for the most common interactive patterns, we can get components for search and selection (like Autocomplete, Listbox and Select), navigation and actions (Menu, Menubar and Toolbar like we just built), and content organization (Accordion, Tabs, Tree and Grid). Every directive comes with complete documentation, working examples and API references. You can see the full list of available components in the official Angular Aria documentation.

But I’m a Fan of Angular Material

Yes, I understand Angular Material has a long relationship with Angular devs. You can continue using Angular Material when you:

1. Need to ship fast – You’re building an MVP or internal tool and don’t want to spend time on custom styling.
2. Like Material Design – You’re OK with the Google Material Design aesthetic.
3. Have limited design resources – Your team doesn’t have dedicated designers.

Remember, Angular Material is amazing, but it comes with opinions about how things should look.

If you try to heavily customize Material components, you’ll spend more time fighting the framework than building features. I’ve been there—overriding Material styles with ::ng-deep and !important until the CSS becomes unmaintainable.

And don’t even get me started on theming. Creating a custom theme for Angular Material is… let’s just say “special.” It’s doable, but it’s tricky and requires deep knowledge of Sass and Material’s theming system. (If you’re curious about the complexity, I wrote about it in Theme UI Frameworks in Angular: Part 2 - Custom Theme for Angular Material.)

Angular Aria solves this by giving you zero styles. You start with a blank canvas and build exactly what you need.

Remember for simple cases, native elements are already accessible when you use <button> for buttons, <input type="radio"> for radio buttons or <select> for simple dropdowns. But Angular Aria gives you a third option: headless accessible components that you can style however you want, we can meet accessibility requirements, maintain full design control and avoid reinventing the wheel.

Recap

We learned that accessibility doesn’t have to be overwhelming. Angular Aria gives you production-ready, WCAG-compliant directives that handle the complex parts.

We provide the HTML structure and CSS and Angular Aria provides the accessibility without pain!

But What About Kendo UI?

Maybe you want to ship faster (really fast) and have complex scenarios with datalist, charts, schedulers and complex UI patterns. If you read this article and are thinking: “This is great, but I still have to write all the HTML and CSS myself. Why not just use a complete component library?” you’re asking the right question.

Here’s when Progress Kendo UI for Angular makes more sense than Angular Aria or Angular Material:

Use Kendo UI when you want:

1. Everything out of the box – Prebuilt components with professional styling, themes and accessibility already done
2. Advanced features included – Things like data grids with sorting/filtering, charts, schedulers and complex UI patterns
3. Consistent design system – A cohesive look across all components without writing custom CSS
4. Enterprise-grade support – Professional support, regular updates and guaranteed compatibility
5. Speed PLUS customization – You need to ship fast and need options to customize (you’ll have five fully built theme options plus the ability to tweak those or create your own theme)

There’s no “wrong” choice—just different tools for different jobs.

If you’re building internal tools or you like the Kendo UI design system, Kendo UI saves you weeks of work, and, honestly? I can build complex stuff (data grids, schedulers, charts) in minutes, making Kendo UI the right answer for me.

Plus, you can use the Kendo UI for Angular AI Coding Assistant, an MCP server that automatically scaffolds components for AI agents. Instead of manually writing Kendo UI components, your AI assistant can do it for you.

Want to learn more? Check out my article: Angular and Kendo UI MCP: Making Agents Work for You

• Source code
• Angular Aria Documentation

Angular developers spend a lot of time on repetitive UI tasks like scaffolding components, wiring data into views and adjusting layouts. Or, at least they used to, before the age of AI.

Now, MCP-powered tools can automate much of that work—letting coding assistants generate Angular code and tools like Agentic UI Generator turn prompts or data into working UI so developers can move faster.

“AI made refactoring and handling technical debt much faster, allowing us to focus on market features. Validating ideas, creating POCs, and writing tests are also areas where we’ve seen huge impact. The whole development lifecycle changed, and it opened the door for exploration and innovation.”
— Progress Product Team Insight

Model Context Protocol (MCP) is a way for AI assistants to connect directly to tools and dev environments instead of generating code in isolation.

Without that connection, AI can only make suggestions based on patterns it has seen before. It doesn’t know what Angular version you’re using, what components exist in your UI library or what APIs are actually available in your project. (Unless your assistant is built into a full-blown IDE, like Cursor.)

Often, with AI, the output might look correct, but developers end up fixing hallucinated APIs or rewriting scaffolding to make it fit their app. MCP closes that gap by giving AI access to real context—frameworks, component libraries, project structure and tooling. Instead of guessing what code might work, the assistant can generate output grounded in the tools you’re actually using.

So if you love VS Code, for example, but Copilot just isn’t cutting it for frontend AI-generated code, this is where MCP can fill the gap.

This is especially true for frontend work. Angular developers spend a lot of time on repetitive UI tasks like scaffolding components, wiring data into views and configuring layouts. MCP-powered tools can automate much of that groundwork. Coding assistants can generate valid Angular structures, and tools like Agentic UI Generator can turn prompts or data into working UI.

The result isn’t magic code generation—it’s a faster starting point. AI helps developers get moving, while humans still shape the final result.

Task #1: Scaffolding Angular Components Faster

Creating components is one of the most common tasks in Angular development. Even with Angular CLI, developers still need to generate the component, add inputs, wire services and start building the template.

If your coding assistant is connected to the Progress Kendo UI for Angular MCP server, it understands the components available in your UI library and can generate valid Angular structures using them.

With an MCP-powered coding assistant, you can start with a simple prompt:

#kendo_component_assistant Create a ProductCard Angular component that displays a product image,
name, and price using Kendo UI components.

The assistant can generate a working Angular component structure:

@Component({
  selector: 'app-product-card',
  imports: [KENDO_LAYOUT, NgOptimizedImage],
  template: `
    <kendo-card class="product-card" width="100%">
      <img
        kendoCardMedia
        [ngSrc]="product().imageUrl"
        [width]="product().imageWidth"
        [height]="product().imageHeight"
        [alt]="product().imageAlt"
      />

      <kendo-card-body>
        <h3 kendoCardTitle>{{ product().name }}</h3>
        <p class="product-price" [attr.aria-label]="'Price: ' + formattedPrice()">
          {{ formattedPrice() }}
        </p>
      </kendo-card-body>
    </kendo-card>
    ...

Instead of starting from scratch, developers get a valid Angular starting point immediately and can focus on refining the UI.

Task #2: Turning Data Into UI

A large portion of frontend work isn’t writing complex logic—it’s translating data and ideas into working UI.

As devs, we are accustomed to taking API responses or product requirements and turn them into forms, dashboards or application layouts. That process usually starts with sketching the structure of the interface and then building the components to support it.

With the Angular Agentic UI Generator, you can start that process with a prompt instead.

Because the tool connects to your UI library through MCP, it understands the components available in your stack and can generate layouts using them. Instead of manually assembling the structure of the page, the generator produces a working Angular layout you can refine.

For example, you might start with a prompt like this:

#kendo-ui-generator Create a responsive Workflow Composer app layout that includes: a left sidebar that only takes up 1/3 max of the UI for available workflow steps (this is essentially a column that is a list of individual cards/tasks), and main canvas area for building connected flows.

From there, the generator produces a starting UI layout using Kendo UI for Angular components.

Task #3: Updating and Iterating on UI

Building the first version of a UI is only the beginning. Most frontend work happens in the iteration phase—adjusting layouts, adding interactions and refining components as requirements evolve.

This is another area where MCP-connected assistants can help speed things up. Instead of manually digging through templates and wiring new behavior, developers can describe the change they want and let the assistant update the structure.

For this last task, I took our generated Workflow Composer app and added drag-and-drop support with a simple prompt:

#kendo_ui_generator let’s add drag and drop

Rather than rewriting the layout or manually integrating interaction logic, the assistant extends the generated UI and adds the new behavior.

One thing I’ve noticed while experimenting with this workflow is that single task prompts tend to work best. Breaking changes into bite-sized requests often produces cleaner results when working with MCP-powered tools and Copilot.

Why MCP Matters

AI coding tools are useful, but without access to your real development environment, they can only generate suggestions based on patterns they’ve seen before.

MCP changes that by connecting AI assistants directly to the tools developers already use. Instead of guessing which components exist or how your project is structured, the assistant can interact with real frameworks, libraries and development workflows.

That connection is what makes tasks like generating Angular components, creating UI layouts or iterating on interfaces possible with simple prompts. Rather than starting from scratch each time, devs get a working starting point that fits their stack.

Conclusion

Angular developers spend a lot of time on repetitive UI work—scaffolding components, turning data into layouts and iterating on interfaces as requirements evolve.

MCP-powered tools can help automate much of that groundwork. Coding assistants can generate valid Angular structures, and tools like the Angular Agentic UI Generator can turn prompts into working UI layouts that developers can refine and extend.

If you’d like to try it yourself, you can install our MCP servers and learn how to get started with Coding Assistant and Agentic UI Generator in the documentation.

Explore the MCP setup guide in the docs.

Building modern Angular applications involves juggling multiple tasks: executing CLI commands, managing libraries, navigating documentation and, now, integrating AI tools.

The challenge? Most AI assistants provide generic code snippets but lack context about your specific project structure or the professional UI tools you use.

What if your AI assistant could do more than just suggest code? What if it could actually use your tools to perform the work for you? Imagine an agent that doesn’t just “talk” about Angular and Kendo UI documentation but actually applies official best practices directly to your codebase.

Today, we’re going to bridge that gap. We’ll connect your AI tools directly to your project to literally make Angular and Kendo UI work for you.

We’ll achieve this using Angular MCP and the Progress Kendo UI for Angular AI Coding Assistant.

But First, What Is MCP?

MCP stands for Model Context Protocol. Think of it as a standardized bridge that allows AI assistants to securely interact with your local tools and data.

Before MCP, interacting with an AI was like having a video call with a senior developer; they could offer great advice, but they couldn’t touch your keyboard. With MCP our reality changes, MCP brings a standard way for AI to connect with our source code; enabling it to execute commands, read files and understand the state of your project in real time and give full access and context to help us.

For a deeper dive into the concept, I recommend checking out The Promise of Model Context Protocol.

By combining Angular MCP for project management and the Kendo UI for Angular AI Coding Assistant for professional UI components, we can transform the development experience. We stop typing ng generate commands manually and stop switching context so we can see Kendo UI documentation inside our editor by following the Progress team’s recommended practices.

Let’s talk first about Angular MCP!

Part 1: Angular MCP (The Builder)

Think of Angular MCP as a direct line between your AI-powered editor (like Cursor or VS Code) and the Angular CLI.

Instead of switching to a terminal, you can simply ask your AI to create a new component called user-profile, add @angular/material to your project, or fix a build error and explain what happened.

We need to register the MCP server in your editor’s configuration. In Cursor, open your MCP settings (usually found via Command + Shift + P > “Open MCP Settings”) and add the following:

{
  "servers": {
    "angular-cli": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

Note for VS Code users: The configuration file is typically located at:

• macOS/Linux: ~/.vscode/mcp.json

Cursor users: You can add this JSON to your MCP configuration by opening the Command Palette (Cmd/Ctrl + Shift + P) and searching for “MCP.” The configuration file is located under the Tools & MCP section.

Once added, restart your editor and verify it works by asking: “Generate a new Angular service called api-client.”

Checkpoint: Your agent can now manage your Angular project. But how do we handle the UI design?

Learn more about the basics of getting started with Angular and Cursor.

Kendo UI AI Coding Assistant (The Designer)

Building professional dashboards usually involves navigating documentation and manually wiring up complex components. The Kendo UI for Angular AI Coding Assistant changes this by acting as a local Kendo UI expert that understands the entire library.

The Kendo UI for Angular MCP Server runs with npx and uses your Progress Telerik license directly.

First, you need a valid Telerik license. If you don’t have one, you can start a free trial and you don’t need a credit card. Second, you need to add the configuration to your mcp.json file:

{
  "servers": {
    "kendo-angular-mcp-server": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@progress/kendo-angular-mcp@latest"],
      "env": {
        "TELERIK_LICENSE": "YOUR_LICENSE_KEY_HERE"
      }
    }
  }
}

Pro tip: If you have your license key set up globally on your machine, you can omit the env section!

Now your agent has the tools to build a responsive orders dashboard. Instead of writing hundreds of lines of code, you can simply prompt your agent using the #kendo_angular_assistant handle:

“Use the #kendo_angular_assistant to build an OrdersDashboardComponent. I need a responsive layout with a sidebar, and a Kendo Grid in the main content area showing ID, Customer, Date, Status and Total. Add a “New Order” button in a toolbar above the grid and use the Kendo Default theme.”

The agent follows three steps. It analyzes your request to see which Kendo UI components you need. Then, it generates clean and typed code for TypeScript and HTML using Kendo UI standards. Finally, it implements the code in your files and helps you with the modules.

Need to iterate? Just ask for a refinement:

“Awesome. Now update the grid to allow filtering by Status using a dropdown, and highlight ‘Pending’ orders in yellow.”

The agent adapts the code instantly, following your specialized requirements.

Let’s See It in Action

To start a new project, just run this command in your terminal:

ng new kendo-store

Now, configure your editor with both MCP servers. Here is a complete example of how your mcp.json should look. Don’t forget to add your Telerik license key:

{
  "servers": {
    "angular-cli": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    },
    "kendo-angular-mcp-server": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@progress/kendo-angular-mcp@latest"],
      "env": {
        "TELERIK_LICENSE": "YOUR_LICENSE_KEY_HERE"
      }
    }
  }
}

Now, let’s play with our Cursor agent. We want it to do the tasks for us using these new MCP tools.

For example, ask it which tools are available. It must show Kendo (if you have configured Angular or other MCP). Then, just use a prompt mentioning #kendo_angular_assistant like:

#kendo_angular_assistant Create a basic Grid component that displays employee data with columns for ID, Name, Position, and Salary. Include sorting and pagination functionality.

Let’s see how Cursor works with Kendo UI for Angular MCP:

Maybe you’re wondering, “Do I need to remember every prompt?” Don’t worry, Progress Kendo UI provides a list of optimized prompts ready for use with the Kendo UI for Angular AI Coding Assistant.

Now you are ready with prompts and MCP to give the agents the tools to work for you.

Conclusion

Honestly, we shouldn’t spend our time fighting with our tools. We need to make them work for us.

With Angular MCP handling the CLI work and the Kendo AI Assistant building the professional UI, you can finally focus on what really matters: solving problems and building your app. No more boring boilerplate or searching documentation for hours.

Stop copying and pasting code from ChatGPT, or leaving your agent to work without tools. Give your agents the tools they need to work better for you!

• Angular MCP Documentation
• Kendo UI for Angular AI Coding Assistant

And remember: Kendo UI for Angular comes with a free trial. So, give it a try if you aren’t already using it.

Try Kendo UI for Angular

Micro-frontends are an architectural pattern that extends the concept of microservices to frontend development. It involves breaking a large frontend application into smaller, independent and deployable components.

In this article, we will learn how to implement a micro-frontend architecture using Native Federation. We will:

• Create one host application
• Create two remote client applications
• Load the remote applications dynamically in the host application using routing or dynamic component loading

Let’s begin by creating the remote applications.

Creating Remote Apps

We can use the Angular CLI to scaffold the client application. Let’s create a remote app using the CLI command below.

ng new remote-app1

After successfully creating the project, configure the Angular application as a remote app in the micro-frontend (MFE) setup by running the schematic command shown below.

ng add @angular-architects/native-federation --project remote-app1 --port 4201 --type remote

Make sure to pass your project name after the --project flag (in this case, remote-app1). The CLI will then prompt you to confirm. After that, it will run the schematics and configure the Angular project as a remote application.

After the installation completes successfully, you will see a new federation.config.js file added to the project.

const { withNativeFederation, shareAll } = require('@angular-architects/native-federation/config');

module.exports = withNativeFederation({
  name: 'remote-app2',


  exposes: {
    './Component': './src/app/app.ts',
  },

  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
  },

  skip: [
    'rxjs/ajax',
    'rxjs/fetch',
    'rxjs/testing',
    'rxjs/webSocket',
    // Add further packages you don't need at runtime
  ],

  // Please read our FAQ about sharing libs:
  // https://shorturl.at/jmzH0

  features: {
    // New feature for more performance and avoiding
    // issues with node libs. Comment this out to
    // get the traditional behavior:
    ignoreUnusedDeps: true
  }
});

Also, you will see changes in the angular.json file. Ideally, you should not change anything in this file except the exposes object. By default, it exposes the AppComponent, but you can also choose to expose routes if needed.

In the project, add home, product and invoice components. Then modify the route as shown below:

export const routes: Routes = [
    {
        path: '',
        component: App,
        children: [
            { path: 'home', component: Home1 },
            { path: 'product', component: Product },
            { path: 'invoice', component: Invoice },
        ],
    }
];

On the AppComponent, add router-outlet and buttons to navigate as shown below.

<h2>Client App</h2>
<hr/>
<button routerLink="home" routerLinkActive="active">Home</button>
<button routerLink="product" routerLinkActive="active">Product</button>
<button routerLink="invoice" routerLinkActive="active">Invoice</button>
<hr/>
<router-outlet></router-outlet>

After that, expose the route by updating the exposes section in federation.config.js, as shown below.

const { withNativeFederation, shareAll } = require('@angular-architects/native-federation/config');

module.exports = withNativeFederation({
  name: 'remote-app1',


  exposes: {
    './Routes': './src/app/app.routes',
  },

  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
  },

  skip: [
    'rxjs/ajax',
    'rxjs/fetch',
    'rxjs/testing',
    'rxjs/webSocket',
    // Add further packages you don't need at runtime
  ],

  // Please read our FAQ about sharing libs:
  // https://shorturl.at/jmzH0

  features: {
    // New feature for more performance and avoiding
    // issues with node libs. Comment this out to
    // get the traditional behavior:
    ignoreUnusedDeps: true
  }
});

In the same way, let’s create one more remote application, but this time we won’t add any routes to it. To create this application, run the following commands:

• ng new remote-app2
• ng add @angular-architects/native-federation --project remote-app2 --port 4202 --type remote

In this application, we will not configure any routes. This helps us understand how the host application can work with both an exposed route and an exposed component. So the federation.config.js of this application should look like:

const { withNativeFederation, shareAll } = require('@angular-architects/native-federation/config');

module.exports = withNativeFederation({
  name: 'remote-app2',


  exposes: {
    './Component': './src/app/app.ts',
  },

  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
  },

  skip: [
    'rxjs/ajax',
    'rxjs/fetch',
    'rxjs/testing',
    'rxjs/webSocket',
    // Add further packages you don't need at runtime
  ],

  // Please read our FAQ about sharing libs:
  // https://shorturl.at/jmzH0

  features: {
    // New feature for more performance and avoiding
    // issues with node libs. Comment this out to
    // get the traditional behavior:
    ignoreUnusedDeps: true
  }
});

So far, we have configured two client applications, and you should be able to run them independently on ports 4201 and 4202. In this way, you can create any number of client applications and set up independent deployment pipelines for each of them.

Creating Host App

Let’s create a host app using the Angular CLI command:

ng new host-app 

After scaffolding the application, use the following schematic command to configure it as the host application.

ng add @angular-architects/native-federation --project host-app --port 4200 --type dynamic-host

After the installation completes successfully:

• A new federation.config.js file is added to the project.
• The federation.manifest.json file is added to the public folder.
• The main.ts file is updated.
• The angular.json file is updated.

The updated main.ts should look like this:

import { initFederation } from '@angular-architects/native-federation';

initFederation('federation.manifest.json')
  .catch(err => console.error(err))
  .then(_ => import('./bootstrap'))
  .catch(err => console.error(err));

You can also see the corresponding changes reflected in the angular.json file build and serve section, as shown below.

Loading Remote Applications Dynamically

Ideally, you should not make any changes to the scaffolded configuration, including the federation.config.ts file. The only file you need to update is federation.manifest.json, where you add the client application information.

{
    "client1": "http://localhost:4201/remoteEntry.json",
    "client2": "http://localhost:4202/remoteEntry.json"
}

Here, client1 and client2 correspond to the two remote applications. You can choose any names you like, but make sure to use the same names when configuring the routes in the host application.

In the host application, you can create routes corresponding to the remote apps as shown below:

export const routes: Routes = [
{
   path:'home',
   component:Home
},
 {
    path: 'client1',
    loadChildren: () =>
      loadRemoteModule('client1', './Routes').then((m) => m.routes),
  },
   {
    path: 'client2',
    loadComponent: () =>
      loadRemoteModule('client2', './Component').then((m) => m.App),
  },
  { path: '', redirectTo: 'home', pathMatch: 'full' },

];

Next, add the router-outlet and the navigation links to move between the different remote applications, as shown below.

<h1>MFE APP</h1>
<hr/>
<button routerLink="/home" routerLinkActive="active">Home</button>
<button routerLink="/client1" routerLinkActive="active">Client1</button>
<button routerLink="/client2" routerLinkActive="active">Client2</button>
<hr/>
<router-outlet></router-outlet>

Now, when you navigate to client1, the first remote application loads. Similarly, when you navigate to client2, the second remote application loads.

If you want to load applications side by side without navigating to different URLs, you can achieve this by using Angular’s dynamic component loading feature.

@ViewChild('vcHostClient1', { read: ViewContainerRef, static: true }) vcHostClient1!: ViewContainerRef;

   @ViewChild('vcHostClient2', { read: ViewContainerRef, static: true }) vcHostClient2!: ViewContainerRef;

  async loadCient1(){

     const {App} = await loadRemoteModule('client1','./Component');
     console.log(App);
     this.vcHostClient1.clear();
     this.vcHostClient1.createComponent(App);
  }

  async loadClient2(){
    const {App} = await loadRemoteModule('client2','./Component');
     console.log(App);
     this.vcHostClient2.clear();
     this.vcHostClient2.createComponent(App);
  }

And on the template, create ng-template to load as shown below:

<button (click)="loadCient1()">Load Client 1</button>
<button (click)="loadClient2()">Load Client 2</button>

<ng-template #vcHostClient1></ng-template>
<ng-template #vcHostClient2></ng-template>

So that's how you can load remote apps in different ways.

Summary

In this article, we learned step by step how to build a micro-frontend application using Native Federation. I hope you found it helpful—thanks for reading!

Angular services are a core feature of the framework, used to share data and functionality across components. Their primary purposes include:

• Angular services are classes used to organize and share reusable logic across components.
• They help keep components clean by handling data, business rules and API interactions.
• Services use Angular’s dependency injection system, making them easy to share and test.
• They can also act as lightweight state stores using signals, computed values and effects.

You create an Angular service by running a CLI command:

ng g s log

This command should scaffold the LogService as shown below:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class Log {
  
}

When you create a service in Angular, you encounter two key characteristics:

1. Services are tree-shakeable
2. Services are singletons

In this article, we will explore the truthfulness of these two behaviors in depth. Read on.

Are Angular Services Tree-Shakeable?

By default, Angular services are tree-shakeable. Tree-shaking is a dead code elimination technique that removes unused code from the final bundle, reducing application size and improving performance.

Angular tree-shakes a service and excludes it from the final bundle:

1. If it is provided with providedIn option
2. If it is not re-provided anywhere in the application using providers array
3. If it is not used anywhere in the application

Let’s consider the service below. We are just logging a message in the service file.

import { Injectable } from '@angular/core';

console.log('service is part of the bundle');

@Injectable({
  providedIn: 'root',
})
export class Log {

}

Let’s assume that this service is not used anywhere in the application, and you run the Angular application. In the browser console, you won’t find the message logged.

Next, in the AppComponent (the root component of the application) or any other component, add the LogService to the providers array, as shown below.

@Component({
  selector: 'app-root',
  imports: [],
  templateUrl: './app.html',
  providers:[Log],
  styleUrl: './app.css'
})
export class App {
 
}

Even in this case, the service isn’t being used anywhere in the application. However, you can still see its messages logged in the browser. This happens because when a service is added to the providers array of any component, it is no longer tree-shakeable. As a result, Angular includes it in the final output bundle, even if it’s never actually used in the application.

The takeaway is that a service provided with providedIn is tree-shakeable, but a service provided in a component’s providers array is not tree-shakeable.

Are Services Singletons?

By default, Angular Services are singletons. This means that if you do not re-provide them, Angular creates only one object of the service. To understand this, let’s modify the service as shown below:

@Injectable({
  providedIn: 'root',
})
export class Log {

  private static instanceCount = 0;

  constructor() {
    Log.instanceCount++;
    console.log(`Log service instance count: ${Log.instanceCount}`);
  }

}

We add a static variable to count the number of instances Angular creates for this service. And, in the constructor, we increment it to track the number of objects.

Next, we use the LogService in two or more different components. To do that, we simply inject the service as shown below.

@Component({
  selector: 'app-child2',
  imports: [],
  templateUrl: './child2.html',
  styleUrl: './child2.css',
})
export class Child2 {

  logService  = inject(Log);

}

And in other components as shown below:

@Component({
  selector: 'app-child1',
  imports: [],
  templateUrl: './child1.html',
  styleUrl: './child1.css',
})
export class Child1 {

  logService = inject(Log);

}

So, even though the LogService is injected into two components, Angular still creates only one instance of it. In the browser console, you should see the following output.

Now, let’s go ahead and re-provide the service again in the Child2Component.

@Component({
  selector: 'app-child2',
  imports: [],
  templateUrl: './child2.html',
  styleUrl: './child2.css',
  providers:[Log]
})
export class Child2 {

  log = inject(Log);

}

You will observe that two objects have been created in the service.

By default, an Angular service is a singleton, but if it is provided again in a component’s providers array, Angular creates additional instances.

Please be informed that even if a service is provided in five different components, Angular does not necessarily create five separate instances. The actual number of instances depends on the provider hierarchy.

Let’s understand the above statement with an example. We have created a service as shown below:

@Injectable({
  providedIn: 'root',
})
export class Log {

  private static count = 0;

  constructor() {
    Log.count = Log.count + 1;
    console.log(`Log service instance count: ${Log.count}`);
  }

  counter = 0;

  setCount() {
    this.counter = this.counter + 1;
  }

  getCount() {
    return this.counter;
  }
}

The LogService is used on the child1 component:

import { Component, inject } from '@angular/core';
import { Log } from '../log';

const template = `
<p>Child 1 Count = {{log.getCount()}}</p>
<button (click)="update()">Update Count </button>
`

@Component({
  selector: 'app-child1',
  imports: [],
  template: template,
  providers: []
})
export class Child1 {

  log = inject(Log);

  update() {
    this.log.setCount();
  }

}

Next, it is used on the Child2 component:

import { Component, inject } from '@angular/core';
import { Log } from '../log';

const template = `
<p>Child 2 Count = {{log.getCount()}}</p>
<button (click)="update()">Update Count </button>
`

@Component({
  selector: 'app-child2',
  template: template,
  providers: []
})
export class Child2 {

  log = inject(Log);

  update() {
    this.log.setCount();
  }
}

Both of these components are used in the App Component:

import { Component } from '@angular/core';
import { Child1 } from './child1/child1';
import { Child2 } from './child2/child2';

const template =` <h1>App Component</h1>
<app-child1></app-child1>
<app-child2></app-child2>
`

@Component({
  selector: 'app-root',
  imports: [Child1,Child2],
  template: template,
  providers:[]
})
export class App {

}

Now, when you run the application, you can see that data is passed between the Child1 and Child2 components, and Angular creates only one instance of the LogService.

Next, let’s make a small change and add LogService to the providers array of the Child2 component.

@Component({
  selector: 'app-child2',
  template: template,
  providers: [Log]
})
export class Child2 {

  log = inject(Log);

  update() {
    this.log.setCount();
  }
}

Now, what do you notice in the output? You should see the following:

1. Two separate instances of LogService are created.
2. Data is no longer shared between the Child1 and Child2 components.

Next, let’s make another small change and add LogService to the providers array of the App Component.

import { Component } from '@angular/core';
import { Child1 } from './child1/child1';
import { Child2 } from './child2/child2';
import { Log } from './log';

const template = ` <h1>App Component</h1>
<app-child1></app-child1>
<app-child2></app-child2>
`

@Component({
  selector: 'app-root',
  imports: [Child1, Child2],
  template: template,
  providers: [Log]
})
export class App {

}

Now, what do you observe in the output? Data is still not shared between the Child1 and Child2 components, and only two instances of LogService are created.

Two instances of LogService are created, not three. You might wonder why it is not three, even though LogService is provided in multiple places:

1. The Child1 Component
2. The App Component
3. And using the providedIn option in the service itself

Let’s understand the above behavior. Angular works with a service in the following steps:

• Step 1 – Is the service used?
• Step 2 – Is the service injected?
• Step 3 – Is the service provided?

So, from the above steps, if a service is used but not injected, Step 2 fails. And for that, Angular gives a compilation error. It searches for the injection in the same component.

However, whether a service is actually provided is determined by Angular at runtime. So, if a service is used and injected but not provided, Angular throws a runtime error, which looks something like this:

Angular searches for a service provider in the component tree hierarchy. It first looks in the current component; if it finds a provider there, it uses that instance. If not, it moves up to the parent component and continues searching.

If no provider is found in the hierarchy, Angular finally uses the provider configuration defined in the service itself. If it still doesn’t find a provider configuration in the service, Angular throws a runtime error like the one shown above.

Let’s apply the above explanation to the Child2 component.

For the Child2 component, since Angular finds the LogService provided directly in the component, it uses the instance created there and does not continue searching in parent components or in the service’s own provider configuration.

However, for the Child1 component, Angular does not find LogService provided within the component itself, so it moves up to the parent AppComponent and finds it there. It then uses that instance and does not continue searching in the service’s own provider configuration.

Now you can see that the Child1 and Child2 components use different instances of LogService, which is why they cannot share data between them.

Also, because LogService is used in only two places, Angular creates one instance for the Child2 component (since it is provided there) and another instance for the Child1 component (from the AppComponent). Angular never reaches the service’s own provider configuration to create an additional instance.

This is why only two instances of LogService are created, not three.

Summary

We learned in this article that Angular services are singleton by default, but when a service is re-provided, Angular creates additional instances.

We also saw that, when using services to share data in a large application, we must be careful. If a service is accidentally re-provided, it may behave unexpectedly and fail to share data as intended.

Additionally, a service is tree-shakeable by default, but once it is added to a providers array, it is no longer tree-shakeable.

I hope you found this article useful. Thanks for reading!

In this article, you will learn how to set up Cursor for a modern Angular project (for example, version 21.0) and how to use it in a practical way. We will cover basic setup, useful features and simple examples that you can try right away.

If you are starting a new project with Angular 20 or later, make sure to configure Cursor rules upfront to work with Cursor more effectively.

After successfully executing the command, you’ll notice that along with the scaffolded Angular project, the Angular CLI also adds a cursor.mdc rule file to the project.

You can modify the generated rule file to suit your project requirements. Feel free to customize the Cursor rules as needed. For example, as shown below, I have specified the Angular version to be used by the agents.

If you are working with an existing project, you can manually add the Cursor rules file to the project. Make sure to add the rule in the root of the project inside .cursor/rules. You can also go to Cursor-> Settings -> Cursor Setting -> Rules, Skills, Subagents to add a rule using the IDE.

Cursor automatically detects rules from .cursor/rules/cursor.mdc or .cursor/rules.md. When using Angular CLI, a cursor.mdc file is already added, so do not add rules.md. You should have only one of these files in the project.

Also, verify that alwaysApply: true is set in the rule file. Alternatively, you can manually add the following line at the top of the cursor.mdc file.

alwaysApply: true

You may also enable this setting by selecting the option from the dropdown at the top of the file in the Cursor IDE, as shown in the image below.

Always make sure to configure project rules to:

• Apply domain-specific knowledge to the codebase
• Set the version to be used
• Select architecture decisions regarding whether to use signals or RxJS
• Use a specific coding style

To validate whether the rule is applied to your project or not, open the chat in ask mode and ask which version you are using as shown image below:

Next, make sure to connect to the Angular MCP server. To do that on the terminal run the command:

ng mcp

Next, in the Cursor IDE, go to Cursor-> Settings -> Cursor Setting -> Tools and MCP to add a custom MCP.

Paste the configuration created by the ng mcp command.

{
  "mcpServers": {
    "angular-cli": {
      "command": "npx",
      "args": ["-y", "@angular/cli", "mcp"]
    }
  }
}

After adding the Angular MCP server, you can validate the setup by asking Cursor to list all the MCP servers it is using, and it should list the Angular MCP server as shown in the image below.

After setting up these elements, open the Agent pane and we’ll create a plan to implement the login screen in Angular.

As shown in the image above, I have selected Plan Mode and am asking very specific questions. I am clear on what I want to implement, which features I want to use and which I do not.

Cursor created a plan that closely matches what I wanted, and I am satisfied with it. As shown in the image below, it uses the latest form functions to create a signal-based form and also indicates that it used the Angular MCP server to do this.

Next, click the Build button. The cursor will switch to Agent mode, and the Login feature will be built according to the plan. Once the cursor finishes creating the code, click Review to begin reviewing the generated code.

After review, click either Keep All or Commit to commit the code to the project.

If you are on the main branch, it may ask you whether you want to create a new branch or commit to the main branch.

After completing this setup, Cursor generated the LoginComponent, which uses the latest Signal Forms, and I am very happy with the result.

export class LoginComponent {
  protected readonly loginModel = signal<LoginData>({
    email: '',
    password: '',
  });

  protected readonly loginForm = form(this.loginModel, (path) => {
    required(path.email, { message: 'Email is required' });
    email(path.email, { message: 'Enter a valid email address' });
    required(path.password, { message: 'Password is required' });
  });

  protected onSubmit(event: Event): void {
    event.preventDefault();
    submit(this.loginForm, async () => {
      const credentials = this.loginModel();
      console.log('Logging in with:', credentials);
    });
  }
}

The generated code is based on Angular 21.0 features and adheres to project-specific rules defined in the Angular MCP Server. As your project grows, you can add more rules at different levels, but this guide should be enough to help you get started.

I hope you find this article useful. Thanks for reading.

Angular has changed a lot in the last few years. We now are at Version 20. We can simplify the Angular setup with Firebase, and only add the minimum necessary packages and server infrastructure to get our app working in any environment.

TL;DR

This app setup takes the best of Firebase setups to cover all your bases. You can fetch data purely on the server for good SEO, validate the schema meta data and have a safe “login wall” to prevent unauthorized user access on the client. No need for cookies, sessions or authorization on the server.

Remove ZoneJS

We do NOT need ZoneJS anymore. Signals make Angular faster and more responsive, and remove unnecessary bloat.

AnalogJS

Generate a new Analog component, or use an existing one.

app.config.ts

import {
  provideHttpClient,
  withFetch,
  withInterceptors,
} from '@angular/common/http';
import {
  ApplicationConfig,
  provideBrowserGlobalErrorListeners,
  provideZonelessChangeDetection
} from '@angular/core';
import { provideClientHydration, withEventReplay } from '@angular/platform-browser';
import { provideFileRouter, requestContextInterceptor } from '@analogjs/router';

export const appConfig: ApplicationConfig = {
  providers: [
    provideBrowserGlobalErrorListeners(),
    provideZonelessChangeDetection(), // <----- change
    provideFileRouter(),
    provideHttpClient(
      withFetch(),
      withInterceptors([requestContextInterceptor])
    ),
    provideClientHydration(withEventReplay()),
  ],
};

Here we change out the Zone provider for a Zoneless one.

npm uninstall zone.js

Also, remove any imports in the main.server.ts and in main.ts.

// Remove these lines
import 'zone.js/node';
import 'zone.js';

vite.config.ts

I also added an alias for @lib, services and @components. I changed the default public prefix for .env info from VITE_ to PUBLIC_, but this is optional. Feel free to change the preset to where you want to deploy.

/// <reference types="vitest" />

import { defineConfig } from 'vite';
import analog from '@analogjs/platform';
import tailwindcss from '@tailwindcss/vite';
import { resolve } from 'path';

// https://vitejs.dev/config/
export default defineConfig(() => ({
  build: {
    target: ['es2020'],
  },
  envPrefix: ['PUBLIC_'],
  resolve: {
    alias: {
      '@services': resolve(__dirname, './src/app/services'),
      '@components': resolve(__dirname, './src/app/components'),
      '@lib': resolve(__dirname, './src/app/lib')
    },
    mainFields: ['module']
  },
  plugins: [
    analog({
      ssr: true,
      static: false,
      nitro: {
        alias: {
          '@lib': resolve(__dirname, './src/app/lib'),
          '@services': resolve(__dirname, './src/app/services'),
          '@components': resolve(__dirname, './src/app/components'),
        },
        preset: 'vercel-edge'
      },
      prerender: {
        routes: [],
      },
    }),
    tailwindcss()
  ],
}));

Utility Functions

For many apps I use in Angular, I have created a few reusable utility functions.

import { TransferState, inject, makeStateKey } from "@angular/core";
import { ActivatedRoute } from "@angular/router";
import { map } from "rxjs";

export const useAsyncTransferState = async <T>(
    name: string,
    fn: () => T
) => {
    const state = inject(TransferState);
    const key = makeStateKey<T>(name);
    const cache = state.get(key, null);
    if (cache) {
        return cache;
    }
    const data = await fn() as T;
    state.set(key, data);
    return data;
};

export const useTransferState = <T>(
    name: string,
    fn: () => T
) => {
    const state = inject(TransferState);
    const key = makeStateKey<T>(name);
    const cache = state.get(key, null);
    if (cache) {
        return cache;
    }
    const data = fn() as T;
    state.set(key, data);
    return data;
};

export const injectResolver = <T>(name: string) =>
    inject(ActivatedRoute).data.pipe<T>(map(r => r[name]));

export const injectSnapResolver = <T>(name: string) =>
    inject(ActivatedRoute).snapshot.data[name] as T;

• useAsyncTransferState – This allows the data to be fetched on the server once and hydrated to the browser. By default, the server would fetch the data, then the client would refetch the data. We don’t want extraneous reads in Firestore.
• injectResolver and injectSnapResolver are helpers to add the resolver data to your component.

schema.service.ts

By default, you can inject Meta to add meta data. However, there is no default schema tool. I created a basic one.

import { Injectable, Inject } from '@angular/core';
import { DOCUMENT } from '@angular/common';

@Injectable({ providedIn: 'root' })
export class Schema {
    constructor(@Inject(DOCUMENT) private document: Document) { }

    /**
     * Adds or updates a JSON-LD script tag in <head>, similar to Title/Meta.
     */
    setSchema(data: Record<string, unknown>, id = 'jsonld-schema'): void {
        const json = JSON.stringify(data).replace(/</g, '\\u003c');

        // Avoid duplicates
        let script = this.document.head.querySelector<HTMLScriptElement>(
            `script#${id}[type="application/ld+json"]`
        );

        if (!script) {
            script = this.document.createElement('script');
            script.id = id;
            script.type = 'application/ld+json';
            this.document.head.appendChild(script);
        }

        script.textContent = json;
    }

    /** Optional cleanup */
    removeSchema(id = 'jsonld-schema'): void {
        const existing = this.document.getElementById(id);
        if (existing) {
            this.document.head.removeChild(existing);
        }
    }
}

Firebase

Next, install pure Firebase. DO NOT use @angular/fire, as it is built with ZoneJS in mind.

npm i firebase

ENV

Set up your .env file to have your firebase public API key available.

PUBLIC_FIREBASE_CONFIG={"apiKey":...."authDomain"...,...}

Next, create the Firebase Service file which will have your firebase sharing injection tokens.

import { isPlatformBrowser } from "@angular/common";
import { inject, InjectionToken, PLATFORM_ID } from "@angular/core";
import { FirebaseApp, getApp, getApps, initializeApp } from "firebase/app";
import { Auth, getAuth } from "firebase/auth";
import { doc, Firestore, getDoc, getFirestore } from "firebase/firestore";
import {
    getFirestore as getFirestoreLite,
    getDoc as getDocLite,
    doc as docLite
} from 'firebase/firestore/lite'

const firebase_config = JSON.parse(import.meta.env['PUBLIC_FIREBASE_CONFIG']);

export const FIREBASE_APP = new InjectionToken<FirebaseApp>(
    'firebase-app',
    {
        providedIn: 'root',
        factory() {
            return getApps().length
                ? getApp()
                : initializeApp(firebase_config);

        }
    }
);

export const FIREBASE_AUTH = new InjectionToken<Auth | null>(
    'firebase-auth',
    {
        providedIn: 'root',
        factory() {
            const platformID = inject(PLATFORM_ID);
            if (isPlatformBrowser(platformID)) {
                const app = inject(FIREBASE_APP);
                return getAuth(app);
            }
            return null;
        }
    }
);

export const FIREBASE_FIRESTORE = new InjectionToken<Firestore>(
    'firebase-firestore',
    {
        providedIn: 'root',
        factory() {
            const platformID = inject(PLATFORM_ID);
            const app = inject(FIREBASE_APP);
            if (isPlatformBrowser(platformID)) {
                return getFirestore(app);
            }
            return getFirestoreLite(app);
        }
    }
);

export const FIRESTORE_GET_DOC = new InjectionToken(
    'firestore-get-doc',
    {
        providedIn: 'root',
        factory() {
            const db = inject(FIREBASE_FIRESTORE);
            const platformID = inject(PLATFORM_ID);
            return async <T>(path: string) => {

                try {

                    const snap = isPlatformBrowser(platformID)
                        ? await getDoc(doc(db, path))
                        : await getDocLite(docLite(db, path));
                    if (!snap.exists()) {
                        throw new Error(`Document at path "${path}" does not exist.`);
                    }
                    return {
                        data: snap.data() as T,
                        error: null
                    };

                } catch (e) {
                    
                    return {
                        data: null,
                        error: e
                    };
                }
            }
        }
    }
);

Breakdown

1. First, we import our firebase config and parse the JSON data so it can be read.
2. firebase-app makes sure we initialize Firebase only once.
3. firebase-auth will return null if on the server. We only need to use it on the browser.
4. firebase-firestore has two versions. The Firestore Lite package at firebase/firestore/lite will be faster, does not require TCP and will run in any environment. This means if you deploy to Vercel Edge, Deno, Cloudflare or Bun, it will still work!
5. firestore-get-doc is just a shortcut for us to get rid of the boilerplate of asynchronously fetching a document.

Authentication

We need an authentication service to handle login actions. This is only used on the client.

import {
    DestroyRef,
    InjectionToken,
    inject,
    isDevMode,
    signal
} from '@angular/core';
import {
    GoogleAuthProvider,
    User,
    onIdTokenChanged,
    signInWithPopup,
    signOut
} from 'firebase/auth';
import { FIREBASE_AUTH } from './firebase.service';

export interface userData {
    photoURL: string | null;
    uid: string;
    displayName: string | null;
    email: string | null;
};

export const USER = new InjectionToken(
    'user',
    {
        providedIn: 'root',
        factory() {

            const auth = inject(FIREBASE_AUTH);
            const destroy = inject(DestroyRef);

            const user = signal<{
                loading: boolean,
                data: userData | null,
                error: Error | null
            }>({
                loading: true,
                data: null,
                error: null
            });

            // server environment
            if (!auth) {
                user.set({
                    data: null,
                    loading: false,
                    error: null
                });
                return user;
            }

            // toggle loading
            user.update(_user => ({
                ..._user,
                loading: true
            }));

            const unsubscribe = onIdTokenChanged(auth,
                (_user: User | null) => {

                    if (!_user) {
                        user.set({
                            data: null,
                            loading: false,
                            error: null
                        });
                        return;
                    }

                    // map data to user data type
                    const {
                        photoURL,
                        uid,
                        displayName,
                        email
                    } = _user;
                    const data = {
                        photoURL,
                        uid,
                        displayName,
                        email
                    };

                    // print data in dev mode
                    if (isDevMode()) {
                        console.log(data);
                    }

                    // set store
                    user.set({
                        data,
                        loading: false,
                        error: null
                    });
                }, (error) => {

                    // handle error
                    user.set({
                        data: null,
                        loading: false,
                        error
                    });

                });

            destroy.onDestroy(unsubscribe);

            return user;
        }
    }
);

export const LOGIN = new InjectionToken(
    'LOGIN',
    {
        providedIn: 'root',
        factory() {
            const auth = inject(FIREBASE_AUTH);
            return () => {
                if (!auth) {
                    return null;
                }
                return signInWithPopup(
                    auth,
                    new GoogleAuthProvider()
                );
            };
        }
    }
);

export const LOGOUT = new InjectionToken(
    'LOGOUT',
    {
        providedIn: 'root',
        factory() {
            const auth = inject(FIREBASE_AUTH);
            return () => {
                if (!auth) {
                    return null;
                }
                return signOut(auth);
            };
        }
    }
);

Breakdown

1. USER will use onIdTokenChanged to get the latest user state and set it to a signal that is updated in real time. You can check loading states or errors. It gets destroyed when the component is unmounted by using onDestroy.
2. LOGIN is a callable function to login with the Google provider. It is meant to be called from a button on the client.
3. LOGOUT is the logout method that destroys the session on the client. It is also meant to be called from the client only.

Layout

We can edit the app.ts file to get our layout.

import { Component } from '@angular/core';
import { RouterLink, RouterOutlet } from '@angular/router';

@Component({
  selector: 'app-root',
  imports: [RouterOutlet, RouterLink],
  template: `
  <div class="pt-5">
    <router-outlet />
  </div>  
  <nav class="flex gap-3 justify-center mt-5">
      <a routerLink="/">Home</a>
      <a routerLink="/about">About</a>
      <a routerLink="/wall">Login Wall</a>
  </nav>
  `,
})
export class AppComponent { }

1. Home will display our login state and profile.
2. About will display the About information from the server OR the client, whether or not we are logged in. It also populates the schema and meta tags so that it can be SEO friendly.
3. Login Wall will ONLY work when a user is logged in. You do not need to load data directly from the server, as Firebase has Firebase Rules for that, and SEO is unnecessary behind a login wall.

Home

For the home component, we only need to inject the user and login tokens from our auth service.

home.component.ts

import { Component, inject } from '@angular/core';
import { ProfileComponent } from '@components/profile/profile.component';
import { LOGIN, USER } from '@lib/firebase/auth.service';

@Component({
  selector: 'app-home',
  standalone: true,
  imports: [ProfileComponent],
  templateUrl: './home.component.html'
})
export class HomeComponent {
  user = inject(USER);
  login = inject(LOGIN);
}

home.component.html

<div class="text-center">
    <h1 class="text-3xl font-semibold my-3">Analog Firebase App</h1>

    @if (user().loading) {

    <p>Loading...</p>

    } @else if (user().data) {

    <app-profile />

    } @else if (user().error) {

    <p class="text-red-500">Error: {{ user().error?.message }}</p>

    } @else {

    <button type="button" class="border p-2 rounded-md text-white bg-red-600" (click)="login()">
        Signin with Google
    </button>

    }
</div>

We display errors when necessary, and we show the app-profile component on success.

Profile

Because we are logged in already, we only need to show logout and user info.

profile.component.ts

import { Component, inject } from '@angular/core';
import { LOGOUT, USER } from '@lib/firebase/auth.service';

@Component({
  selector: 'app-profile',
  standalone: true,
  imports: [],
  templateUrl: './profile.component.html'
})
export class ProfileComponent {
  user = inject(USER);
  logout = inject(LOGOUT);
}

profile.component.html

<div class="flex flex-col gap-3 items-center">
    <h3 class="font-bold">Hi {{ user().data?.displayName }}!</h3>
    <img [src]="user().data?.photoURL" width="100" height="100" alt="user avatar" />
    <p>Your userID is {{ user().data?.uid }}</p>
    <button type="button" class="border p-2 rounded-md text-white bg-lime-600" (click)="logout()">
        Logout
    </button>
</div>

Buttons can only be called on the server.

About Data

Our About data is the key to SEO.

About Resolver

We need to force our Angular component to wait for our About data to be fetched. The correct place to do this is in an Angular Resolver, although you can use Pending Tasks in more complex situations.

about-data.resolver.ts

import { inject, isDevMode } from '@angular/core';
import { Meta, Title } from '@angular/platform-browser';
import { ResolveFn } from '@angular/router';
import { FIRESTORE_GET_DOC } from '@lib/firebase/firebase.service';
import { useAsyncTransferState } from '@lib/utils';
import { Schema } from './schema.service';

export type AboutDoc = {
    name: string;
    description: string;
};

export const aboutDataResolver: ResolveFn<AboutDoc> = async () => {

    return useAsyncTransferState('about', async () => {

        const getDoc = inject(FIRESTORE_GET_DOC);

        const meta = inject(Meta);
        const title = inject(Title);
        const schema = inject(Schema);

        const {
            data,
            error
        } = await getDoc<AboutDoc>('/about/ZlNJrKd6LcATycPRmBPA');

        if (error) {
            throw error;
        }

        if (!data) {
            throw new Error('No data found');
        }

        title.setTitle(data.name);
        meta.updateTag({
            name: 'description',
            content: data.description
        });
        schema.setSchema({
            '@context': 'https://schema.org',
            '@type': 'WebPage',
            name: data.name,
            description: data.description
        });

        if (isDevMode()) {
            console.log(data);
        }

        return data;
    });

};

This resolver uses all our utility files in one go. We fetch our Firestore document by providing the path, set the title, meta tag and schema before returning the data. We do this in a transfer state so that we only have to fetch the data once on the server. Bing!

about-data.component.ts

We inject our transfer data from the resolver and display it.

import { Component } from '@angular/core';
import { AboutDoc } from './about-data.resolver';
import { injectResolver } from '@lib/utils';
import { AsyncPipe } from '@angular/common';

@Component({
    selector: 'app-about-data',
    standalone: true,
    imports: [AsyncPipe],
    template: `
    @if (about | async; as data) {
    <div class="flex items-center justify-center my-5">
        <div class="border w-[400px] p-5 flex flex-col gap-3">
            <h1 class="text-3xl font-semibold">{{ data.name }}</h1>
            <p>{{ data.description }}</p>
        </div>
    </div>
    <p class="text-center">
        <a href="https://validator.schema.org/#url=https%3A%2F%2Fultimate-analog-firebase.vercel.app%2Fabout" target="_blank" class="text-blue-600 underline">Validate Schema.org Metadata</a>
    </p>
    }
    `
})
export default class AboutDataComponent {
    about = injectResolver<AboutDoc>('data');
}

We must import the AsyncPipe and add it to an @if statement. Then we can display our data. The server will wait.

Notice we use a standalone component here. Sometimes it is good to mix and match depending on readability or preference.

Login Wall

We do not want to fetch on the server, but on the client only. The resource directive gives us the perfect tools to handle loading and error states.

import { Component, inject, isDevMode, resource } from '@angular/core';
import { FIRESTORE_GET_DOC } from '@lib/firebase/firebase.service';
import { FirebaseError } from 'firebase/app';

export type WallDoc = {
    name: string;
    description: string;
};

@Component({
    selector: 'app-wall-data',
    standalone: true,
    imports: [],
    template: `
    @if (wall.isLoading()) {
    <div class="flex items-center justify-center my-5">
        <h1 class="text-3xl font-semibold">Loading...</h1>
    </div>
    } @else if (wall.status() === 'resolved') {
    <div class="flex items-center justify-center my-5">
        <div class="border w-[400px] p-5 flex flex-col gap-3">
            <h1 class="text-3xl font-semibold">{{ wall.value()?.name }}</h1>
            <p>{{ wall.value()?.description }}</p>
        </div>
    </div>
    } @else if (wall.status() === 'error') {
    <div class="flex items-center justify-center my-5">
        @if (wall.error()?.message === 'permission-denied') {
            <h1 class="text-3xl font-semibold">You must be logged in to view this!</h1>
        } @else {
            <h1 class="text-3xl font-semibold">An error occurred: {{ wall.error()?.message }}</h1>
        }
    </div>
    } @else {
    <div class="flex items-center justify-center my-5">
        <h1 class="text-3xl font-semibold">You must be logged in to view this!</h1>
    </div>
    }
    `
})
export default class WallDataComponent {

    getDoc = inject(FIRESTORE_GET_DOC);

    wall = resource({

        loader: async () => {

            const {
                data,
                error
            } = await this.getDoc<WallDoc>('/secret/tJKWxu0ls6R0RyH1Atpb');

            if (error) {

                if (error instanceof FirebaseError) {

                    if (error.code === 'permission-denied') {
                        throw new Error(error.code);
                    }

                    console.error(error);
                    throw error;
                }
            }

            if (!data) {
                throw new Error('No data returned');
            }

            if (isDevMode()) {
                console.log(data);
            }

            return data;
        }
    });
}

• We fetch our document in resource({ loader: ... });.
• We throw and error to use it in our template.
• Our signals are:
  • wall.isLoading()
  • wall.status() === 'resolved'
  • wall.status() === 'error'
• We check for the specific permission-denied error to show our not logged-in message.

Firebase Rules

For our login wall, we can create a Firestore Rule to prevent a document from being read unless the user is logged in. We could equally add roles, etc.

service cloud.firestore {

  match /databases/{database}/documents {
    match /{document=**} {
    
      match /secret/{document} {
      allow read: if request.auth != null;
      }
      
      ...

Final Thoughts

I firmly believe this is all you need for 99% of Firebase apps. I have written articles on Firebase Admin Setup and Service Worker with Firebase Lite if you want to go down that rabbit hole, but you really don’t need them.

You also really don’t need real-time data unless you’re building a chat app or using notifications, but that can be easily added.

This basic setup, using Angular 20+, signals, pure Firebase, Firestore Lite and clean injection tokens, should cover all your needs.

Repo: GitHub
Demo: Vercel Edge Functions

There is hardly a website you will come across that does not have images, and this shows how indispensable they are in driving sales, enhancing credibility and improving user engagement.

While this is good news, on the other hand, images contribute to 42% of why websites are slow, as they take up significant bandwidth and are a major contributor to why websites do not meet the standard requirements for performance on the internet, as defined by Google’s Core Web Vitals and its LCP metric.

This raises the important question of how best to take advantage of images. The answer is image optimization—a set of techniques that enable web developers to effectively use images and deliver the best user experience.

Framework developers, having understood the difficulties developers face while using images, have created tools to do the heavy lifting. In this article, we will go through the use of Angular’s NgOptimizedImage directive, which builds on top of the traditional <img/> element with some enhancements. We will see how it can be used to address some common image optimization concerns effortlessly.

Things We Need to Optimize When Using Images

This section will discuss a set of areas that require attention to get it right with images, irrespective of the platform on which images are used. The browser provides two main tags to work with images: <picture/> and <img/>, with the latter being the preferred option.

As we go over these areas and the techniques used, where necessary we will also specify attributes provided by the img element that can be used to solve these problems.

We will split our optimization concerns into three categories:

• Those that have to do with a single image
• Working with multiple images
• Meeting standards

Single Image

Optimizing a single image involves the following:

Format

Different image formats provide different compression levels and are best suited for different purposes:

• Verify that the right image format is used for the right purpose. For example, PNGs are best suited for graphic content, and AVIF or WebP should be preferred over older formats like JPEG, since they yield smaller file sizes with greater quality and reduced bandwidth.
• For local images, you may need to use tools like Photoshop, FFmpeg, Squoosh or another media manipulation tool to convert between formats before using them on your website. However, if images are stored on a CDN provisioned by some provider (e.g., Cloudinary), tools are provided to convert between formats.

Resolution Switching and Viewport-Based Sizing

Devices have different resolutions and pixel densities/ratios. Developers need to serve the right image to the right device.

Device pixel ratio, in simple terms, refers to how many of the device’s physical pixels can fit into the dimensions of a CSS pixel. So a device with a higher DPR should be served a high-resolution image and vice versa.

The img element ships with two main attributes to solve this problem. The srcset attribute allows developers to configure the candidate images to enable browsers to select the right one.

Multiple Images

When working with multiple images, optimization concerns involve the following:

• Lazy loading images
• Giving priority to more important images

Lazy Loading Images

Lazy loading means that only the required image(s) are presented to the user, which saves bandwidth and reduces the page’s critical rendering path, which in turn lowers its load time. The img tag ships with the loading attribute, which can be set to “lazy” to achieve this behavior.

Low-quality image placeholders should be used in conjunction with lazy loading to minimize the perceived loading time while the browser downloads the actual image. For local images, developers may need to generate placeholders manually or use specialized tools. When using a remote provider, some JavaScript is still required to display the placeholder before the browser downloads the actual image.

Giving Priority to More Important Image(s)

Not all images on a page are of equal importance (e.g., LCP—Largest Contentful Paint—images). Developers should prioritize more important images over less important ones. The img tag provides the loading and fetchPriority attributes to solve these issues, together with preloading the image using the link element.

Optimizing for Standard

Optimizing a standard image involves the following:

• Optimize for LCP (Largest Contentful Paint)
• Optimize for CLS (Cumulative Layout Shift)

Optimize for LCP

The LCP of a webpage is a measure of how long it takes to display its main content—it could be an image, a section, a video, etc. A good LCP is within the range of 0-2.5s.

When the LCP element on a page is an image, developers should load that image to the webpage as soon as possible while also verifying that the image size is optimized. The img element provides us with loading and fetchPriority attributes. The link element can also be used to prioritize fetching important assets, such as images on the webpage.

Optimize for CLS

Layout shifts occur when there is a sudden movement of one or more elements on the webpage because something changed or was introduced to the DOM while the webpage was still loading. With images, it occurs when the browser loads the image at a later time after loading some of the other content on the page, and when space was not reserved for the image. So after the image is added to the DOM, other elements are displaced.

When images are not used as background images, it is essential to define a width and height for the image so that the space is reserved for the image, even when the load time is delayed.

The NgOptimizedImage Directive

We have discussed the different things we need to optimize when using images, and those that we can resolve using combinations of one or more attributes provided by the img element. One might wonder why we still need the NgOptimizedImage directive. Let’s go over a few points.

The NgOptimizedImage directive builds on top of the img element and enhances it in the following ways:

• First, out of the box, it defines some important attributes when using the img element, so that developers do not have to remember to use them and can focus on building their applications.
• It enables developers to use images optimized to meet standard requirements. By default, when using this directive, you are required to provide a width and height when images are not used as background images, so that layout shifts do not happen when loading images.
• Out of the box, it integrates well with third-party media providers such as Cloudinary, ImageKit, Cloudflare, etc., so developers can easily use these services and get even better optimization.

NgOptimizedImage in Action

Let’s now see this directive in action. We will revisit the image optimization areas we listed earlier and see firsthand how to use the NgOptimizedImage directive in code. We will see how each step can be achieved with local and remote images.

Project Setup

Run the command below to clone the starter project:

https://github.com/christiannwamba/ng-image-optimization

Our starter application has a few local images in its /public folder.

Apart from the root app component, the demo application defines three other components:

• local.component.ts: The component in this file will show how to use local images.
• remote-image.component.ts: The component in this file will show how to use remote images.
• local-and-remote-image.component.ts: We will update this component later to see how to use local and remote images in one component using custom loaders.

Basic Use

Let’s start by showing the basic use of this directive.

Local Image

Update your local.component.ts file with the following:

import { Component } from "@angular/core";
import { NgOptimizedImage } from "@angular/common";
@Component({
  selector: "local-use",
  imports: [NgOptimizedImage],
  template: `
    <h3>Local image</h3>
    @for (img of localImages; track $index) {
    <div style="padding-top: 700px">
      <img width="800" height="600" [ngSrc]="img" />
    </div>
    }
  `,
  styles: ``,
})
export class LocalImageComponent {
  localImages = [
    "2.webp",
    "3.webp",
    "4.jpg",
    "5.jpg",
    "6.jpg",
    "7.jpg",
    "8.jpg",
    "9.jpg",
  ];
}

Remote Image

Update your remote-image.component.ts file with the following:

import { NgOptimizedImage, provideCloudinaryLoader } from "@angular/common";
import { Component } from "@angular/core";
@Component({
  selector: "remote-image-use",
  imports: [NgOptimizedImage],
  providers: [
    provideCloudinaryLoader("https://res.cloudinary.com/chrisnwamba1"),
  ],
  template: `
    <h3>Remote images</h3>
    @for (img of remoteImages; track $index) {
    <div class="">
      <img width="800" height="600" [ngSrc]="img" />
    </div>
    }
  `,
  styles: ``,
})
export class RemoteImageComponent {
  remoteImages = [
    "jcuh90sdncxwugdsqh40",
    "qowugcszjxcdixvalvcp",
    "err9wujrz1epkrhjbjtz",
    "fypu0o7ea3ssvu4m97uh",
  ];
}

We start by importing the NgOptimizedImage directive and injecting it into the imports array.
In each component, we defined an array of local and remote images in the localImages and remoteImages variables, respectively.

Since we want our remote images to be managed for us by a third-party provider, Cloudinary, in our case, we created a Cloudinary account and uploaded a few images there.

Feel free to use your preferred media provider solution; we just chose to go with Cloudinary in this article.

To work with remote images, we make use of loaders, which are just functions that resolve to URLs. We can create custom loaders or use those that are supported by default. We used the Cloudinary loader by injecting provideCloudinaryLoader, which we fed the base URL pointing to our cloud name.

We used the ngSrc property to set the image source. It is mandatory to define a width and height for images; this helps prevent layout shifts if the image is delayed during loading. Failure to do so will likely result in errors.

You can start your application server by running npm run start. If you go ahead and inspect the img elements, you will notice that both local and remote images are lazy-loaded by default, as indicated by the loading="lazy" attribute, and there is no priority assigned to any image as specified by fetchPriority="auto".

By default, the srcset attribute is added for remote images, and it defines candidate images for different DPRs.

Just by using the ngSrc attribute, the benefits of the NgOptimizedImage directive are immediately obvious. Let’s now proceed to make some tweaks in our app to address the following areas:

• Using images as backgrounds
• Lazy loading with placeholders
• Loading high-priority images (improving LCP)
• Resolution switching and viewport-based sizing

Using Images as Backgrounds

Update the local.component.ts file with the following:

@Component({
  selector: 'local-use',
  imports: [NgOptimizedImage],
  template: `
  <div
  style="
    width: 300px;
    height: 700px;
    overflow: hidden;
    position: relative;
    margin-inline: auto;
    margin-top:700px;
    padding:30px;
  "
>
  <img
    fill
    [ngSrc]="localImages[3]"
    style="object-fit: cover; z-index: -1"
  />
  <H1>Hello</H1>
  <p>testing Backgrounds</p>
</div>

By using the fill attribute, we can use images as backgrounds. This property overlays the image in its parent container using CSS. The fill attribute does not require us to specify a width or height property.

Here is a sample output:

Lazy Loading with Placeholders

Local Image

<h3>Local image</h3>
    <img
    width="800"
    height="600"
    [ngSrc]="localImages[3]"
    placeholder="data:image/webp;base64,UklGRtAAAABXRUJQVlA4IMQAAABwBQCdASoeABYAPn04lEeko6IhN/qoAJAPiWUAtOmMvNuEG3k3qonsrAxlVBwKRSuctL6AAP5RW9WtEC0SDum4fF68ZQfeqBp3ieyso2Hc2ynsYXNcHAVa/DMTVvEUDdP0bRJtvmL3wvsyJ806MJRwREZAAVSaRrRK08CE6p8y76jW+EO/e7rKmFK5yUhVi3z7XYbOSbwkJ+X7ferG15xGCnyYvNIHoozVzX9IOCk0RxXcw5ZqEee3QgU+m05NtntkAAAA"
  />

For local images, the image placeholder property must be manually set to a data URL as shown above. It is recommended that data URLs should be kept within 4KB in size. You can use tools like FFmpeg or visit websites like blurred.dev to generate placeholders. Failure to use a data URL will generate an error.

Remote Image

@for (img of remoteImages; track $index) {
  <div class="">
    <img
      width="800"
      height="590"
      [ngSrc]="img"
      placeholder
    />
  </div>
}

For remote images, just by setting the placeholder property, the loader generates a placeholder URL for all our images.

By default, placeholders have a width of 30 px in the generated URL as shown in the image below:

Customizing Placeholders

Width

We can customize the width of placeholders by using the IMAGE_CONFIG injection token. This is only applicable when using remote images.

import { IMAGE_CONFIG, NgOptimizedImage, provideCloudinaryLoader } from '@angular/common';
import { Component } from '@angular/core';
@Component({
  selector: 'remote-image-use',
  imports: [NgOptimizedImage],
  providers: [provideCloudinaryLoader('https://res.cloudinary.com/dqydioa17'),
    {
      provide: IMAGE_CONFIG,
      useValue: {
        placeholderResolution: 40,
      }
    },
  ],

If you set the placeholderResolution to 40, you’ll notice that the request URL is updated as shown below:

Appearance

By default, placeholder images are blurred out. As we saw earlier, the placeholderConfig property is an object that allows us to enable or disable the blur effect. It accepts an object with only one property called blur and can be used for both remote and local images.

@for (img of remoteImages; track $index) {
  <div style="padding-bottom: 900px">
    <img
      width="800"
      height="590"
      [ngSrc]="img"
      placeholder
      [placeholderConfig]="{blur:false}"
    />
  </div>
}

Loading High-Priority Images (Improving LCP)

Websites may use one or more images, depending on the use case. Some images may need to be loaded earlier than others because an image could be the LCP element on the page. Hence, the need to give certain images a higher loading priority over others.

@for (img of remoteImages; track $index) {
  <div style="padding-bottom: 900px">
    <img
      width="800"
      height="590"
      [ngSrc]="img"
      placeholder
      [placeholderConfig]="{blur:false}"
      [priority]="$index ===2"
    />
  </div>
}

For demonstration purposes, we set the priority property for the third image to true, simply assuming it is our LCP image.

As seen above, this sets the loading and fetchPriority to eager and high respectively.

As seen above, the image with higher priority is loaded before other resources. For the img element, it sets the loading and fetchPriority attributes on the image to eager and high respectively, so that the browser downloads the image as soon as possible and prioritizes it over any other resources being loaded.

Since we also enabled server-side rendering in our project, a link element is injected in the head section of the page. The rel="preload" instructs the browser to load the given asset (the image) as soon as possible.

Optimizing Quality and Resolution

Remote Images

As stated earlier, optimizing images for quality and resolution involves two steps:

• Define one or more candidate images based on some criteria (e.g., width descriptors or DPR) using the srcset attribute
• If our candidate images are width descriptors, we may optionally specify the criteria to help the browser select an image using the sizes prop

We already established earlier that simply setting the ngSrc prop, the srcset attribute is populated. Different candidates are generated for device pixel ratios/densities in the srcset field, as shown below:

Another way to look at it is that by default, ngSrcset="1x, 2x". The ngSrcset attribute allows us to define candidate images for the browser to choose from. It takes a comma-separated list of DPRs or width descriptors.

Density descriptors or DPR can only be one of 1x, 2x, or 3x; anything outside these will result in an error. Width descriptors are a comma-separated list of numbers with a w suffix (e.g., 200w, 700w, 900w), which can be thought of as 200 px, 700 px and 900 px. However, px is not used.

Define Different Resolutions of the Image Based on Screen Widths

The ngSrcset attribute allows us to customize the candidate image URLs to be populated in the img element’s srcset attribute using a shorter syntax. Let’s update the local.component.ts file to see it in action:

@for (img of remoteImages; track $index) {
  <div style="padding-bottom: 900px">
    <img
      width="800"
      height="590"
      [ngSrc]="img"
      placeholder
      [placeholderConfig]="{blur:false}"
      [priority]="$index ===0"
      ngSrcset="200w, 700w, 900w"
    />
  </div>
}

This tells the browser to generate three URLs at 200 px, 700 px and 900 px. When we look at the DOM, we see that the srcset attribute now defines three images based on the specified sizes, as shown below:

When we define selection rules using the sizes prop, we instruct the browser how to select the candidate image in the srcset attribute based on available space.

@for (img of remoteImages; track $index) {
  <div style="padding-bottom: 900px">
    <img
      width="800"
      height="590"
      [ngSrc]="img"
      placeholder
      [placeholderConfig]="{blur:false}"
      [priority]="$index ===0"
      sizes="(max-width: 30em) 100vw"
    />
  </div>
}

In the code above, we stated that if the viewport size is less than 30em, the browser should display the image that is 100vw.

To put it into context, assuming 30em maps to 480 px, if the width of the device is less than or equal to 480 px, then the image to be displayed is the one at 100vw.

If 100vw for the target device maps to, say, 300 px, the browser looks at the list of images specified in the srcset and renders the one equal to or greater than, but closest to, 300 px. So if there were images of 900w, 650w and 1200w, the one at 650w is selected.

Specifying sizes informs the NgOptimizedImage directive that we want width descriptors. Since we didn’t specify any above, like we did with ngSrcset previously, it automatically populates the srcset attribute with the default set of width descriptors it maintains, as shown below:

To customize the generated widths, we can either define an ngSrcset per image, as we did, or define them globally using the IMAGE_CONFIG injection token.

providers: [
    {
      provide: IMAGE_CONFIG,
      useValue: {
      placeholderResolution: 30,
      breakpoints: [500, 600, 1000]
    }
    },

When we refresh the application and inspect the DOM now, we notice that the srcset fields have been updated.

Introducing Custom Loaders

We already established that loaders are functions that receive some parameters and resolve a URL based on some predefined rules. So far, we have been using one of the default loaders (provideCloudinaryLoader), and this works well. However, there are situations when we have more complex requirements in our app that would require us to create a custom loader to achieve our goals.

Here is a list of things we want to support in our app and why we will be needing one:

• We want to use both local and remote images together in a single component
• For our remote images, on our Cloudinary account, we want to be able to apply cool effects to image assets
• We also want to be able to fetch a random image on the internet, store it in our Cloudinary account and apply effects to the image before rendering it in the browser

Some other reasons why you might need to define an image loader include:

• Using multiple remote media provider solutions at once (e.g., Cloudinary, S3 and Imgix)

All the code we will write here will be in the local-and-remote-image.component.ts file. Update the file to look like so:

import {
  IMAGE_LOADER,
  ImageLoaderConfig,
  NgOptimizedImage,
} from "@angular/common";
import { Component } from "@angular/core";
@Component({
  selector: "local-and-remote-image",
  imports: [NgOptimizedImage],
  providers: [
    {
      provide: IMAGE_LOADER,
      useValue: (config: ImageLoaderConfig) => {
        if (config && config.loaderParams && config.loaderParams["local"]) {
          return "/" + config.src;
        }
        const deliveryType =
          (config.loaderParams && config.loaderParams["delivery_type"]) ||
          "upload";
        let url = `https://res.cloudinary.com/dqydioa17/image/${deliveryType}`;
        if (config.loaderParams && config.loaderParams["tf"]) {
          url += config.loaderParams["tf"];
        }
        if (config.width) {
          url += `/w_${config.width}`;
        }
        url += `/${config.src}`;
        return url;
      },
    },
  ],
  template: `
    <div style="padding-top: 50px">
      <h2>local image</h2>
      <img
        width="800"
        height="600"
        [ngSrc]="'8.jpg'"
        [loaderParams]="{ local: true }"
      />
    </div>
    <div style="padding-top: 50px">
      <h2>remote image with effects</h2>
      <img
        width="800"
        height="600"
        [ngSrc]="'jcuh90sdncxwugdsqh40'"
        placeholder
        [loaderParams]="{ tf: '/e_enhance' }"
      />
    </div>
    <div style="padding-top: 50px">
      <h2>remote image with effects</h2>
      <img
        width="600"
        height="700"
        [ngSrc]="
          'https://upload.wikimedia.org/wikipedia/commons/1/13/Benedict_Cumberbatch_2011.png'
        "
        [loaderParams]="{ delivery_type: 'fetch', tf: '/e_vignette' }"
      />
    </div>
  `,
  styles: ``,
})
export class LocalAndRemoteImageComponent {}

Our new component shows how we can use a custom loader to do amazing things. This component displays three images: a local one and two remote images with some effects applied. It starts by defining a custom loader, which is just a function bound to the IMAGE_LOADER injection token, which accepts an object that looks like so:

interface ImageLoaderConfig {
  src: string;
  width?: number;
  isPlaceholder?: boolean;
  loaderParams?: {
    [key: string]: any;
  };
}

Of all these properties, the one we tinkered with most is the one called loaderParams, which allows us to define arbitrary key-value pairs to enable our loader to effectively decide how to resolve the URL. For the local image, we defined a local property.

For the remote images, we defined two:

• tf: This holds image effects as defined in the Cloudinary docs
• delivery_type: Setting this to fetch means that the image is first fetched remotely, then added to our remote assets

Conclusion

Images are an integral part of the web. This guide shows how to use images effectively. Even though our focus was on the Angular framework, there are still a lot of takeaways to apply when using images in future projects.

You may not know it, but Vercel released a package for Next.js called @vercel/og. It is unfortunately not open-source, but almost every framework has implemented their own version using Satori under the hood.

TL;DR

Analog now has the ability to generate OG Images in Angular on the server for SEO purposes. You can customize them and generate them on the spot. While they only work in Node environments and have limited CSS capabilities, they are extremely useful and great for dynamic image sharing.

What Is an OG Image?

The Open Graph Protocol is an HTML pattern that allows you to describe your webpage in the meta tags for better search engine optimization.

<meta property="og:image" content="https://ia.media-imdb.com/images/rock.jpg" />

When you create an image for each webpage, you allow preview images to be displayed. You can test a website with tools like Open Graph Preview.

You can also add data with Twitter Cards and Schema.org images.

Twitter Card

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Learn Latin with Interactive Flashcards">
<meta name="twitter:description" content="Build your Latin vocabulary through smart, progressive flashcards.">
<meta name="twitter:image" content="https://example.com/images/latin-flashcards.jpg">
<meta name="twitter:image:alt" content="Latin flashcards with English translations">

Schema.org

Or JSON-LD for schemas:

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "How to Make French Toast",
  "url": "https://example.com/french-toast",
  "image": "https://example.com/images/french-toast.jpg",
  "description": "A simple guide to making delicious French toast.",
  "author": {
    "@type": "Person",
    "name": "Jane Doe"
  }
}

Angular Image Directive

If you have an image on the site that can be created with CSS or Tailwind, you may also want to use it to generate dynamic images using the Angular Image Directive.

Satori

Vercel created a library called Satori, which converts HTML, CSS and Tailwind to an SVG image. It is a beautiful module, and it can run anywhere. However, it does not do every CSS function, nor does it convert the SVG to a PNG file, which requires rasterization. You must build a mini-canvas to convert the raw pixel data to PNG or JPG buffer. OG image parsers prefer PNG or SVG images.

Vercel OG

Vercel created a wrapper for this project. Unfortunately, it is not open-source and it only works on Next.js. It also uses JSX instead of pure HTML. However, there have been several implementations for it, including this one for AnalogJS.

Installation

First, install AnalogJS. Then install the packages.

npm install satori satori-html sharp --save

Og Image Route

Create the file og-image.ts in /server/routes/api.

import { defineEventHandler, getQuery } from 'h3';
import { ImageResponse } from '@analogjs/content/og';

export default defineEventHandler(async (event) => {
    const fontFile = await fetch(
        'https://cdn.jsdelivr.net/npm/@fontsource/geist-sans/files/geist-sans-latin-700-normal.woff',
    );
    const fontData: ArrayBuffer = await fontFile.arrayBuffer();
    const query = getQuery(event);

const template = `
    <div tw="flex flex-col w-full h-full p-12 items-center text-center justify-center text-white bg-[${query['bgColor'] ?? '#5ce500'}]">
      <h1 tw="flex font-bold text-8xl mb-4 text-black">${query['title'] ?? 'Progress <span class="text-gray-400">Telerik</span>'}</h1>
      <p tw="flex text-5xl mb-12 text-white">${query['description'] ?? 'Kendo UI'}</p>
    </div>
`;

    return new ImageResponse(template, {
        debug: true,
        fonts: [
            {
                name: 'Geist Sans',
                data: fontData,
                weight: 700,
                style: 'normal',
            },
        ],
    });
});

We can pass data from the URL parameters through getQuery. Her we are using three variables:

• title
• description
• bgColor

You can use whatever variables you want. The ImageResponse returns a png image. satori creates an svg and sharp is used to convert the image to a png.

Dynamic Images

Because you can pass parameters, you can create on-the-fly images through the parameters.

<html>
  <head>
    <meta
      property="og:image"
      content="https://your-url.com/api/v1/og-images?title=Developer"
    />
    <meta
      name="twitter:image"
      content="https://your-url.com/api/v1/og-images?title=Developer"
      key="twitter:image"
    />
    ...
  </head>
</html>

Demo

For this example, I am generating several images from the same route. The default route has no parameters.

• /api/og-image
• /api/og-image?title=…
• /api/og-image?title=…&description=

You can also pass extra fields in the title or description fields like a span.

title=<span%20class='text-red-300'>Kendo+UI</span>

Notice it is HTML encoded.

Request

Since we are generating the image URL first on the server, we need to get the correct URL from the request event. This is important so it can work on any server without changing the URL manually, including on the local machine.

Edit the main.server.ts file to get the request event through provideServerContext.

import 'zone.js/node';
import '@angular/platform-server/init';
import { provideServerContext } from '@analogjs/router/server';

import { AppComponent } from './app/app';
import { config } from './app/app.config.server';
import { renderApplication } from '@angular/platform-server';
import { bootstrapApplication, BootstrapContext } from '@angular/platform-browser';
import { ServerContext } from '@analogjs/router/tokens';

export function bootstrap(context: BootstrapContext) {
  return bootstrapApplication(AppComponent, config, context);
}

export default async function render(
  url: string,
  document: string,
  serverContext: ServerContext,
) {
  const html = await renderApplication(bootstrap, {
    document,
    url,
    platformProviders: [provideServerContext(serverContext)],
  });

  return html;
}

Config

Make sure to turn on ssr and turn off static in the vite.config.ts file.

/// <reference types="vitest" />

import { defineConfig } from 'vite';
import analog from '@analogjs/platform';
import tailwindcss from '@tailwindcss/vite';

// https://vitejs.dev/config/
export default defineConfig(() => ({
  build: {
    target: ['es2020'],
  },
  resolve: {
    mainFields: ['module'],
  },
  plugins: [
    analog({
      ssr: true,
      static: false,
      prerender: {
        routes: [],
      },
      nitro: {
        preset: 'vercel'
      }
    }),
    tailwindcss()
  ],
}));

⚠️ This will NOT work in Bun, Deno, Vercel Edge Functions, nor Cloudflare. Standard Node environments and serverless functions only! Only the Next.js version will correctly compile the large WASM file necessary to convert the SVG to a PNG. Hopefully, the framework developers will get this working for those environments as well. There may be some hacks, but I have never personally succeeded to get it working.

Origin

Next, we need to create a token to get the correct origin URL on the server and browser. I put this in app/lib/utils.ts.

import { injectRequest } from "@analogjs/router/tokens";
import { isPlatformBrowser } from "@angular/common";
import { DOCUMENT, inject, InjectionToken, PLATFORM_ID } from "@angular/core";

export const ORIGIN = new InjectionToken<string>(
  'origin',
  {
    providedIn: 'root',
    factory() {
      // You could hardcode this, or just hydrate the server value
      // This shows you how to derive it dynamically
      const doc = inject(DOCUMENT);
      const platformId = inject(PLATFORM_ID);
      const isBrowser = isPlatformBrowser(platformId);
      const request = injectRequest();
      const host = request?.headers.host;
      const protocol = host?.includes('localhost') ? 'http' : 'https';
      const origin = `${protocol}://${host}`;
      return isBrowser ? doc.location.origin : origin;
    }
  }
);

referer will get the origin from the request event on the server, but we must get rid of the extra / at the end with slice. The can inject a safely usable DOCUMENT token that will not error out on the server. Now we can get the correct base URL in any environment.

Creating the Images

We inject the ORIGIN token to get the correct URL.

import { Component, inject } from '@angular/core';
import { ORIGIN } from '../lib/utils';
import { Meta } from '@angular/platform-browser';

@Component({
  selector: 'app-home',
  standalone: true,
  template: `
  <main class="flex flex-col gap-5 items-center justify-center py-10">
    <h2 class="text-6xl font-semibold">AnalogJS</h2>
    <h3 class="text-4xl font-medium">OG Image Generator</h3>

    <img [src]="img1" alt="Default OG Image" />
    <div class="text-6xl font-semibold">or</div>

    <img [src]="img2" alt="Custom Title & Description" />
    <div class="text-6xl font-semibold">or</div>

    <img [src]="img3" alt="Styled Title, Custom BG" />
  </main>
  `,
})
export default class HomeComponent {

  readonly origin = inject(ORIGIN);
  readonly meta = inject(Meta);

  constructor() {
    this.meta.updateTag({
      name: 'og:image',
      content: this.origin + '/api/og-image'
    });
  }

  img1 = this.origin + '/api/og-image';

  img2 = this.origin + '/api/og-image?title=My%20Custom%20Title&description=My%20Custom%20Description';

  img3 = this.origin + "/api/og-image?title=<span%20class='text-red-300'>Kendo+UI</span>&description=For%20Angular&bgColor=%23eb0249";
}

You can see our images are created dynamically from our server route /api/og-image.

We could have hard-coded the image URLs, but then they would not work automatically if we change servers or if we test on localhost.

Meta

We use the Meta injection to update the meta tag dynamically.

this.meta.updateTag({
  name: 'og:image',
  content: this.origin + '/api/og-image'
});