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

The 2025 Stack Overflow Developer Survey confirmed what most of us already know from experience: 84% of developers are now using or planning to use AI tools in their development process. What’s more revealing is how developers are still being cautious in their use of these tools. Only about one-third say they trust AI outputs completely, while nearly half question their accuracy.

This cautious adoption tells us something important. We’re not blindly handing our work over to AI. We’re learning to use these tools strategically, treating them as assistants rather than replacements. For React developers specifically, this means adapting how we approach building interfaces, managing component libraries and iterating on features.

If you’ve been building React applications for a while, you’ve probably experienced this shift firsthand. Maybe you’re using GitHub Copilot to autocomplete component logic, or Cursor to refactor entire feature branches. Perhaps you’re generating design themes with Progress ThemeBuilder, or using Claude to debug complex state management issues. These aren’t experimental workflows anymore; they’re part of how we work.

In this article, we’ll explore what this actually looks like in practice for React developers in 2026.

Coding Itself Has Changed

There’s a shift in how we write code, and it’s not what most people expected (don’t worry, we’re not being replaced by AI). We’re spending less time on the mechanical act of typing and more time on the creative work of guiding and refining.

Ryan Dahl, the creator of Node.js and Deno, aptly put it in a recent social media post: “This has been said a thousand times before, but allow me to add my own voice: the era of humans writing code is over. Disturbing for those of us who identify as SWEs, but no less true. That’s not to say SWEs don’t have work to do, but writing syntax directly is not it.”

For React developers, this means our day-to-day work looks different. Instead of spending an hour carefully typing out a form component with all its validation logic, we might spend 10 minutes describing what we need and then another 20 minutes reviewing and adjusting the generated code. The result? The same quality component in a fraction of the time.

The iteration cycles have also become faster. When we can generate and refine code quickly, we’re more willing to try multiple approaches. Need to see how our data grid looks with server-side pagination versus client-side? Generate both implementations and compare them. Want to experiment with different state management patterns? We can prototype each one in minutes rather than hours.

We still need to understand React’s rendering model, still need to know when to use useCallback versus useMemo, still need to architect our component hierarchy thoughtfully. However, we don’t need to manually type out every property definition or write boilerplate code repeatedly.

Continuous Context and AI-Native Editors

One of the significant improvements in AI-assisted development is persistent context. Modern AI coding assistants understand our entire codebase, not just the file we’re currently editing.

Traditional autocomplete tools could only see a few lines around our cursor. They might suggest completing a function name, but they had no idea what that function should actually do or how it fit into our broader application architecture. AI-native editors and tools like Cursor, Claude Code and others have changed this completely.

These tools help maintain an understanding of our project structure, our component patterns, our naming conventions and even our coding style. When we ask them to create a new feature, they don’t just generate generic React code; they generate code that looks like it belongs in our codebase because they’ve learned from the rest of our application.

Let’s say we’re building a React dashboard UI that needs to fetch user data and display it in a table. With traditional tools, we’d manually wire up the API call, handle loading states, manage errors and set up the table structure.

With an AI assistant that understands our codebase, we can describe what we need, and it’ll generate code that uses our existing API client, follows our established error handling patterns and implements the table using whatever libraries we’re already using in our app.

Working with these AI assistants feels less like using a tool and more like pair programming with someone who already knows our codebase inside and out.

Planning and Agentic Workflows

Writing individual functions or components is one thing, but modern AI tools are increasingly capable of handling multi-step workflows that require planning and coordination. This is where agentic AI comes in: systems that can break down complex tasks into smaller steps and execute them sequentially or in parallel.

For React developers, this means we can hand off entire features to an AI agent rather than just asking for help with specific files. Want to migrate from Redux to Zustand? An AI agent can analyze our current state management setup, create a migration plan, and then systematically work through each component to update the implementation.

For example, we might tell an agent: “Build a column chart that shows quarterly sales by region, with drill-down functionality to reveal monthly data when a quarter is clicked.”

The agent can generate the chart component, configure the data bindings, create any necessary helper functions for aggregation and even add default styling or tooltips.

What’s powerful is that these agents can handle refactors and migrations that would be tedious to do manually. Need to rename a prop across 50 components? Want to update all your class components to functional components with hooks? Planning to migrate from JavaScript to TypeScript? These are exactly the kinds of repetitive-but-important tasks that agents excel at.

UI Generation, Design and Theming with AI

Building user interfaces has always involved a fair amount of repetitive work. Creating layouts, styling components and maintaining design consistency across an application. These are all necessary tasks, but they’re not where some developers want to spend their creative energy.

With AI, layout generation has become surprisingly sophisticated. Tools like v0 can take a description or even a screenshot of a design and generate React components that implement that layout. The code they produce isn’t just a rough approximation either, it’s good-quality JSX with proper semantic HTML, accessibility attributes and responsive styling.

For React developers working with component libraries like Progress KendoReact, this gets even more powerful as long as the agent has the appropriate context about the library and components. Instead of generating generic HTML and CSS, these tools can generate code using the actual components from our library. Need a data grid with sorting, filtering and pagination? Describe it, and the AI will scaffold it using the React Grid component we’re already using elsewhere in our app: with all the right props, event handlers and styling.

Progress ThemeBuilder has taken this a step further with AI-powered theme generation. Instead of manually configuring dozens of color variables and spacing values, we can describe the aesthetic we’re going for in plain English: “Create a clean, modern analytics theme with a cool blue-gray palette that feels data-driven and professional, suitable for a B2B software dashboard.” The AI generates a complete design system that applies consistently across all our components.

What makes this valuable is that the generated themes aren’t just random color combinations. The AI understands design principles like color theory, contrast ratios for accessibility and how different UI states should relate visually. When it generates a theme, it’s creating a system where primary buttons, hover states, focus indicators and disabled states all work together. ThemeBuilder also provides component-level AI theming, which means we can refine specific components without having to regenerate our entire theme.

For developers who aren’t designers (which is most of us), this removes a huge source of friction. We can focus on building functionality while still delivering applications that look professional and cohesive.

Model Context Protocol and Integration

The tools we’ve talked about so far are impressive, but they have a limitation: they only know what’s in our codebase and what they learned during training. They don’t know about our specific component library’s latest features, our company’s internal design system, or the proprietary APIs we’re building against.

This is where Model Context Protocol (MCP) becomes important. Think of MCP as a standardized way for AI models to connect to external knowledge sources and tools. Instead of the AI being limited to its training data, it can reach out to documentation, component libraries, databases and other resources to get current, specific information about the tools we’re using.

For React developers, this means our AI assistant can understand the actual API of the components we’re working with, not just generic React patterns. When we’re using the KendoReact Grid component, an MCP-enabled assistant can query the real documentation to understand what props are available, what patterns are recommended and what changed in the latest version.

The @progress/kendo-react-mcp server implements this for KendoReact. When we install it and configure it with our editor, the AI assistant gains access to comprehensive knowledge about KendoReact components. It’s not guessing at how to use the Grid, or the Scheduler, or the DatePicker. It’s referencing the actual documentation and best practices.

Here’s an example of generating a KendoReact Grid from scratch with the help of the @progress/kendo-react-mcp tool.

This can make a large difference in practice. Without MCP, we might ask an AI to create a KendoReact Grid component and get something that looks right but uses outdated props or misses important configuration options. With MCP, the AI generates code that follows current best practices and uses the component exactly as it was designed to be used.

Quality, Review and Governance

As AI-generated code becomes more prevalent in React applications, questions about quality and review processes naturally arise. The good news is that AI isn’t just generating code; it’s starting to get better at reviewing and improving it.

Modern AI tools can perform code reviews that go beyond syntax checking. They understand architectural patterns, can spot potential performance issues and flag accessibility concerns. When we commit changes, these tools can analyze the diff and provide feedback similar to what a developer might offer in a pull request review.

For React applications specifically, this means AI can catch issues like unnecessary re-renders, missing dependency arrays in hooks, improper state management patterns or components that should be memoized but aren’t. It can also verify that our components follow established patterns in our codebase and flag when new code deviates from those conventions.

AI-generated code can greatly accelerate development and improve consistency, but it’s not a replacement for human judgment. Even the more sophisticated tools benefit from a steward: a developer who reviews, guides and validates the AI’s output. Humans remain essential for making nuanced decisions, verifying alignment with project goals and upholding quality standards that AI alone can’t fully guarantee. In other words, AI can handle the heavy (repetitive) lifting, but the final responsibility still rests with us.

What This Means for Day-to-Day React Work

What does all of this actually look like in practice? How has the daily experience of building React applications changed? Here are some takeaways:

• Faster iteration: Features that used to take days can now be scaffolded in hours. AI handles repetitive boilerplate, letting us focus on logic, architecture and user experience.
• Less boilerplate, more creativity: Forms, API integrations, responsive layouts and other common patterns can be generated automatically, freeing us to solve higher-level problems.
• Higher-level decisions matter more: Understanding React fundamentals like component composition, state management, performance optimization and accessibility is more important than ever because we’re guiding and reviewing AI outputs rather than typing everything ourselves.

In short, React development in 2026 is faster, more iterative and more creative. The mechanical work of writing boilerplate and translating designs into components is largely automated, but the critical thinking and stewardship still require skilled developers.

Ready to Explore How AI Can Enhance Your React Development?

• Give the KendoReact AI Components and Features a try.
• Watch demos of AI-powered theme generation in ThemeBuilder to see how design ideation can be automated.
• Try the KendoReact MCP Server to give your AI assistant deep knowledge of KendoReact components.
• Check out the KendoReact Prompt Library for ready-made prompts that target common development scenarios.

Authentication should be straightforward, but in practice, it takes time. You’re dealing with sessions, cookies, password hashing, OAuth redirects and email verification, and each piece has its own quirks and scattered documentation. The whole time, you may also be asking yourself if you’re doing this securely. One mistake exposes your users.

Most existing tools don’t help much. NextAuth is solid if you’re using Next.js, but switching frameworks means starting over. Building from scratch gives you control at the cost of maintaining every security detail yourself. Clerk and Auth0 work well until you reach their pricing tiers or require a feature they don’t support. Passport.js works, but it hasn’t aged well—there’s callback hell and endless boilerplate.

Better Auth takes a different approach. It’s lightweight, works with any framework (Next.js, Remix, Svelte, etc.), and comes with TypeScript baked in. You get OAuth, 2FA and password resets out of the box. You can also customize when you need to, or just use the defaults.

In this guide, we’ll build a complete email and password authentication system with session management to see how Better Auth works. Users will be able to sign up, log in and stay authenticated across page refreshes. We’ll use Next.js, Drizzle ORM and SQLite.

Prerequisites

To follow along with this guide, you’ll need:

• A decent understanding of JavaScript/TypeScript
• Basic familiarity with React and Next.js
• A database ready (PostgreSQL, MySQL or SQLite)

What Is Better Auth?

Better Auth is a TypeScript-first authentication library that avoids the usual trade-offs like vendor lock-in, expensive monthly fees or complex configurations. It is framework-agnostic, so you can use it with Next.js today and switch to Remix or SvelteKit tomorrow without rewriting your auth logic. It’s not a managed service, so there’s no per-user pricing or vendor lock-in.

What makes it different? It’s database-agnostic, meaning you can use PostgreSQL, MySQL, SQLite or MongoDB. Better Auth adapts through adapters like Prisma, Drizzle and Mongoose. It’s type-safe by default, built in TypeScript from the ground up, so your IDE knows what methods exist, what data comes back, and catches errors before you run your code. It also has security measures built in by default, with proper password hashing, HttpOnly cookies, CSRF protection and secure session management. The defaults follow best practices.

Better Auth supports OAuth providers (Google, GitHub, etc.), magic links, two-factor authentication, passkeys, even enterprise SSO, and more than what we’ll cover in this article. We’re focusing on the fundamentals so you understand how the system works. Once you grasp the basics, adding these features is straightforward through Better Auth’s plugin system.

Project Setup

Let’s start by creating a new Next.js project with TypeScript and Tailwind CSS. Run the following command in your terminal:

npx create-next-app@latest better-auth --ts --tailwind --eslint --app

This creates a Next.js project with TypeScript, Tailwind CSS, ESLint and App Router (the modern Next.js routing system) configured.

Run this command to navigate into the project:

cd better-auth

Run the following command to install Better Auth and its dependencies:

npm install better-auth drizzle-orm better-sqlite3 
npm install -D drizzle-kit @types/better-sqlite3

Database Setup

Before configuring Better Auth, we need to prepare our database. We’ll break this down into three distinct files to keep things organized:

• Define the tables: Create the tables Better Auth needs (users, sessions, accounts, verification)
• Database initialization: Set up the SQLite connection and wrap it with Drizzle for type-safe queries
• Configure auth: Finally, we connect our database to Better Auth using the Drizzle adapter

Define the Tables

