Telerik Blogs | Web | Blazor

Progress Telerik Agentic UI Generator vs. Syncfusion Agentic UI Builder

2026-04-08T16:38:33Z

See how the AI-based UI creation tools from devtools powerhouses Progress and Syncfusion stack up when they go head to head.

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:

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

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:

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:

Syncfusion Agentic UI Builder Prompt Libraries

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

Blazor Basics: Building Responsive Blazor Apps with CSS Media Queries

2026-04-06T20:25:23Z

Responsive design is the reason applications feel polished and user-friendly. Learn how to build responsive Blazor web applications using CSS media queries.

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">Summaryth>
<td class="desktop-only">@forecast.Summarytd>

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:

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.
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.
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.
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.
Use the browser’s developer tools: Test your responsive web app by changing resolutions and aspect ratios to simulate different devices.
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.

Instantiating Objects and Accessing Properties in Blazor

2026-03-30T19:06:20Z

Learn how to use Blazor’s interop features with JavaScript to handle live C# objects for typeable code.

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 = `
            
                
                
                
                    
                    
                
                
            
        `;

            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 />