We need to explicitly define the tables Better Auth expects. We will add all of these to a single file. Open your lib/auth-schema.ts file and add the following to it:

The User Table
This stores basic user information.

//lib/auth-schema.ts
import { sqliteTable, text, integer } from "drizzle-orm/sqlite-core";
export const user = sqliteTable("user", {
  id: text("id").primaryKey(),
  name: text("name").notNull(),
  email: text("email").notNull().unique(),
  emailVerified: integer("emailVerified", { mode: "boolean" }).notNull(),
  image: text("image"),
  createdAt: integer("createdAt", { mode: "timestamp" }).notNull(),
  updatedAt: integer("updatedAt", { mode: "timestamp" }).notNull(),
});

The email field is unique, meaning no two users can share the same email. Better Auth requires these specific fields for its internal functionality.

Notice we mark name and email as notNull() here. This is important because Better Auth infers its types from this schema. By making them required in the database, TypeScript will automatically force us to provide them in the sign-up form later.

The Session Table
This manages active login sessions.

//lib/auth-schema.ts
export const session = sqliteTable("session", {
  id: text("id").primaryKey(),
  expiresAt: integer("expiresAt", { mode: "timestamp" }).notNull(),
  token: text("token").notNull().unique(),
  createdAt: integer("createdAt", { mode: "timestamp" }).notNull(),
  updatedAt: integer("updatedAt", { mode: "timestamp" }).notNull(),
  ipAddress: text("ipAddress"),
  userAgent: text("userAgent"),
  userId: text("userId")
    .notNull()
    .references(() => user.id),
});

Each session has a unique token and links to a user via userId. The expiresAt timestamp determines when the session becomes invalid.

The Account Table
This handles OAuth providers and stores authentication credentials.

//lib/auth-schema.ts
export const account = sqliteTable("account", {
  id: text("id").primaryKey(),
  accountId: text("accountId").notNull(),
  providerId: text("providerId").notNull(),
  userId: text("userId")
    .notNull()
    .references(() => user.id),
  accessToken: text("accessToken"),
  refreshToken: text("refreshToken"),
  idToken: text("idToken"),
  accessTokenExpiresAt: integer("accessTokenExpiresAt", { mode: "timestamp" }),
  refreshTokenExpiresAt: integer("refreshTokenExpiresAt", {
    mode: "timestamp",
  }),
  scope: text("scope"),
  password: text("password"),
  createdAt: integer("createdAt", { mode: "timestamp" }).notNull(),
  updatedAt: integer("updatedAt", { mode: "timestamp" }).notNull(),
});

The account table stores the user’s credentials, including the password. This separation keeps the architecture flexible, allowing you to link other providers like GitHub or Google to the same user identity.

Verification Table
This stores temporary code for email verification and password resets.

export const verification = sqliteTable("verification", {
  id: text("id").primaryKey(),
  identifier: text("identifier").notNull(),
  value: text("value").notNull(),
  expiresAt: integer("expiresAt", { mode: "timestamp" }).notNull(),
  createdAt: integer("createdAt", { mode: "timestamp" }),
  updatedAt: integer("updatedAt", { mode: "timestamp" }),
});

This table acts as a temporary vault for security tokens. When the system sends an email to verify a user, the unique code is stored here to ensure the link is valid and hasn’t expired when clicked.

Database Initialization

We need a running database connection. Let’s create a file called lib/db.ts. This is where we initialize SQLite and wrap it in Drizzle so we can use it everywhere else. We wrap it because we want to write TypeScript, not SQL strings. By passing the connection to Drizzle, you get to query your database using typed methods.

// lib/db.ts 
import { drizzle } from "drizzle-orm/better-sqlite3";
import Database from "better-sqlite3";

// This creates a local 'sqlite.db' file if it doesn't exist
const sqlite = new Database("sqlite.db"); 

export const db = drizzle(sqlite);

We need to do this first so we can import db into our auth configuration without TypeScript yelling at us.

Configure Auth

Now we can write the auth config. This file is where we tell Better Auth about our database and configure how users will authenticate.

Create a lib/auth.ts file and add the following to it:

//lib/auth.ts
import { betterAuth } from "better-auth";
import { drizzleAdapter } from "better-auth/adapters/drizzle";
import { db } from "./db";
import * as schema from "./auth-schema";

export const auth = betterAuth({
  database: drizzleAdapter(db, {
    provider: "sqlite",
    schema: schema, // passing the schema here
  }),
  emailAndPassword: {
    enabled: true,
  },
  })

In the code above, we import the database connection db and schema we created, then pass them to Better Auth through the drizzleAdapter. This adapter translates Better Auth operations into Drizzle queries so it can read and write user data.

The provider: "sqlite" tells Better Auth we’re using SQLite. If we were using something else like PostgreSQL, we would change it to whatever we’re using.

It is important to note that the emailAndPassword: {enabled: true} option activates email and password authentication. Better Auth will generate the signup and signin endpoints we need.

Syncing Database

Now that we have three core files, we need to create the database file. Currently, sqlite.db doesn’t exist.

Drizzle Configuration

Create a file named drizzle.config.ts at the your root of your project and add the following to it:

//drizzle.config.ts
import { defineConfig } from "drizzle-kit";

export default defineConfig({
  schema: "./lib/auth-schema.ts", // where our tables will be defined
  dialect: "sqlite",
  dbCredentials: {
    url: "sqlite.db", // This is the name of the file it will create
  },
});

Here, we tell Drizzle where to find our schema and what database to use. The config points to our schema file ./lib/auth-schema.ts and specifies SQLite as the database type. The url is the filename Drizzle will create and in this case, it’s sqlite.db.

Now, run this command in your terminal to sync your code with the database:

npx drizzle-kit push

If everything is set up correctly, you should see a success message. Drizzle just created a local sqlite.db file in your project root with all your user, session and account tables.

API Route

Now we need to set up an API route so our frontend can communicate with Better Auth. Create a file named app/api/auth/[...all]/route.ts. This will be the API route that handles all auth requests:

// app/api/auth/[...all]/route.ts

import { auth } from "@/lib/auth";
import { toNextJsHandler } from "better-auth/next-js";

export const { GET, POST } = toNextJsHandler(auth);

If your project uses src/, this goes in src/api/auth/[...all]/route.ts.

Auth Client

Finally, for our setup, we need a way for our frontend to talk to the backend without writing messy fetch calls.

Create lib/auth-client.ts file and add the following to it:

import { createAuthClient } from "better-auth/react";

export const authClient = createAuthClient({
  baseURL: "http://localhost:3000",
});

This small utility will give us type-safe methods for signing in, signing up and checking sessions.

Email and Password Authentication

Now let’s build the authentication forms. We’ll create two components: one for sign-up and one for sign-in.

Sign-up Form

Create a file named components/sign-up.tsx and add the following to it:

// components/sign-up.tsx
"use client";

import { useState } from "react";
import { authClient } from "@/lib/auth-client";
import { useRouter } from "next/navigation";

export default function SignUp() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [name, setName] = useState("");
  const [isLoading, setIsLoading] = useState(false);
  const router = useRouter();

  const signUp = async () => {
    await authClient.signUp.email(
      {
        email,
        password,
        name,
      },
      {
        onRequest: () => {
          setIsLoading(true);
        },
        onSuccess: () => {
          router.push("/dashboard");
        },
        onError: (ctx) => {
          alert(ctx.error.message);
          setIsLoading(false);
        },
      }
    );
  };

return (
  <div className="flex flex-col gap-4 w-full max-w-md mx-auto mt-10 border border-gray-200 p-6 rounded-lg shadow-sm bg-white">
    <h1 className="text-xl font-bold text-gray-900">Create Account</h1>

    <div className="flex flex-col gap-2">
      <label className="text-sm font-medium text-gray-700">Name</label>
      <input
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
        placeholder="John Doe"
        className="border border-gray-300 p-2 rounded focus:outline-none focus:ring-2 focus:ring-black text-black bg-white"
      />
    </div>

    <div className="flex flex-col gap-2">
      <label className="text-sm font-medium text-gray-700">Email</label>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="user@example.com"
        className="border border-gray-300 p-2 rounded focus:outline-none focus:ring-2 focus:ring-black text-black bg-white"
      />
    </div>

    <div className="flex flex-col gap-2">
      <label className="text-sm font-medium text-gray-700">Password</label>
      <input
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
        placeholder="••••••••"
        className="border border-gray-300 p-2 rounded focus:outline-none focus:ring-2 focus:ring-black text-black bg-white"
      />
    </div>

    <button
      onClick={signUp}
      disabled={isLoading}
      className={`mt-2 p-2 rounded text-white font-medium transition-colors ${
        isLoading
          ? "bg-gray-400 cursor-not-allowed"
          : "bg-black hover:bg-gray-800"
      }`}
    >
      {isLoading ? "Creating an account..." : "Sign Up"}
    </button>
  </div>
); 

This component handles the entire sign-up flow in a single file. If you look closer, you’ll see that the heavy lifting is done by authClient.signUp.email(). This function is type-safe and accepts two distinct arguments (the payload and the event handlers):

• The payload: This is the actual data we’re sending. In this case, email, password and name. Since our database schema requires these fields, the client verifies we actually provide them. If we miss a required field, TypeScript will flag it instantly.
• Event handlers: The second argument is an object that controls the request lifecycle, from the moment we click Sign Up to when we get a result. This is one of the perks of Better Auth because it replaces try/catch blocks with clean event hooks. All we have to do is define what happens at each stage: onRequest, onSuccess and onError, which catches errors and alerts the user in this case.

Sign-in Form

With our current setup, users can only register. We need to log them in if they’re existing users.

Create a file named components/sign-in.tsx and add the following to it:

//components/sign-in.tsx
"use client";

import { useState } from "react";
import { authClient } from "@/lib/auth-client";
import { useRouter } from "next/navigation";

export default function SignIn() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [isLoading, setIsLoading] = useState(false);

  const router = useRouter();

  const signIn = async () => {
    await authClient.signIn.email(
      {
        email,
        password,
      },
      {
        onRequest: () => {
          setIsLoading(true);
        },
        onSuccess: () => {
          setIsLoading(false);
          router.push("/dashboard");
        },
        onError: (ctx) => {
          setIsLoading(false);
          alert(ctx.error.message);
        },
      }
    );
  };

  return (
    <div className="flex flex-col gap-4 w-full max-w-md mx-auto mt-10 border border-gray-200 p-6 rounded-lg shadow-sm bg-white">
      <h1 className="text-xl font-bold text-gray-900">Sign In</h1>

      <div className="flex flex-col gap-2">
        <label className="text-sm font-medium text-gray-700">Email</label>
        <input
          type="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
          placeholder="user@example.com"
          className="border border-gray-300 p-2 rounded focus:outline-none focus:ring-2 focus:ring-black text-black bg-white"
        />
      </div>

      <div className="flex flex-col gap-2">
        <label className="text-sm font-medium text-gray-700">Password</label>
        <input
          type="password"
          value={password}
          onChange={(e) => setPassword(e.target.value)}
          placeholder="••••••••"
          className="border border-gray-300 p-2 rounded focus:outline-none focus:ring-2 focus:ring-black text-black bg-white"
        />
      </div>

      <button
        onClick={signIn}
        disabled={isLoading}
        className={`mt-2 p-2 rounded text-white font-medium transition-colors ${
          isLoading
            ? "bg-gray-400 cursor-not-allowed"
            : "bg-black hover:bg-gray-800"
        }`}
      >
        {isLoading ? "Loading..." : "Sign In"}
      </button>
    </div>
  );
}

This component is nearly identical to the sign-up form with one key difference: we only need email and password since we’re verifying an existing user, not creating a new one.

When a user submits the form, Better Auth verifies the credentials against our database. If they match, it automatically creates a session and sets a secure HttpOnly cookie. This cookie persists the login state, so users stay logged in even after refreshing the page.

Remember when we enabled emailAndPassword: { enabled: true } in the lib/auth.ts file? Better Auth read that configuration and automatically generated this method for us.

Now let’s create dedicated pages for these forms.

Creating Authentication Pages

Instead of embedding forms on the homepage, we’ll create dedicated routes for sign-in, sign-up and a dashboard to verify successful login.

Sign-up Page

Create a component called app/signup/page.tsx and add the following to it:

//app/signup/page.tsx
import SignUp from "@/components/sign-up";
import Link from "next/link";

export default function SignUpPage() {
  return (
    <div className="flex flex-col items-center justify-center min-h-screen bg-gray-50">
      <SignUp />
      <div className="mt-6 text-center text-sm text-gray-600">
        Already have an account?{" "}
        <Link
          href="/signin"
          className="text-blue-600 font-medium hover:underline"
        >
          Sign In
        </Link>
      </div>
    </div>
  );
}

This page wraps the <SignUp /> component and adds a link to sign in.

Sign-in Page

Create a component called app/signin/page.tsx and add the following to it:

//app/signin/page.tsx
import SignIn from "@/components/sign-in";
import Link from "next/link";

export default function SignInPage() {
  return (
    <div className="flex flex-col items-center justify-center min-h-screen bg-gray-50">
      <SignIn />
      <div className="mt-6 text-center text-sm text-gray-600">
        New here?{" "}
        <Link
          href="/signup"
          className="text-blue-600 font-medium hover:underline"
        >
          Create an account
        </Link>
      </div>
    </div>
  );
}

This page wraps the <SignIn /> component and adds a link to Sign Up.

Dashboard Page

We need a destination for users after they log in. For now, let’s create a simple static page named app/dashboard/page.tsx and add the following to it:

//app/dashboard/page.tsx
export default function Dashboard() {
  return (
    <div className="flex flex-col items-center justify-center min-h-screen bg-white text-black">
      <h1 className="text-3xl font-bold">Dashboard</h1>
      <p className="mt-4 text-gray-600">You are successfully logged in!</p>
    </div>
  );
}

Now you can start your server by running npm run dev and then open http://localhost:3000.

You should see a landing page with options to Sign In or Create Account. Follow these steps to test the authentication:

• Click “Create Account” and create a new user. If it works, you should be redirected to the dashboard.
• To test the login form, you don’t need to open another window. Just hit the back button in your browser to return to the landing page. Click “Sign In” this time, enter the email and password you just used to sign up, and watch it redirect you back to the dashboard.

Accessing User Sessions

Right now, our dashboard just shows static text. We need to make it smart so it displays the actual user’s name and email.

To do this, we use the useSession hook from the auth-client. This hook gives us real-time access to the user’s data.

Update your app/dashboard/page.tsx file with the following:

//app/dashboard/page.tsx
"use client";

import { authClient } from "@/lib/auth-client";
import { useRouter } from "next/navigation";

export default function Dashboard() {
  const router = useRouter();
  const { data: session, isPending } = authClient.useSession();
  if (isPending) {
    return (
      <div className="flex min-h-screen items-center justify-center">
        <p className="text-gray-500">Loading...</p>
      </div>
    );
  }
  if (!session) {
    router.push("/signin");
    return null;
  }
  return (
    <div className="flex flex-col items-center justify-center min-h-screen gap-4 bg-white text-black">
      <h1 className="text-2xl font-bold">Welcome back, {session.user.name}!</h1>
      <p className="text-gray-600">
        You are logged in as{" "}
        <span className="font-semibold">{session.user.email}</span>
      </p>

      <button
        onClick={async () => {
          await authClient.signOut({
            fetchOptions: {
              onSuccess: () => {
                router.push("/signin");
              },
            },
          });
        }}
        className="px-4 py-2 bg-red-500 text-white rounded hover:bg-red-600 transition"
      >
        Sign Out
      </button>
    </div>
  );
}

We introduced the useSession() hook. This is the bridge between the frontend and the user’s session. It gives us access to the current session and keeps it in sync as authentication changes. It returns two key values:

• data: The session object containing user information (or null if not logged in).
• isPending: A boolean indicating whether the session is still loading. With this, we’re able to show a loading state so the user doesn’t see empty content.

Finally, the Sign Out button calls authClient.signOut(). This function invalidates the session cookie and uses the onSuccess callback to send the user straight back to the login screen.

Session Management and Protected Routes

Now that our app works, let’s look at what happens under the hood.

When a user signs in, Better Auth creates a session and stores it as an HttpOnly cookie. Unlike regular cookies that you can read with document.cookie, these are blocked from frontend JavaScript entirely. Only the browser can send them automatically with each request to the server.

There are two main ways of securing your pages, and they serve different purposes:

• Client-Side Protection: This is what we implemented in our app/dashboard/page.tsx earlier. We wait for the session to load in the browser, and, if it’s missing, we redirect the user to the “Sign In” page.
• Server-Side Protection (better for security): We check the session on the server before the page renders. If there’s no valid session, the request gets blocked immediately, and the sensitive page content is never sent to the browser.

To implement server-side protection, we use middleware. Middleware is code that runs before a page loads. It sits between the user’s request and your page, checking conditions and deciding whether to allow access or redirect elsewhere. In Next.js, it runs on the server, so unauthorized users never even download the page.

Protecting Routes with Middleware

Create a new file named middleware.ts at the same level as your app folder and add the following to it:

//middleware.ts
import { betterFetch } from "@better-fetch/fetch";
import type { Session } from "better-auth/types";
import { NextResponse, type NextRequest } from "next/server";

export default async function authMiddleware(request: NextRequest) {
  const { data: session } = await betterFetch<Session>(
    "/api/auth/get-session",
    {
      baseURL: request.nextUrl.origin,
      headers: {
        cookie: request.headers.get("cookie") || "",
      },
    }
  );

  if (!session) {
    return NextResponse.redirect(new URL("/signin", request.url));
  }
  return NextResponse.next();
}

export const config = {
  matcher: ["/dashboard"],
};

In a nutshell, the config object at the bottom defines the rules of engagement, telling Next.js to strictly apply this security check only to routes starting with /dashboard. When a user attempts to visit the page, the middleware steps in to verify their session first. If the session is missing, it instantly blocks the request and redirects them to the “Sign In” page, preventing the protected content from reaching the browser.

Refactor the Dashboard

Now that the server (middleware) is handling the security, we can simplify our dashboard page. We don’t need to redirect from inside the component anymore, but we’ll keep the data fetching to show the user’s name and email address.

//app/dashboard/page.tsx
"use client";

import { authClient } from "@/lib/auth-client";
import { useRouter } from "next/navigation";

export default function Dashboard() {
  const router = useRouter();
  const { data: session, isPending } = authClient.useSession();

  if (isPending) {
    return (
      <div className="flex min-h-screen items-center justify-center">
        <p className="text-gray-500">Loading...</p>
      </div>
    );
  }

  return (
    <div className="flex flex-col items-center justify-center min-h-screen gap-4">
      <h1 className="text-2xl font-bold">Dashboard</h1>
      <div className="p-4 border rounded shadow-sm bg-white min-w-[300px]">
        <p className="text-gray-600 mb-2">
          Signed in as:{" "}
          <span className="font-semibold text-black">
            {session?.user.email}
          </span>
        </p>
        <p className="text-xs text-gray-400">User ID: {session?.user.id}</p>
      </div>

      <button
        onClick={async () => {
          await authClient.signOut({
            fetchOptions: {
              onSuccess: () => {
                router.push("/signin");
              },
            },
          });
        }}
        className="px-4 py-2 bg-red-500 text-white rounded hover:bg-red-600 transition"
      >
        Sign Out
      </button>
    </div>
  );
}

Now when we sign out from the app and try to manually visit http://localhost:3000/dashboard, we should be instantly redirected back to the sign-in page. The dashboard will never attempt to render because there’s no valid session.

Conclusion

At the base level, Better Auth handles the heavy lifting for authentication. The good thing is you aren’t reinventing the wheel, and because it works with pretty much everything, you don’t even have to rewrite your whole auth setup if you switch frameworks down the line. It just works, so you can focus on your app.

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

Over the last year, AI coding agents have gone from glorified autocomplete to autonomous systems capable of scaffolding entire features.

As our VP of Product put it:

“The speed of software engineering is no longer the bottleneck.”
— Genady Sergeev, VP Product, Progress

If that’s true—and it increasingly feels like it is—then something fundamental has shifted.

The constraint isn’t typing. It’s judgment.

These lessons come directly from conversations with our engineering and product teams. Across many of interviews and internal reflections, four themes emerged.

Lesson #1: AI Is Best at Getting Us Started

One of our product leads described the shift this way:

“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.”
— Yoana Kalaydzhieva, Senior Manager, Software Engineering, Progress

AI lowers the cost of starting. It accelerates refactoring. It scaffolds tests. It makes proof-of-concepts nearly frictionless.

But our engineers were equally honest:

“AI is better at starting than finishing.”
— Stefan Mariyanov, Senior Product Manager, Progress

AI gives you momentum. It doesn’t give you judgment.

What we realized is that developers don’t actually want magic answers—they want orientation. They want something to react to, refine and push against.

That changed how we thought about AI in our tools. Instead of “generate and disappear,” we moved toward:

• Iterative workflows
• Clear stopping points
• Explicit human decision moments

AI made refactoring and technical debt much faster, allowing teams to focus on market features. Validating ideas, creating POCs and writing tests also saw huge impact.

And what that really opened up was exploration.

Lesson #2: Clever ≠ Correct

Then we ran into something humbling.

AI-generated code often looks clean, structured and convincing. The formatting is good. The structure feels familiar. The solution appears reasonable at first glance. But many times it’s simply wrong.

As one of our engineers put it:

“Code often looks right but breaks in subtle ways.”
— Stefan Mariyanov, Senior Product Manager, Progress

That’s the danger. It sounds right.

Kathryn Grayson Nanz framed this beautifully:

“I’d encourage teams to learn how AI actually works instead of treating it like a black box. Even a high-level understanding—how models predict the next word, how they gain context—demystifies the magic.”
— Kathryn Grayson Nanz, Senior Developer Advocate, Progress

The key thing to understand is that AI doesn’t understand truth. It predicts plausibility. It generates the next token based on patterns it has learned.

And when tools are confidently wrong, trust erodes fast.

For developer tools, that’s a serious problem. Developers rely on their tools to accelerate their work, not introduce hidden uncertainty. If AI suggestions consistently require double-checking or rewriting, the productivity gains disappear.

That realization forced us to rethink how AI should be integrated into the products we build.

Instead of asking AI to guess what developers might want, we started focusing on giving it better context. Rather than generating output in isolation, we began connecting AI directly to the frameworks, component libraries and development tools our users already rely on.

This is where things like our MCP server and product-aware AI tooling come in. By allowing assistants to access real project structure, real component APIs and real framework constraints, the output becomes grounded in the actual environment the developer is working in.

In other words, the goal isn’t to make AI more clever. The goal is to make it more reliable.

What This Changed for Us

For instance, in the Progress Kendo UI for Angular library AI tools, that meant building product-aware AI that understands the capabilities and APIs of the components in our libraries. It meant adding framework-aware constraints so generated code follows Angular patterns instead of generic JavaScript assumptions (or even outdate Angular patterns). And it meant leaning into opinionated scaffolding, where AI helps developers start with valid structures instead of forcing them to repair generated output afterward.

What we realized is that the gap wasn’t intelligence, it was context. AI could generate something that looked clever, but without grounding in real tools and constraints, it still left developers doing the hard part.

So we shifted the question. Instead of asking how to make AI more impressive, we started asking how to make it more trustworthy. And once we framed it that way, the answer showed up everywhere: context beats cleverness.

Lesson #3: Fast Isn’t Free

Speed came with a cost.

As we started integrating AI more deeply into developer workflows, we began to see both the upside and the tradeoffs more clearly. The productivity gains were real, but so were the risks.

One of our VPs of Product reflected on this directly:

“Using CLI agents successfully requires certain skills and practice. The improvement rate is so fast that observations from 3–4 months ago are already outdated.”
— Genady Sergeev, VP Product, Progress

That pace of change creates a new kind of pressure. Not just to adopt AI, but to continuously relearn how to use it well.

And we observed something else happening inside teams.

“AI helps experienced developers master their productivity—it’s impressive. But less experienced developers might over-trust AI-generated code, which leads to pull requests that require much deeper senior review.”
— Yoana Kalaydzhieva, Senior Manager, Software Engineering, Progress

In other words, AI doesn’t just accelerate output. It amplifies behavior.

For experienced developers, that can mean faster iteration and deeper focus. For less experienced developers, it can mean moving quickly in the wrong direction—and creating more work downstream.

That’s when the real cost of speed started to show up. AI makes output cheaper, but not ownership. It accelerates mistakes just as efficiently as it accelerates success. And when everything moves faster, the cost of catching issues later increases. So we changed how we approached tooling.

Instead of optimizing purely for generation speed, we started designing for accountability alongside acceleration. That meant introducing clear checkpoints where human review is expected, giving teams control over the models and endpoints they use, and enabling every AI-generated action to be traced, inspected and understood.

We also shifted our mindset around AI output itself. Instead of treating it as a near-final draft, we began treating it as untrusted input—something useful, but something that still requires validation.

Demo Highlight: Observability as Accountability

This is where our AI Observability Platform became part of the solution. Not to “watch code,” but to watch reasoning.

We wanted to make it possible to see what the model did, how it arrived at a result and why certain decisions were made along the way. Because if AI is going to operate inside real workflows, its behavior can’t be opaque. Visibility becomes a requirement, not a bonus.

If AI accelerates execution, then visibility has to scale with it. Because speed, on its own, isn’t the goal. Speed is only valuable when accountability scales alongside it.

Lesson #4: AI Belongs in the Product—Thoughtfully

This one surprised us most.

One internal reflection stood out:

“What surprised me most is how quickly the attention span of our customers dropped, and how much the evaluation process changed.”
— Yoana Kalaydzhieva, Senior Manager, Software Engineering, Progress

Evaluation cycles compressed, tolerance for friction disappeared, and that shift affects end users too. Users struggle with:

• Complex data
• Dense interfaces
• Discoverability

AI isn’t a replacement UI. It’s an augmentation layer.

Demo Highlight: AI Inside the Interface

Lesson #4 shows up very clearly in how we’ve approached AI within the Kendo UI Grid—not as a replacement for the interface, but as a layer that makes it easier to use.

Instead of hiding the system behind a prompt box, we’ve focused on keeping the structure intact: columns, grouping, filtering and data visibility all remain explicit and inspectable. AI becomes a way to express intent faster—“group by this,” “filter that”—while still grounding every action in the underlying UI. You can explore the full capabilities here: Angular Smart Grid.

What this means in practice is that the grid doesn’t disappear when AI is introduced—it becomes more approachable. Users can move faster without losing their bearings, because every change is visible, reversible and tied to real UI controls.

That balance is the point: reducing cognitive load without sacrificing control. Rather than asking users to trust a black box, the grid invites them to collaborate with it—AI helps initiate actions, but the interface remains the source of truth.

What We’re Really Learning

Over time, these lessons started to feel less like separate observations and more like different edges of the same shape. AI is incredibly effective at helping us begin, but it doesn’t carry the responsibility of finishing. It can produce outputs that look convincing, but without context, that confidence can be misplaced. And while it dramatically increases speed, it also raises the cost of mistakes when that speed isn’t paired with visibility and accountability.

Even when we bring AI into the product itself, the goal isn’t to replace the interface—it’s to make it easier to use without taking control away from the user.

What this ultimately points to is a deeper shift in how we think about building tools. AI changes how quickly we can move, but it doesn’t change who owns the outcome. Developers still make the decisions. Teams still carry the consequences. So the goal can’t just be faster output—it has to be confidence in what we’re building, even as everything around us accelerates.

Let’s Talk About It

We’re hosting a live Developer Roundtable on April 15 at 9 a.m. PT, where we’re unpacking all of this in real time—no slides, no polished answers, just honest conversation with developers in the trenches.

We’ll be digging into questions like:

• Where has AI actually helped you move faster—and where has it created more work?
• How are you validating AI-generated code today?
• What guardrails feel necessary right now?
• Where has AI in tools felt genuinely helpful … and where has it felt forced?

Join us on the Progress Labs Discord:

Come share what’s working, what’s breaking and what still feels unresolved.

Because the truth is—we’re all still figuring this out. And the best insights aren’t coming from headlines. They’re coming from conversations like this.

AI may be a normal part of daily life now, but the reality of implementing AI-powered tooling in the workplace is not so simple. Teams are moving faster, but workflows are becoming messier, more complex and more challenging to scale. AI is improving productivity at the individual and small-team level—but those gains aren't necessarily translating into consistent, scalable workflows across teams.

How do we know? In our 2025 Designer-Developer Collaboration survey, we asked 200+ respondents across design and development (including hybrid and leadership roles, as well) about the ways they’re leveraging new AI capabilities in their work. You can download the full report to see everything, but these were our top takeaways:

1. AI Is the Default—Maturity Is Not.

People are using AI: 84% of people, to be precise (or at least, 84% of the people who filled out our survey). This was divided among folks who are all in—taking “an AI-first approach across [their] entire process”—and folks who have AI tools regularly integrated or in experimental phases in their current workflows. Only 16% said they were avoiding the use of AI tools entirely.

The challenge is no longer simply adoption, but rather how to turn AI usage into a reliable, repeatable process.

2. Speed Is Real. Trust Is Conditional.

There’s a lot of back-and-forth right now on whether AI actually delivers its promises of improved productivity.

Our respondents were also mixed; a little over half said it was “moderately positive”, helping somewhat but with some limitations. And 33% found it to have a negative effect—split between being neutral (having no impact), moderately negative (added more work than saved), or significantly negative (disrupted workflow significantly). Only 16% felt strongly positive about it, claiming major time savings and quality improvements.

Speed isn’t an issue, but consistency is. We need tools and systems that can be trusted to produce reliable results in order to scale them across teams and businesses.

3. Collaboration Friction Still Matters

Despite all the new tooling AI has made available to us in the form of quick prototyping, design-to-code features and vibe coding … it hasn’t fixed the core design-dev “handoff” problem.

Only 21% of our participants reported “smooth handoffs and minimal issues” when we asked how they would rate the efficiency of the design implementation process. When things fall through the cracks, slower time-to-market (42%), rework (33%) and wasted time (36%) were listed as the top three consequences—all significant pain points at a time when we’re shipping new products and features faster than ever before.

This is where structured systems, shared standards and better-integrated tooling become critical.

4. 2026 Is About Operational Execution—Not Experimentation

People’s top priority coming into 2026 was the effective implementation of AI tools (39%), closely followed by building hybrid skillsets across their teams (29%). AI is reshaping the workplace, and both teams and individual roles are stretching to incorporate the disruption and turn it into something valuable.

This shift makes the path forward clear: AI needs to move from ad-hoc usage into systems, standards-aware workflows and production-ready processes that can scale. Whether or not that’s possible is something I suppose we’ll have to wait until next year’s survey to find out!

Want the Full Picture?

You can download the full report to see the answers to all the questions, including extra data analysis and interesting cross-sections. We think there’s a lot to learn, and the report is packed with helpful tips—as well as our own predictions on what to watch next.

Finally, if you took the survey: thank you so much! We genuinely enjoyed going through all the responses and seeing what everyone had to say. Keep an eye out for next year’s survey, and—until then—keep building and experimenting. We can’t wait to see what you’ve been working on!

See Full Report

Today, we will learn how to build responsive Blazor web applications. Responsive design is the reason applications feel polished and user-friendly.

We will first learn the basics of responsive design and how to use CSS media queries to implement responsive layouts. Next, we will learn about what we should and should not do in our Blazor logic (C# code).

You can access the code used in this example on GitHub.

What Is Responsive Design for Blazor Apps?

Blazor provides a user interface rendering engine (Razor components) that lets us implement behavior using C#. Blazor components consist of an HTML and CSS template combined with C# interaction logic.

In modern web development, we want to utilize CSS media queries to let our web applications adapt to different screen sizes:

• Small screens, such as mobile phones
• Medium screens, such as tablets
• Large screens, such as desktop computers
• (optional) Ultra-wide monitors

Best practices for general web development also apply to implementing Blazor web applications.

CSS Media Queries in Blazor Components

Let’s learn about CSS media queries using a practical example, a Blazor web application generated from the .NET 10 Blazor Web App project template.

The NavMenu component contains a menu toggler. How it appears on the screen differs completely between a larger and a smaller screen.

For a larger screen, the menu is always visible on the left. For a smaller screen, the menu is collapsed, and the menu toggler is visible. The menu only appears if the user presses the hamburger menu button.

The HTML definition in the NavMenu component looks like this:

<input type="checkbox" title="Navigation menu" class="navbar-toggler" />

It’s an input element with the navbar-toggler CSS class attached.

Let’s look at the CSS code defining that behavior:

.navbar-toggler {
    appearance: none;
    cursor: pointer;
    width: 3.5rem;
    height: 2.5rem;
    color: white;
    position: absolute;
    top: 0.5rem;
    right: 1rem;
    border: 1px solid rgba(255, 255, 255, 0.1);
    background: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 30 30'%3e%3cpath stroke='rgba%28255, 255, 255, 0.55%29' stroke-linecap='round' stroke-miterlimit='10' stroke-width='2' d='M4 7h22M4 15h22M4 23h22'/%3e%3c/svg%3e") no-repeat center/1.75rem rgba(255, 255, 255, 0.1);
}

This CSS class definition defines the visual appearance of the menu toggler. It includes an inline SVG to define the three horizontal lines and a few spacing definitions.

As shown in the image above, on larger screens, this nav menu button is not visible. Let’s look at the CSS code that implements this behavior.

@media (min-width: 641px) {
    .navbar-toggler {
        display: none;
    }
}

The @media syntax introduces the CSS media query feature. In the parentheses, we can implement a filter. In this case, we want all CSS definitions placed inside the curly braces to apply in case the filter condition evaluates to true. In this case, the minimum width of the rendered web page is expected to be 641 pixels.

In other words: When the page is at least 641 pixels in width, we want the CSS definitions inside the curly braces to be applied. In this definition, we set the display property to none for the navbar-toggler CSS class.

Learning: Using CSS media queries, we can implement conditional rules based on a filter criterion. For example, we can add additional CSS definitions for existing CSS classes.

Hint: There are additional CSS definitions inside the NavMenu.razor.css file generated by the default .NET 10 Blazor Web App project template. For simplicity and illustration, I included only the relevant code.

Hiding Information on Smaller Screens

A very useful technique is to show certain information only for larger screens.

As mentioned earlier, you want to carefully decide what information to show on the screen. Does it help the user with the current use case, or does it distract? Is it really necessary?

Consider the following screenshot of the Weather page for a desktop-sized screen.

We have data in four columns: Date, Temperature in Celsius, Temperature in Fahrenheit and Summary.

The Summary column adds a textual explanation and gives slightly more detail than the numerical temperature. Let’s say we don’t want to show that Summary on mobile to help the user focus on the actual temperature numbers.

Let’s add the following class definition to the th and td elements of the table in the Weather page component:

<th class="desktop-only">Summary</th>
<td class="desktop-only">@forecast.Summary</td>

We added the desktop-only CSS class to those HTML elements.

Now, we implement the CSS code inside the Weather.razor.css file:

.desktop-only {
    display: none;
}

@media (min-width: 768px) {
    .desktop-only {
        display: block;
    }
}

We set the display property to none and implement a media query to set it to block for screens larger than 768 pixels.

As you can see in the image, the Summary column doesn’t show up for mobile users.

This is a simple yet powerful technique for conditionally rendering information based on screen size without requiring imperative C# code, such as using the @if directive in the component’s template.

Integrating User Interface Control Libraries

You might think that using a professional user control library, such as Progress Telerik UI for Blazor, solves everything for you. They provide professional-looking, tested user interface controls with accessibility and usability in mind. They also provide theming support, making it easy to apply custom colors.

However, while those components are implemented with responsive design in mind internally, you still have to arrange the layout around them, show and hide panels, and adjust spacing or information density.

You need to understand the overall structure of your web application and know when to step in and adjust the page layout to accommodate the various aspect ratios and device sizes of the modern world—from a handheld smartphone to a large 34" desktop monitor.

A good example provides the implementation of the MainLayout page in the default .NET 10 Blazor Web App project template:

.page {
    position: relative;
    display: flex;
    flex-direction: column;
}

@media (min-width: 641px) {
    .page {
        flex-direction: row;
    }
}

The page CSS class is applied to the most outer div of the MainLayout component. It defines a relative position and a flex layout with the flex direction column. It means that the items will be rendered vertically below each other.

The following media query, with a minimum width of 641 pixels, sets the flex direction to row. It means that for screens at least 641 pixels wide, the items will be placed horizontally beside each other.

This is an excellent example of how to utilize CSS media queries to structure your pages for different screen sizes.

Yes, utilizing one of the proven user interface libraries will take a lot of weight off your shoulders and provide you with ready-to-use building blocks.

It will save you a lot of time and let you focus on solving your business problems rather than reinventing the wheel by implementing foundational components.

However, a fully responsive web application integrates those components to form a truly responsive web application.

In short: Responsive design touches all levels of web application development. You have to consider it when implementing reusable building blocks, and when orchestrating them to form a page or application part.

Best Practices for Implementing Responsive Blazor Web Applications

The following best practices will help you with implementing your responsive Blazor web applications:

1. Use a mobile-first approach: When implementing page layouts, always start with the layout for the smallest screens. It will force you to clearly structure the information and present it in a user-friendly way. Creating the layouts for bigger screens is much simpler than starting with a big screen and trying to size it down.
2. Use CSS Grid & CSS Flexbox: They adapt naturally to screen changes, reducing the need for complex breakpoints and other complex CSS magic. I personally prefer Flexbox for internal component structure and Grid for layout.
3. Use CSS Isolation in Blazor: Component-specific styles written in [Component].razor.css files are scoped and easily maintainable. You’re sure that changes made in that file do not propagate to other components or your entire application code.
4. Avoid screen-size logic in C#: Do not try to detect screen width or similar information from C# interaction code. Let CSS do the layouting and focus on loading, storing, updating and organizing data in your C# Code.
5. Use the browser’s developer tools: Test your responsive web app by changing resolutions and aspect ratios to simulate different devices.
6. Use prebuilt user interface libraries: Reinventing the wheel is time-consuming, and you risk repeating mistakes others have already made and fixed. However, you still need to take care to properly integrate and arrange those third-party components to keep your web application fully responsive.

Conclusion

Blazor provides a powerful, simple user interface rendering engine. However, true responsiveness comes from combining it with modern CSS techniques, such as media queries.

Utilizing CSS Isolation will allow you to separate the scope of your CSS for individual components.

Responsive design is important for implementing modern low-level components, but also for integrating them into a full webpage or web application.

While CSS media queries are powerful and let us implement conditional behavior, it’s still a lot of code that needs to be maintained. Be careful to extract reused code into components to minimize the effect, and use third-party user interface libraries to avoid re-inventing the wheel.

If you want to learn more about Blazor development, watch my free Blazor Crash Course on YouTube. And stay tuned to the Telerik blog for more Blazor Basics.

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

Progress Telerik Document Processing Libraries, in addition to letting you work with a variety of document formats (PDF, DOCX, RTF, HTML, XLSX and more), are an example of the reason you buy into a suite of tools: All the tools bear a “family resemblance.”

The ideal scenario, of course, would be for a single tool that made all these document formats look the same. Given the differences in format and functionality between, for example, a PDF, a Microsoft Word (or RTF or HTML) document and an Excel spreadsheet, that’s not reasonable (though Progress Telerik has achieved that with DOCX, RTF and HTML documents).

The good news here is that, with Telerik Document Processing Libraries (DPL), the family resemblance is strong enough that, for all of the document types the library supports, I can show you how to load documents, start the editing process, convert between various document types and save a document in this one post.

Configuring Your Project

The sample code in this post was all written using the DPL for Windows libraries (even though I was working in ASP.NET Core—the more technical name for the version I used is “.NET(Target OS: Windows).” The suite is also available for the .NET Framework.

To create an ASP.NET Core project that would work with “all the documents,” I added these NuGet packages to my project:

• To work with PDF files: Telerik.Windows.Documents.Fixed
• To work with DOCX, HTML and RTF files: Telerik.Windows.Documents.Flow
• To work with Excel spreadsheets: Telerik.Windows.Documents.Spreadsheet

For the Excel spreadsheets, I’m only going to work with XLSX files, so I added the Telerik.Windows.Documents.Spreadsheet.FormatProviders.OpenXml package to my project. (If I was going to work with, for example, XLS spreadsheet, then I would have added the Telerik.Documents.Spreadsheet.FormatProviders.Xls package.)

Loading Your Document

The code to load a document from a file into any of these libraries is very similar:

1. Create the appropriate provider.
2. Use the .NETFile object’s OpenRead to create a Stream that points to the file.
3. Use the provider’s Import method to load the stream into the document object.

Here, for example, is the code to load a PDF file into a RadFixedDocument object (I used this code in an ASP.NET Core application with documents in my project’s wwwroot folder):

RadFixedDocument doc;
PdfFormatProvider prov = new();

using (Stream str = File.OpenRead(@"wwwroot/documents/Priorities.pdf"))
{
    doc = prov.Import(str, TimeSpan.FromSeconds(10));
}

And here’s the code to load a DOCX file into a RadFlowDocument:

RadFlowDocument doc;
DocxFormatProvider prov = new();

using (Stream str = File.OpenRead(@"wwwroot/documents/Priorities.docx"))
{
    doc = prov.Import(str, TimeSpan.FromSeconds(10));
}

As you can see, the code is identical except for the provider (PdfFormatProvider vs. DocxFormatProvider) and document objects (RadFlowDocument vs. RadFixedDocument).

Because both RTF and HTML documents load into the same RadFlowDocument object as a DOCX document, only the provider object changes (HtmlFormatProvider or RtfFormatProdiver instead of DocxFormatProvider) when working with those file formats. Here’s the code to load an RTF document:

RadFlowDocument doc;
RtfFormatProvider prov = new();

using (Stream str = File.OpenRead(@"wwwroot/documents/Priorities.rtf"))
{
    doc = prov.Import(str, TimeSpan.FromSeconds(10));
}

And here’s the almost identical code to load an HTML file:

RadFlowDocument doc;
HtmlFormatProvider prov = new();

using (Stream str = File.OpenRead(@"wwwroot/documents/Priorities.html"))
{
    doc = prov.Import(str, TimeSpan.FromSeconds(10));
}

The code to load an Excel workbook is also similar to what you’ve seen before, just swapping in a new document object (Workbook) and provider (XlsxFormatProvider):

Workbook doc;
XlsxFormatProvider prov = new();
using (Stream str = File.OpenRead(@"wwwroot/documents/priority.xlsx"))
{
    doc = prov.Import(str, TimeSpan.FromSeconds(10));
}

A note: The Workbook object assumes that you’re going to load the whole Excel workbook into memory. For very large workbooks, that may not make sense. For that scenario, you should look at the SpreadStreamProcessing Library.

Modifying the Documents

Once you’ve loaded the documents, you can start working with them. You can often simplify your code by using the RadFixedDocumentEditor with PDF documents or the RadFlowDocumentEditorwith Word/RTF/HTML documents. Not surprisingly, the code for creating an editor is almost identical for these two document types: create an editor object and pass the document you want loaded into the editor.

The code to create an editor for a PDF document looks like this:

RadFixedDocumentEditor editor = new RadFixedDocumentEditor(doc);

The code for Word/RTF/HTML documents looks like this:

RadFlowDocumentEditor editor = new RadFlowDocumentEditor(doc);

That’s not to say that, as you start working with those documents, there aren’t going to be differences. These are, after all, very different kinds of documents. Having said that, some functionality does work in a similar way across all the document types.

If, for example, I want to search a PDF document for the text “ASP.NET,” I create a TextSearch instance from my document object. I then use the TextSearch object’s FindAll method to search for text in my PDF document, passing two things: my search text and a TextSearchOptions object that specifies how I want my search conducted. That FindAll object returns a collection of SearchResult objects that I can loop through.

Typical code, then, looks like this:

TextSearch search = new TextSearch(doc);
TextSearchOptions opts = new() {
CaseSensitive = false,
WholeWordsOnly = true,
UseRegularExpression = true
                                                              };

IEnumerable<SearchResult> items = search.FindAll("ASP.NET", opts);

Debug.Print($"Found {items.Count()} items.");
foreach (SearchResult item in items)
{
    Debug.Print($"Found at {item.Range.StartPosition} ");
    Debug.Print($"Found: {item.Result}");
}

The process is almost identical for the RadFlowDocument object, except:

• You call the FindAllmethod directly from the RadFlowDocumentEditor.
• There isn’t a separate options object (though all the search options from the TextSearch object are still available).
• The FindAll method on the editor returns FindResult objects instead of SearchResult objects.

As a result, the equivalent search code for a DOCX, RTF or HTML document looks like this:

RadFlowDocumentEditor editor = new RadFlowDocumentEditor(doc);

IEnumerable<FindResult> items = editor.FindAll("ASP.NET");

Debug.Print($"Found {items.Count()} items.");
foreach (FindResult item in items)
{
    Debug.Print($"Found at {item.RelativeStartIndex} ");
    Debug.Print($"Found: {item.FullMatchText}");
}

Searching a spreadsheet works similarly. The differences:

• The FindAll method is built right into the Workbook object.
• You have more search options available with the spreadsheet object.
• You pass your search string as part of the options object.

My find code with a workbook would look like this:

FindOptions opts = new() {
FindWhat = "ASP.NET",
MatchCase = false,
MatchEntireCellContents = true,
                                                };

IEnumerable<FindResult> items = doc.FindAll(opts);

Debug.Print($"Found {items.Count()} items.");
foreach(FindResult item in items)
{
    Debug.Print($"Found at {item.FoundCell.CellIndex} ");
    Debug.Print($"Found: {item.ResultValue}");
}

One note: It is certainly convenient when objects from the different libraries share the same name (like the FindResult object that’s defined in both the RadFlowDocument and Workbook libraries). However, if you try to use both FindResult objects in the same code file, the compiler will get confused because the two objects are in different namespaces. In the unlikely case that you’re working with both Excel and Word documents in the same code file, you’ll have to fully qualify the object names—something I haven’t done in this post.

Saving Your Documents

To save your modified documents back to disk, you just need to use the provider’s Export method. The code for all the document types is identical:

using (Stream str = File.Create(@"wwwroot/documents/Prioritiesnew.<filetype>"))
{
    prov.Export(doc,str, TimeSpan.FromSeconds(10));
}

Converting Documents

You can convert from one type in the suite to other types and, not surprisingly, the conversion processes look very much alike. As you’ve seen before, it often comes down to using the right provider.

If, for example, you want plain text version of your PDF file, you use the TextFormatProvider object’s Export method:

TextFormatProvider prov = new();
string text = prov.Export(doc, TimeSpan.FromSeconds(10));

For Word/HTML/RTF document types, the code is almost identical except it uses the TxtFormatProvider object:

TxtFormatProvider txProv = new();
string text = prov.Export(doc, TimeSpan.FromSeconds(10));            

One note: There is a downside to having the classes that do similar things to different document types have the same name. If you are mixing document types and, as a result, using the Fixed, Flow and spreadsheet libraries in the same application, the compiler can get confused about which class from which library you’re using. If so, you’ll have to fully qualify your class names by including their namespaces in the class names. That makes for hard-to-read code, so I haven’t done that here.

But, as an example of how different documents require different functionality, you probably wouldn’t ever want to convert an Excel workbook to a string … but you might want to save your workbook as a CSV file. As you might expect by now, the code to save your imported workbook into a CSV file just means using the Export method on the appropriate provider—the CsvFormatProvider object in this case.

Typical code would look like this:

CsvFormatProvider prov = new();

using (Stream str = File.Create("Priority.csv"))
{
    prov.Export(doc, str, TimeSpan.FromSeconds(10));
}

Converting any of these document types (Excel, Word, HTML, etc.) to PDF is equally straightforward. Because all the libraries look very much alike, it’s really just a matter of adding the library with the provider you need.

But you can also convert your Workbook object into a RadFixedDocument if you wanted to manipulate your spreadsheet as a PDF object. That conversion is handled by the PdfFormatProvider from the Telerik.Windows.Documents.Spreadsheet.Formatproviders.Pdf package and using its ExportToFixedDocumentmethod:

PdfFormatProvider prov = new();

RadFixedDocument fixedDoc = 
        prov.ExportToFixedDocument(doc, TimeSpan.FromSeconds(10));

The code is identical if you want to convert a Word/RTF/HTML document to a RadFixedDocument to work with it as a PDF file. That conversion also uses a PdfFormatProvider object but, this time, from the Telerik.Windows.Documents.Flow.FormatProviders.Pdf namespace.

But, because the providers from the two libraries have the same name, if you’re using both libraries in the same code file, you will need to fully qualify your provider names to make sure you’re getting the appropriate PdfFormatProvider.

Of course, once you start using these tools to create or modify the documents you’ve loaded, you’ll find more differences—the functionality in a spreadsheet is very different from the functionality in an HTML document. But, while the family resemblances among this suite won’t eliminate those differences, it does cut those differences down to what matters: how those documents differ in their functionality. Which is, after all, what you want.

Explore Telerik Document Processing Libraries, plus component libraries, reporting and more with a free trial of the Telerik DevCraft bundle:

Try DevCraft

Blazor is Microsoft’s framework ideal for creating single-page applications (SPAs), complementing the stack for developing applications entirely in .NET. This is why each year we see significant updates in the framework that allows developers to create secure and robust applications. These changes, along with Blazor control suites like the one from Progress Telerik, undoubtedly accelerate the development of complete apps.

In this article, I will tell you about the new interop features with JavaScript, which certainly marks a significant improvement in handling objects from the C# language. Let’s get started!

Understanding the Problem to Solve

Until .NET 10, interoperability with JS was mainly done by invoking JS functions, without being able to directly handle live objects from C# code, which involved creating wrappers and code that could often lead to failures and runtime errors due to syntax errors.

We can get an idea of the above through a practical case. Suppose that in our application, we have a Blazor Data Grid control that allows displaying products from an online store. Each row has a column with a button to show a lightbox popup, where images are displayed. The demonstration code, for you to gain a complete idea, looks as follows.

First, I created a JavaScript file with the necessary functionality to display the lightbox image gallery:

lightboxGallery.js

window.lightboxGallery = {
    LightboxGallery: class LightboxGallery {
        constructor(imageUrls, startIndex = 0) {
            this.images = imageUrls;
            this.currentIndex = startIndex;
            this.overlayElement = null;
            this.keyHandler = null;
        }

        show() {
            this.createOverlay();
            this.displayImage();
        }

        createOverlay() {
            if (this.overlayElement) {
                this.overlayElement.remove();
            }

            this.overlayElement = document.createElement('div');
            this.overlayElement.className = 'lightbox-overlay';
            this.overlayElement.innerHTML = `
            <div class="lightbox-container">
                <button class="lightbox-close">&times;</button>
                <button class="lightbox-prev">&lsaquo;</button>
                <div class="lightbox-content">
                    <img class="lightbox-image" src="https://www.telerik.com" alt="Gallery Image">
                    <div class="lightbox-counter"></div>
                </div>
                <button class="lightbox-next">&rsaquo;</button>
            </div>
        `;

            document.body.appendChild(this.overlayElement);
            
            this.overlayElement.querySelector('.lightbox-close').addEventListener('click', () => this.close());
            this.overlayElement.querySelector('.lightbox-prev').addEventListener('click', () => this.prev());
            this.overlayElement.querySelector('.lightbox-next').addEventListener('click', () => this.next());

            this.overlayElement.addEventListener('click', (e) => {
                if (e.target === this.overlayElement) {
                    this.close();
                }
            });

            this.keyHandler = (e) => {
                if (e.key === 'Escape') this.close();
                if (e.key === 'ArrowLeft') this.prev();
                if (e.key === 'ArrowRight') this.next();
            };
            document.addEventListener('keydown', this.keyHandler);
        }

        displayImage() {
            if (!this.overlayElement) return;

            const img = this.overlayElement.querySelector('.lightbox-image');
            const counter = this.overlayElement.querySelector('.lightbox-counter');

            img.src = this.images[this.currentIndex];
            counter.textContent = `${this.currentIndex + 1} / ${this.images.length}`;
        }

        next() {
            this.currentIndex = (this.currentIndex + 1) % this.images.length;
            this.displayImage();
        }

        prev() {
            this.currentIndex = (this.currentIndex - 1 + this.images.length) % this.images.length;
            this.displayImage();
        }

        close() {
            if (this.overlayElement) {
                this.overlayElement.remove();
                this.overlayElement = null;
            }
            if (this.keyHandler) {
                document.removeEventListener('keydown', this.keyHandler);
                this.keyHandler = null;
            }
        }
        
        getCurrentIndex() {
            return this.currentIndex;
        }
        
        getImagesLength() {
            return this.images.length;
        }
    }
};

The above code shows the definition of a JS class LightboxGallery with some properties to control the gallery. In addition, methods are also defined to enable interaction with it, such as next, prev, show, etc.

This file needs to be registered in App.razor to be able to use it from the application, as I show you below:

....
<head>
    ...
</head>

<body>
    <Routes @rendermode="InteractiveServer" />
    <ReconnectModal />
    <script src="https://www.telerik.com@Assets["_content/Telerik.UI.for.Blazor/js/telerik-blazor.js"]"></script>
    <script src="https://www.telerik.com@Assets["js/lightboxGallery.js"]"></script>
    <script src="https://www.telerik.com@Assets["_framework/blazor.web.js"]"></script>
</body>

</html>

Finally, I created a Razor page where I use the Blazor Data Grid and Blazor Button components to create a quick and functional graphic interface.

@page "/products-traditional"
@inject IJSRuntime JSRuntime

<PageTitle>Products - Traditional JS Interop</PageTitle>

<div class="container-fluid mt-4">
    <div class="row mb-4">
        <div class="col-12">
            <h1 class="display-6">Product Gallery</h1>          
        </div>
    </div>

    <div class="row">
        <div class="col-12">
            <TelerikGrid Data="@Products"
                         Pageable="true"
                         PageSize="10"
                         Sortable="true"
                         FilterMode="@GridFilterMode.FilterRow"
                         Resizable="true"
                         Height="600px">
                <GridColumns>
                    <GridColumn Field="@nameof(Product.Id)" 
                                Title="ID" 
                                Width="80px" />
                    <GridColumn Field="@nameof(Product.Name)" 
                                Title="Product Name" 
                                Width="200px" />
                    <GridColumn Field="@nameof(Product.Category)" 
                                Title="Category" 
                                Width="150px" />
                    <GridColumn Field="@nameof(Product.Price)" 
                                Title="Price" 
                                Width="120px">
                        <Template>
                            @{
                                var product = context as Product;
                                <span>$@product?.Price.ToString("N2")</span>
                            }
                        </Template>
                    </GridColumn>
                    <GridColumn Field="@nameof(Product.Stock)" 
                                Title="Stock" 
                                Width="100px" />
                    <GridColumn Title="Actions" 
                                Width="150px" 
                                Filterable="false" 
                                Sortable="false">
                        <Template>
                            @{
                                var product = context as Product;
                                <TelerikButton OnClick="@(async () => await ShowImagesTraditional(product))"
                                               ThemeColor="@ThemeConstants.Button.ThemeColor.Primary">
                                    Show Images
                                </TelerikButton>
                            }
                        </Template>
                    </GridColumn>
                </GridColumns>
            </TelerikGrid>
        </div>
    </div>

If we want to invoke the methods from the JS code, there are various ways, although in the following example I show you one of the easiest. To display the gallery, we would use the following code:

private async Task ShowImagesTraditional(Product? product)
{
    if (product == null || product.ImageUrls.Count == 0)
        return;
        
    var imageUrlsJson = System.Text.Json.JsonSerializer.Serialize(product.ImageUrls);
    
    // Step 1
    await JSRuntime.InvokeVoidAsync("eval", 
        $"window.__tempGallery = new lightboxGallery.LightboxGallery({imageUrlsJson}, 0)");
    
    // Step 2
    await JSRuntime.InvokeVoidAsync("eval", "window.__tempGallery.show()");
    
    // Step 3
    var currentIndex = await JSRuntime.InvokeAsync<int>("eval", "window.__tempGallery.currentIndex");
    
    // Step 4
    var imagesCount = await JSRuntime.InvokeAsync<int>("eval", "window.__tempGallery.images.length");
    
    // Step 5
    Console.WriteLine($"Traditional: Showing {imagesCount} images, starting at index {currentIndex}");
    
    isGalleryOpen = true;
    StateHasChanged();    
}

Here’s what we do in the above code:

• Step 1: We use eval and global variables in window to maintain the reference to the gallery.
• Step 2: The method show defined in the class LightboxGallery is called.
• Step 3: We obtain the index of the image from the gallery.
• Step 4: The number of images is obtained using lenght.
• Step 5: The results are displayed based on the information obtained.

The same applies to perform operations like navigating forward or backward:

Navigating Forward

await JSRuntime.InvokeVoidAsync("eval", "window.__tempGallery.next()");

Navigating Backward

await JSRuntime.InvokeVoidAsync("eval", "window.__tempGallery.prev()");

Or even to close the gallery:

await JSRuntime.InvokeVoidAsync("eval", "window.__tempGallery.close()");

await JSRuntime.InvokeVoidAsync("eval", "delete window.__tempGallery");

The example being executed looks as follows:

In the previous example, you can notice several problems, starting with the use of eval, which allows executing text as JavaScript code. Although it is an easy way to run code, it poses a danger as it opens the door to code injection. Moreover, it is slow as it cannot be optimized, is difficult to debug and is generally considered a bad practice.

Another problem is the direct use of global variables in window, as there is a risk of collisions with other libraries in the project; there is no management of galleries or lifecycle, plus there is no control over when to destroy it.

A third serious problem is that there can be a memory leak if the object in memory isn’t destroyed since the browser’s garbage collection (GC) cannot collect the reference, leaving listeners and live DOM references.

New JavaScript Interop Features in Blazor 10

We could continue discussing the multiple issues in the example from the previous section, but let’s focus on the new features of Blazor in .NET 10 to address this.

The InvokeConstructorAsync Method

In .NET 10, it is possible to use the method InvokeConstructorAsync, which allows you to invoke a JS constructor asynchronously. This method will execute the new operator and return a type IJSObjectReference. For example, to display a gallery, it would be done as follows:

@code {
    ...
    private IJSObjectReference? galleryInstance;
    private GalleryInfo? currentGalleryInfo;
    ...
    private async Task ShowImagesModern(Product? product)
    {
        if (product == null || product.ImageUrls.Count == 0)
            return;

        try
        {            
            if (galleryInstance != null)
            {
                await galleryInstance.DisposeAsync();
            }
            
            var imageUrls = product.ImageUrls.ToArray();
            
            // Step 1
            galleryInstance = await JSRuntime.InvokeConstructorAsync(
                "lightboxGallery.LightboxGallery", 
                imageUrls, 
                0);

            // Step 2
            await galleryInstance.InvokeVoidAsync("show");

            // Step 3
            var currentIndex = await galleryInstance.GetValueAsync<int>("currentIndex");
            
            // Step 4
            var imagesLength = await galleryInstance.GetValueAsync<int>("images.length");
            
            //Step 5
            currentGalleryInfo = new GalleryInfo
            {
                CurrentIndex = currentIndex,
                TotalImages = imagesLength
            };

            StateHasChanged();
            
            Console.WriteLine($"Modern: Showing {imagesLength} images, starting at index {currentIndex}");
            
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Error showing images: {ex.Message}");
        }
    }
}

In the above code, the exact same steps are followed to display the gallery, but with cleaner code. InvokeConstructorAsync is used to create the object and maintain its reference, which can in turn be used to invoke other methods using the traditional method InvokeVoidAsync. In our example, we invoke the method show defined in the JavaScript class.

To perform other actions, a similar approach is followed:

To advance:

await galleryInstance.InvokeVoidAsync("next");

To go back:

await galleryInstance.InvokeVoidAsync("prev");

To close the gallery:

await galleryInstance.InvokeVoidAsync("close");
currentGalleryInfo = null;
StateHasChanged();

With this new approach, we have a drastic change not only aesthetically but also internally. For example, each component has its own instance, which prevents collisions between them. Additionally, there is a controlled lifecycle with no memory leaks. You may also notice that parameter passing is much simpler and safer.

The GetValueAsync and SetValueAsync Methods

In addition to the method for invoking a JS function constructor, we can also access the values of the instance obtained through the methods GetValueAsync<TValue>(string identifier) and SetValueAsync<TValue>(string identifier, TValue value). A clear example of this can be seen when we obtain the value of the current image and the length for debugging purposes:

// Step 3
var currentIndex = await galleryInstance.GetValueAsync<int>("currentIndex");

// Step 4
var imagesLength = await galleryInstance.GetValueAsync<int>("images.length");

//Step 5
currentGalleryInfo = new GalleryInfo
{
    CurrentIndex = currentIndex,
    TotalImages = imagesLength
};

StateHasChanged();

Console.WriteLine($"Modern: Showing {imagesLength} images, starting at index {currentIndex}");

In the above code, these values are displayed through an Console.WriteLine, but you could perfectly use them to modify other UI elements or to perform operations.

Conclusion

Throughout this article, you have been introduced to the new JavaScript interop features available in .NET 10, which undoubtedly marks an evolution in the way interaction with JS occurs when necessary. It is time to create safer and typeable code in web apps based on Blazor.

Remember, you can try Telerik UI for Blazor free for 30 days:

Try Now

AI-powered coding assistants have become an important part of modern software engineering workflows. While AI tools excel at generating code quickly, they still require solid context to deliver their full value. This context becomes even more important when working with a UI library like Progress Kendo UI for jQuery, where correct APIs and configuration patterns matter. This is where the Kendo UI for jQuery AI Coding Assistant comes in.

In this article, we’ll explore what the AI Coding Assistant offers and how it helps speed up component development and prototyping when building applications with Kendo UI for jQuery.

Prerequisites: To use the Kendo UI for jQuery AI Coding Assistant, you’ll need a compatible MCP client (we’ll be using Cursor in this article), an active Kendo UI for jQuery license (or trial) and an application that includes Kendo UI for jQuery.

MCP (Model Context Protocol)

Model Context Protocol (MCP) is an open standard developed by Anthropic that standardizes how applications provide context to AI models and agents. Think of it as a common language that allows different systems to share information with AI in a structured way.

MCP works through servers that expose specific tools and knowledge to AI clients. When we install an MCP server, we’re essentially giving our AI assistant access to specialized expertise in a particular domain. For Kendo UI for jQuery, this means the AI can understand component APIs, configuration options and implementation patterns that it wouldn’t otherwise know about.

The Kendo UI for jQuery AI Coding Assistant is integrated into an MCP Server, which means any MCP-compatible client (like Cursor or VS Code) can tap into this specialized knowledge.

Check out the article The Promise of Model Context Protocol for more details on MCP and what it offers.

Setting Up the MCP Server with Cursor

Cursor is an AI-powered code editor that has native support for MCP servers. Let’s walk through the setup process.

Configuring the MCP Server

The first step is creating the MCP configuration file. In the root of our Kendo UI for jQuery project, we’ll create a .cursor folder with an mcp.json file:

{
  "mcpServers": {
    "kendo-jquery-assistant": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@progress/kendo-jquery-mcp@latest"],
      "env": {
        "TELERIK_LICENSE_PATH": "./telerik-license.txt"
      }
    }
  }
}

This configuration tells Cursor to set up the Kendo UI for jQuery MCP server with the name kendo-jquery-assistant. The TELERIK_LICENSE_PATH environment variable should point to the location of our Telerik license file.

After creating the mcp.json file, you may need to restart Cursor to pick up the new MCP configuration.

Enabling MCP in Cursor Settings

Once we’ve set up the configuration file, we’ll need to verify the MCP server is enabled in Cursor’s settings. We can open Cursor settings and navigate to the “MCP Tools” section, and we should see our kendo-jquery-assistant server listed there. We can toggle it on to enable the server.

When the server appears in the list and is enabled, we’re ready to start using the AI Coding Assistant.

Using the AI Coding Assistant

Before we dive into examples, there are a couple of things to keep in mind when working with the Kendo UI for jQuery AI Coding Assistant.

First, we need to make sure our prompts start with one of these trigger phrases: /kendojquery or @kendojquery, which tells Cursor to use the MCP server.

Second, we should verify that the MCP server is actually being used. We’ll look for confirmation messages like “Running kendo-jquery-assistant” or similar statements in the output. If we don’t see this, we might need to rephrase our prompt or check our configuration.

Building a Grid with the Help of the AI Coding Assistant

Now that we have the Kendo UI for jQuery AI Coding Assistant configured, let’s explore how it enhances our development workflow by building a Kendo UI Grid.

Before we start prompting, here’s the base HTML file we’ll be working with. It includes the Kendo UI theme, jQuery and the Kendo UI for jQuery scripts:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Kendo UI jQuery Grid Example</title>

    <!-- Kendo UI default theme -->
    <link rel="stylesheet" href="https://kendo.cdn.telerik.com/themes/12.3.0/default/default-main.css" />

    <!-- jQuery first -->
    <script src="https://code.jquery.com/jquery-3.7.0.min.js"></script>

    <!-- Kendo UI for jQuery -->
    <script src="https://kendo.cdn.telerik.com/2025.4.1321/js/kendo.all.min.js"></script>

    <!-- License script -->
    <script src="telerik-license.js"></script>
  </head>
  <body>
    <h1>My Kendo UI Grid</h1>
  </body>
</html>

With this foundation in place, we can start using the AI Coding Assistant to build our Grid.

Creating a Basic Grid with Sorting and Paging

We’ll start with a simple prompt to create a Grid from scratch:

Prompt: @kendojquery Generate a Kendo UI for jQuery Grid with sorting and paging enabled. Bind the Grid to dummy data.

The MCP server processes this request and provides us with a complete implementation.

The generated code includes everything we need to get started:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Kendo UI jQuery Grid Example</title>

    <!-- Kendo UI default theme -->
    <link rel="stylesheet" href="https://kendo.cdn.telerik.com/themes/12.3.0/default/default-main.css" />

    <!-- jQuery first -->
    <script src="https://code.jquery.com/jquery-3.7.0.min.js"></script>

    <!-- Kendo UI for jQuery -->
    <script src="https://kendo.cdn.telerik.com/2025.4.1321/js/kendo.all.min.js"></script>

    <!-- License script -->
    <script src="telerik-license.js"></script>
  </head>
  <body>
    <h1>My Kendo UI Grid</h1>

    <div id="grid"></div>

    <script>
      $(document).ready(function () {
        // Dummy data for the Grid
        const orderData = [
          { OrderID: 1, OrderDate: new Date("2024-11-06"), Freight: 12.34, ShipCity: "Antwerp", ShipCountry: "Belgium" },
          { OrderID: 2, OrderDate: new Date("2024-03-02"), Freight: 23.45, ShipCity: "Singapore", ShipCountry: "Singapore" },
          { OrderID: 3, OrderDate: new Date("2024-06-26"), Freight: 34.56, ShipCity: "Shanghai", ShipCountry: "China" },
          { OrderID: 4, OrderDate: new Date("2024-09-20"), Freight: 45.67, ShipCity: "Hamburg", ShipCountry: "Germany" },
          { OrderID: 5, OrderDate: new Date("2024-12-12"), Freight: 56.78, ShipCity: "Mumbai", ShipCountry: "India" },
          { OrderID: 6, OrderDate: new Date("2025-02-08"), Freight: 67.89, ShipCity: "Shanghai", ShipCountry: "China" },
          { OrderID: 7, OrderDate: new Date("2025-05-05"), Freight: 78.90, ShipCity: "Tokyo", ShipCountry: "Japan" },
          { OrderID: 8, OrderDate: new Date("2025-08-03"), Freight: 89.01, ShipCity: "Port Klang", ShipCountry: "Malaysia" },
          { OrderID: 9, OrderDate: new Date("2025-10-29"), Freight: 90.12, ShipCity: "Rotterdam", ShipCountry: "Netherlands" },
          { OrderID: 10, OrderDate: new Date("2025-01-23"), Freight: 10.32, ShipCity: "Vancouver", ShipCountry: "Canada" },
          { OrderID: 11, OrderDate: new Date("2024-04-17"), Freight: 21.43, ShipCity: "Colón", ShipCountry: "Panama" },
          { OrderID: 12, OrderDate: new Date("2024-07-11"), Freight: 32.54, ShipCity: "Manila", ShipCountry: "Philippines" }
        ];

        // Initialize the Grid
        $("#grid").kendoGrid({
          dataSource: {
            data: orderData,
            schema: {
              model: {
                fields: {
                  OrderID: { type: "number" },
                  OrderDate: { type: "date" },
                  Freight: { type: "number" },
                  ShipCity: { type: "string" },
                  ShipCountry: { type: "string" }
                }
              }
            },
            pageSize: 5
          },
          columns: [
            { field: "OrderID", title: "Order ID", width: 100 },
            { field: "OrderDate", title: "Order Date", format: "{0:yyyy-MM-dd}", width: 150 },
            { field: "Freight", title: "Freight", format: "{0:c2}", width: 120 },
            { field: "ShipCity", title: "Ship City", width: 150 },
            { field: "ShipCountry", title: "Ship Country" }
          ],
          sortable: true,
          pageable: true,
          height: 400
        });
      });
    </script>
  </body>
</html>

The code includes realistic dummy data, proper Grid initialization with jQuery’s document ready pattern and appropriate configuration for sorting and paging.

This is where the AI Coding Assistant really shines. Instead of receiving generic code that may not work correctly with Kendo UI for jQuery, we’re getting code that follows the library’s practices and patterns.

Adding Filtering Capabilities

Building on our basic Grid, let’s add filtering functionality with a follow-up prompt:

Prompt: @kendojquery Can we add filtering to this Grid?

The MCP server understands our existing context and enhances the implementation:

$("#grid").kendoGrid({
  dataSource: {
    data: orderData,
    schema: {
      // ...
    },
    pageSize: 5
  },
  columns: [
    // ...
  ],
  sortable: true,
  filterable: true, // filterable is added
  pageable: true,
  height: 400
});

The MCP server intelligently added the filterable: true property to our Grid configuration, which demonstrates how we can iteratively build up our components through conversation with the AI.

Enabling Inline Editing

We’ll take our Grid one step further by adding the ability to edit cells inline:

Prompt: @kendojquery Can we make the ship city and ship country columns editable inline?

The MCP server enhances our Grid with editing capabilities:

$("#grid").kendoGrid({
  dataSource: {
    data: orderData,
    schema: {
      OrderID: { type: "number", editable: false },
      OrderDate: { type: "date", editable: false },
      Freight: { type: "number", editable: false },
      // adding editable: true to these columns
      ShipCity: { type: "string", editable: true },
      ShipCountry: { type: "string", editable: true }
    },
    pageSize: 5
  },
  columns: [
    // ...
  ],
  // ...
});

The MCP server understood exactly what we needed. It added the editable property and configured the dataSource schema to specify which fields should be editable. The OrderID, OrderDate and Freight fields are marked as non-editable, while ShipCity and ShipCountry can be edited directly in the Grid cells.

This iterative approach shows the power of working with the AI Coding Assistant. We started with a basic Grid and progressively added sorting, paging, filtering, and now inline editing, all through natural conversation.

Wrap-up

While much of the AI coding hype focuses on newer frameworks, the Kendo UI for jQuery AI Coding Assistant shows that teams working with established technologies like jQuery can still benefit from these same productivity gains.

In this article, we’ve seen how the MCP server provides contextually aware code that follows Kendo UI patterns. Instead of fixing generic AI output or cross-referencing documentation, we can iterate quickly and let the assistant handle the component-specific details.

For more details, check out the official Kendo UI for jQuery AI Coding Assistant documentation. And don’t forget, you can try it yourself, free for 30 days!

Try Kendo UI for jQuery

If you have not yet read Learning Vercel AI SDK—Part 1, that is the best way to get started to follow along today.

In this article, we will learn how to build your first AI agent using the Vercel AI SDK and OpenAI. We are going to use:

• TypeScript
• Vercel AI SDK
• OpenAI

Before getting started, make sure you have the required setup and OpenAI API key. You can get an API key from here.

Setting Up the Project

To get started, create a new Node.js application and set it up to use TypeScript. For that, in your terminal, run the following commands:

npm install -D typescript @types/node ts-node
npx tsc  -init

Once the commands have been executed, replace the contents of your tsconfig.json file with the configuration shown below.

{
  "compilerOptions": {
    "target": "ES2022", 
    "module": "ES2022",
    "moduleResolution": "node",
    "rootDir": "./src",
    "outDir": "./dist",
    "strict": true,
    "esModuleInterop": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules"]
}

After that, install the dependencies below:

• npm install dotenv
• npm install -D @types/dotenv
• npm install -D @types/node tsx typescript
• npm i --save-dev @types/json-schema
• npm install ai @ai-sdk/openai zod

Next, add the .env file to the project root and paste the OpenAI key information below inside the file.

OPENAI_API_KEY= ""

Now that you’ve added your API key and installed all the dependencies, you’ll notice that your package.json file has been updated with these changes.

{
  "name":"agent1",
  "main": "index.js",
  "type": "module",
  "scripts": {
    "build": "tsc",
    "start": "tsc && node dist/index.js"
  },

  "devDependencies": {
    "@types/dotenv": "^6.1.1",
    "@types/json-schema": "^7.0.15",
    "@types/node": "^25.0.6",
    "ts-node": "^10.9.2",
    "tsx": "^4.21.0",
    "typescript": "^5.9.3"
  },
  "dependencies": {
    "@ai-sdk/openai": "^3.0.7",
    "ai": "^6.0.27",
    "dotenv": "^17.2.3",
    "zod": "^4.3.5"
  }
}

In your setup, the package name and version may differ. Next, create a src folder in your project and add an index.ts file inside it. In that file, log the value of your OpenAI key to verify that the project has been configured correctly.

import dotenv from 'dotenv';
dotenv.config();
const openaiApiKey: string | undefined = process.env.OPENAI_API_KEY;
console.log(`OpenAI API Key: ${openaiApiKey}`);

When you execute npm run start in your terminal, you should see your OpenAI key printed in the console.

Agents use tools to perform tasks. So let’s start with creating tools.

Creating a Tool

We’ll begin by creating a very simple tool. The Vercel AI SDK makes it very straightforward to create a tool. You call the tool function and pass an object in it. The input object has properties such as, description, inputSchema and asynchronous execute function.

import { tool, zodSchema } from "ai";
import z from "zod";

export const getTimeTool = tool({
    description: 'Returns the current date and time in ISO format.',
    inputSchema: zodSchema(z.object({})),
    execute: async () => {
      return { time: new Date().toISOString() };
    },
});

The above tool returns the time in ISO format. Notice:

• Schema: z.object({}) : That means model is instructed that to call this tool by passing an empty object.
• inputSchema: zodSchema(z.object({})): That means the tool’s input is an empty object; the model should not pass any arguments, and the SDK will enforce that.

So, the getTimeTool returns an object containing current time in ISO format.

Next, let’s create one more tool to greet the person.

import { tool, zodSchema } from 'ai';
import { z } from 'zod';

export const greetTool = tool({
    description: 'Greets a person by name. Use when the user says hello or asks to greet someone.',
    inputSchema: zodSchema(z.object({
      name: z.string().describe('Name of the person to greet'),
    })),
    execute: async ({ name }) => {
      return { message: `Hello, ${name}!` };
    },
  });

This tool takes person name as input parameter and a prints greeting message.

Creating Agent

We will now use these two tools within an agent to generate a greeting that includes the current time in ISO 8601 format.

To orchestrate tool execution, instantiate an agent using the ToolLoopAgent class. This agent is responsible for iterative tool invocation and model coordination. As shown below, the constructor requires three primary inputs:

• model — The underlying LLM responsible for reasoning and tool selection
• instructions — A system-level directive that constrains behavior (e.g., instructing the agent to greet the user and include the current time in ISO format)
• tools — An array of tool definitions that the agent is authorized to invoke during execution

By injecting the previously defined tools into the tools array, the agent can call them as needed, retrieve the current timestamp, format it in ISO 8601 and construct the greeting deterministically.

var system = `You are a helpful assistant. For this task you MUST:
1. First call the gettime tool to get the current time in ISO format.
2. Then call the greet tool with the person's name (e.g. DJ).
3. After you have called BOTH tools and received their results, write one short final message that greets the person and includes the time in ISO format (e.g. "Hey DJ, here is the time in ISO format: ...").
Do not skip the tools. Call both gettime and greet first, then write your final combined message.`;

const myAgent = new ToolLoopAgent({
    model: openai("gpt-4o-mini"),
    instructions: `${system}`,
    tools: {
      timetool: getTimeTool,
      greettool: greetTool,
    },
    toolChoice: 'auto',
    stopWhen: stepCountIs(3),
});

You can use this agent as shown below, by calling the generate function and passing the user message in the prompt.

const { output } = await myAgent.generate({
    prompt: [
        {
            role: 'user',
            content: "Greet Tom Cruise"
        },
    ],
})
console.log(output);

You should get this output from the agent:

Debugging Agent

You can debug the agent’s behavior by inspecting the steps returned during execution. These steps show each model decision and tool call, making it easier to trace how the agent reached its final output.

const { output,steps } = await myAgent.generate({
    prompt: [
        {
            role: 'user',
            content: "Greet Tom Cruise"
        },
    ],
})

console.log(steps[0].toolCalls[0].toolName);
console.log(steps);

The output should include the name of the first toolName alongside metadata of all tools being invoked.

As you see from the steps output, you can print result of the tool, input and other details. For example, the below snippet prints the first toolName and the output of second tool.

const { output,steps } = await myAgent.generate({
    prompt: [
        {
            role: 'user',
            content: "Greet Tom Cruise"
        },
    ],
})

console.log(steps[0].toolCalls[0].toolName);
console.log(steps[0].toolResults[1].output);

You should get the output:

Agent Loop Control

By default, the agent runs for 20 steps, but we are overriding that for three steps by passing a value to stopWhen property.

const myAgent = new ToolLoopAgent({
    //rest of code
    stopWhen: stepCountIs(3),
});

By default, an agent runs for up to 20 steps. In each step, the model can either generate a final response or call a tool.

If the model generates text, the agent finishes. If it calls a tool, the AI SDK executes that tool and feeds the result back to the model.

To allow the agent to call multiple tools in sequence, we need to increase the stopWhen limit. After each tool execution, the agent starts a new generation step, giving the model another chance to call a tool or produce the final output.

Each step represents one generation that is either generated text or call to the tool. The loop continues until:

• A finish reasoning other than tool calls is returned, or
• A tool that is invoked does not have an execute function, or
• A tool call needs approval, or
• A stop condition is met

To stop the loop, you can combine the multiple stop conditions such as:

1. stepCountIs
2. hasTooCall
3. custom condition

hasToCall is a built-in stopping condition and stops the agent loop when a particular tool is called. You can combine two stop conditions as shown below:

const myAgent = new ToolLoopAgent({
    model: openai("gpt-4o-mini"),
    instructions: `${system}`,
    tools: {
      timetool: getTimeTool,
      greettool: greetTool,
    },
    toolChoice: 'auto',
    stopWhen: [stepCountIs(3), 
        hasToolCall('greettool')
    ]
});

Agent to Send Blog Summary

Putting everything together, let’s build an agent that fetches a blog post, generates a summary and sends it to a specified email address. We’ll use the following libraries:

1. Resend – To send the email. You’ll need an API key from Resend to authenticate requests.
2. Cheerio – To parse and extract content from the blog’s HTML page.

Before implementing the agent, install the required dependencies in your project:

npm install resend
npm install cheerio

Once installed, the agent can use Cheerio to scrape the blog content, generate a summary via the model and then use Resend to deliver that summary via email.

Let’s start by defining a tool that extracts content from a given webpage. This tool will fetch the page, parse its HTML and return the relevant information needed for further processing.

import { tool, zodSchema } from 'ai';
import { z } from 'zod';
import * as cheerio from 'cheerio';

export const extractWebpageTool = tool({
  description: 'Fetches a webpage URL and returns its main text content.',
  inputSchema: zodSchema(z.object({
    url: z.string().url().describe('Webpage URL'),
  })),
  execute: async ({ url }) => {
    try {
      const res = await fetch(url, { headers: { 'User-Agent': 'Agent/1.0' } });
      if (!res.ok) return { success: false, content: '', error: `HTTP ${res.status}` };
      const html = await res.text();
      const $ = cheerio.load(html);
      $('script, style, nav, footer').remove();
      const content = $('body').text().replace(/\s+/g, ' ').trim().slice(0, 15_000);
      return { success: true, url, content };
    } catch (err) {
      return { success: false, content: '', error: err instanceof Error ? err.message : String(err) };
    }
  },
});

Next let’s create a tool to send an email, as shown below:

import { tool, zodSchema } from 'ai';
import { z } from 'zod';
import { Resend } from 'resend';

const resend = new Resend('key);  // your key

export const sendEmailTool = tool({
  description: 'Sends an email. Pass to and body.',
  inputSchema: zodSchema(z.object({ to: z.string().email(), body: z.string() })),
  execute: async ({ to, body }) => {
    const { data, error } = await resend.emails.send({
      from: 'hello@nomadcoder.ai',
      to: [to],
      subject: 'From Agent',
      html: body.includes('<') ? body : `<p>${body.replace(/\n/g, '</p><p>')}</p>`,
    });
    return error ? { success: false, error: error.message } : { success: true, message: `Sent to ${to}` };
  },
});

Next, combine these two tools and register them with the agent so it can orchestrate their execution as part of its workflow.

var system = `You are a helpful assistant. For this task you MUST:
1. First call the extractwebpagetool to get the content of the webpage.
2. Create a summary of the webpage content.
3. After that call the sendemail tool to send the email to the recipient.
3. After you have called BOTH tools and received their results, write one short final message that greets the person and includes the time in ISO format (e.g. "Hey DJ, here is the time in ISO format: ...").
Do not skip the tools.`;

const myAgent = new ToolLoopAgent({
    model: openai("gpt-4o-mini"),
    instructions: `${system}`,
    tools: {
      extractWebpageTool: extractWebpageTool,
      senemail: sendEmailTool,
    },
    toolChoice: 'auto',
    stopWhen: stepCountIs(3),
});

Next, invoke the agent in loop as shown below:

const { output,steps } = await myAgent.generate({
    prompt: [
        {
            role: 'user',
            content: "Send summary of https://www.telerik.com/blogs/how-to-use-cursor-modern-angular to debugmode@outlook.com"
        },
    ],
})

console.log(output);

This agent will send the summary of the given post to the passed email address.

Summary

In this article, we explored how to build an agent using the Vercel AI SDK and implemented a practical example that generates a blog summary and sends it to a specified email address. I hope you found it helpful. Thanks for reading.

Ever since the significant changes that landed with .NET 8, we’ve seen incremental updates to Blazor over several releases.

This year seems set to continue that trend, with some key gaps being filled and refinements to key features. So no structural shifts, new hosting models or render modes, but we do finally get a Label component for forms!

Here are some notable Blazor changes and new features that landed in .NET 11 Previews 1 and 2.

TempData for Static SSR

Ever since .NET 8, we’ve had SSR mode for Blazor. It’s a way of building applications using Blazor’s Razor components, but without resorting to Blazor Server or Blazor WASM to run those components.

With SSR, when a user requests your page, Blazor runs on the server, locates the relevant page component, renders it and returns the generated HTML which is then displayed in the browser.

In this mode you can also use forms to capture user input.

But sometimes you want to take information and persist it between page navigations. For example, maybe a user enters their name in a form, and you want to show them a personalized message on the subsequent confirmation screen, “Thanks, Jon, for your order.”

Prior to .NET 11, this required you to pass the value along somehow, with common solutions involving query string, session state or custom cookies.

But MVC and Razor Pages developers have long been able to use something called Temp Data to store that information between screens. Temp Data is specifically for capturing short-lived messages or data that only need to survive one redirect, then disappear.

In .NET 11, Temp Data is coming to Blazor and will be available as a cascading parameter in static SSR components, with no extra registration needed beyond the usual AddRazorComponents():

[CascadingParameter]
public ITempData? TempData { get; set; }

Let’s say you’re about to redirect your user to a different page. You can write a value to TempData:

private void HandleSubmit()
{
    TempData["SuccessMessage"] = $"Thanks {Input.Name}, your message has been sent!";
    Navigation.NavigateTo("/contact/confirmation");
}

Then pick that up on the page they’re redirected to:

protected override void OnInitialized()
{
    // Get() reads and marks for deletion - one-shot read
    confirmationMessage = TempData?.Get("SuccessMessage") as string;
}

Under the hood, these values are stored in a cookie in the user’s browser.

Once you’ve retrieved a value via Get, it’s marked for deletion. So if you want to check the value without it being deleted, you can use Peek instead. If you want to keep something that has been marked for deletion you can call Keep to cancel the deletion.

IHostedService in Blazor WebAssembly

If you’re using Blazor WebAssembly, you may well have realized there’s one thing you can’t easily do with Blazor running in the browser: schedule jobs to run in the background.

This is a challenge because sometimes you want to separate background work from your component lifecycles. For example, you might want to poll an API (maybe a pricing or notifications endpoint).

In WASM apps, prior to .NET 11, this has been tricky to achieve, often requiring the use of timers within specific components (tied to component lifecycles and only running when the component is rendered), or singleton services with a manual timer.

.NET 11 simplifies this with IHostedService.

You can add a hosted service to your Blazor WASM app and it will start with the app (not a specific component), and run independently of navigation.

AddHostedService<T>() now works with WebAssemblyHostBuilder:

var builder = WebAssemblyHostBuilder.CreateDefault(args);
builder.Services.AddHostedService<PricePollingService>();
await builder.Build().RunAsync();

The service itself is standard BackgroundService, identical to its server-side equivalent:

public class PricePollingService(PriceState state) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            await FetchPricesAsync();
            state.NotifyUpdate();
            await Task.Delay(TimeSpan.FromSeconds(3), stoppingToken);
        }
    }
}

This example uses a Singleton PriceState service and a component which listens for updates to that state.

The PriceState service acts as a shared state container which the background service writes to:

Program.cs

builder.Services.AddSingleton<PriceState>();

PriceState.cs

public class PriceState
{
    public event Action? OnChange;

    public List<PriceQuote> Quotes { get; private set; } = [];
    public DateTimeOffset LastUpdated { get; private set; }

    public void UpdateQuotes(List<PriceQuote> quotes)
    {
        Quotes = quotes;
        LastUpdated = DateTimeOffset.UtcNow;
        OnChange?.Invoke();
    }
}

And then you can subscribe to the OnChange event when that data changes:

PriceWatcher.razor

@implements IDisposable
@inject PriceState State

<p>Last updated: @State.LastUpdated</p>

<!-- render price data here -->

@code {
    protected override void OnInitialized()
    {
        State.OnChange += HandleStateChanged;
    }

    private void HandleStateChanged()
    {
        InvokeAsync(StateHasChanged);
    }

    public void Dispose()
    {
        State.OnChange -= HandleStateChanged;
    }
}

Important note: WASM is single-threaded. BackgroundService gives you a convenient way to abstract background tasks, but not true parallelism.

I/O-bound work (polling, fetching) is typically fine because it’s mostly waiting (await), which frees the thread up in the meantime. But CPU-heavy work would block the UI.

But fear not, there’s a solution for that too!

Web Worker Template

For anything CPU-heavy, you want to keep the main thread (which also handles the UI) free.

.NET 11 introduces dotnet new webworker, which scaffolds a Razor class library with the JS plumbing needed to run .NET code in a browser web worker. Modern web browsers support web workers as a convenient way to run tasks completely separately from your main application’s thread.

The template will create a WebWorkerClient class which uses a factory pattern to create worker instances. Then you can define your worker methods using [JSExport].

Here’s an example, which computes primes (a CPU-heavy task).

PrimesWorker.cs

[SupportedOSPlatform("browser")]
public static partial class PrimesWorker
{
    [JSExport]
    public static string ComputePrimes(int limit)
    {
        // CPU-intensive work runs on the worker thread
        // UI stays responsive
        var result = SieveOfEratosthenes(limit);
        return JsonSerializer.Serialize(new PrimeResult(primes.Count, primes.TakeLast(5).ToArray(), sw.ElapsedMilliseconds));
    }
}

public record PrimeResult(int Count, int[] LastFive, long ElapsedMs);