DEV Community: Syncfusion, Inc.

Sneak Peek: 4 New Libraries Coming to Syncfusion Document SDK 2026 Volume 3

Lucy Muturi — Tue, 22 Sep 2026 14:24:56 +0000

TL;DR: Before the 2026 Volume 3 release arrives, take a sneak peek at four new libraries coming to Syncfusion Document SDK. From JavaScript Office document automation for DOCX, XLSX, and PPTX files to AI-ready document chunking for enterprise content, these new additions are designed to simplify document processing and power the next generation of document-centric applications. Here’s what developers can expect.

Something new is coming to Syncfusion^® Document SDK.

As we get closer to the Syncfusion Essential Studio 2026 Volume 3 release later this month, we’re excited to reveal four new libraries designed for the next generation of document-centric and AI-powered applications.

Developers increasingly need to automate Word, Excel, and PowerPoint documents directly from code, while AI-powered applications require better ways to transform enterprise content into structured, searchable knowledge.

To help address these challenges, we’re introducing:

JavaScript DOCX Library
JavaScript XLSX Library
JavaScript PPTX Library
.NET Document Chunking Library

Let’s take a closer look at the four libraries arriving in the official 2026 Volume 3 release.

JavaScript DOCX Library: Create Word documents directly in JavaScript

From contracts and invoices to reports and personalized documents, generating DOCX documents has become a common requirement in modern applications.

The new JavaScript DOCX Library can create, read, edit, and save DOCX documents entirely in JavaScript. Instead of relying on Microsoft Word or server-side Office automation, developers can work directly with document content and formatting through a structured object model.

Designed for Node.js and modern web applications, the library can be integrated into React, Angular, Vue, JavaScript, and TypeScript projects, making it easier to incorporate document generation and editing into everyday development scenarios.

Why developers should consider this library

Generate DOCX files from code: Create documents dynamically using application data instead of relying on templates or manual editing.
Modify existing documents: Open DOCX files, update content, and save changes programmatically.
Manage document structure: Work with sections, paragraphs, headers, footers, page layouts, and page settings.
Add rich content: Insert tables, images, charts, shapes, text boxes, lists, bookmarks, and fields.
Control formatting with precision: Apply character- and paragraph-level formatting, including hyperlinks.
Support review scenarios: Preserve comments, revisions, and tracked changes when processing documents collaboratively.
Configure page layouts: Control margins, columns, page numbering, and section breaks.

Create a DOCX document programmatically

The following TypeScript example creates a Word document, adds a section and paragraph, and saves it as a DOCX file:

TypeScript

import { WordDocument } from '@syncfusion/ej2-word';
// Create a new Word document
const document = new WordDocument();

// Add a section
const section = document.addSection();

// Add a paragraph
const paragraph = section.addParagraph();
paragraph.addText('Hello World');

// Save the Word document
document.save('Output.docx');

While this example is intentionally simple, the same approach can be extended to generate invoices, contracts, certificates, proposals, and other business documents directly from application data.

Word documents are only one piece of the document-processing puzzle, though. Many business applications also depend heavily on spreadsheets for reporting, analysis, and data exchange.

That’s where the next addition to the release comes in.

JavaScript XLSX Library: Automate excel reports and spreadsheet generation

Excel remains one of the most common formats for storing, analyzing, and sharing business data, which makes programmatic spreadsheet processing a valuable capability for many applications.

The new JavaScript XLSX Library will give developers direct control over XLSX workbooks from code. Instead of manually generating spreadsheets or depending on Microsoft Excel on the server, you can create, update, and manage workbooks programmatically using a comprehensive workbook object model.

Designed for both Node.js and browser environments, the library enables precise worksheet, cell, and data manipulation without requiring Microsoft Excel or COM dependencies. It can also be integrated into React, Angular, Vue, JavaScript, and TypeScript applications, making it easier to build spreadsheet generation, reporting, and data-processing features directly into modern web applications.

Whether you’re building reporting dashboards, financial systems, CRM applications, or internal business tools, the library will provide the flexibility needed to generate and process spreadsheet data at scale.

Why developers will find it useful

Create and edit workbooks: Like the new DOCX library, the XLSX library provides a programmatic object model for creating and editing workbooks.
Manage workbook structure: Create worksheets, define named ranges, configure document properties, and freeze panes.
Work with cells and formulas: Add text, numbers, dates, formulas, hyperlinks, comments, and rich text formatting.
Build professional reports: Apply styles, conditional formatting, images, shapes, tables, and charts.
Validate and protect data: Enforce data-entry rules and secure worksheets and workbooks.
Create interactive spreadsheets: Add form controls and other elements that enhance usability.

Create an XLSX workbook in code

The following TypeScript example creates a workbook, adds content to a worksheet, and saves it as an Excel file:

TypeScript

import { writeFile } from 'node:fs/promises';
import { Workbook } from '@syncfusion/ej2-xlsx';

// Create a new workbook
const wb = Workbook.create();
const sheet = wb.sheet(0)!; // default first worksheet

// Add a cell value
sheet.cell('A1').value = 'Hello World';

// Save the Excel document
const bytes = await wb.save();
await writeFile('hello-world.xlsx', bytes);

This gives JavaScript developers a programmatic way to create and manipulate Excel workbooks without requiring Microsoft Excel.

Of course, business documents aren’t limited to Word files and spreadsheets. Many organizations also rely on presentations for reporting, training, and executive communication.

Let’s look at the new library designed to simplify PowerPoint automation in JavaScript.

JavaScript PPTX Library: Create and edit PowerPoint presentations programmatically

Whether you’re creating executive reports, sales decks, training materials, project summaries, or customer-facing presentations, manually assembling slides can quickly become time-consuming and difficult to scale.

The new JavaScript PPTX Library enables developers to create, read, edit, and save PowerPoint presentations directly in JavaScript. Instead of relying on Microsoft PowerPoint or server-side Office automation, you can work with slides, layouts, and presentation content through a dedicated presentation object model.

It is designed for Node.js and browser environments. It can also be integrated with React, Angular, Vue, JavaScript, and TypeScript applications, making it easier to add presentation generation capabilities to modern web applications.

Why it’s worth exploring

Maintain consistent branding: Customize master slides and layouts across presentations.
Build visually rich slides: Add shapes, images, tables, charts, and placeholders.
Control text and formatting: Modify paragraph formatting, text content, and hyperlinks.
Work with speaker notes: Create and update presentation notes alongside slide content.
Organize large presentations: Structure slides using sections for easier navigation and maintenance.

Generate PowerPoint presentations dynamically

The following TypeScript example creates a presentation, adds a title slide, inserts content, and saves it as a PowerPoint file:

TypeScript

import { Presentation, Slide, Shape, SlideLayoutType } from '@syncfusion/ej2-powerpoint';

// Create a new PowerPoint presentation
let pptxDoc: Presentation = Presentation.create();

// Add a new slide with a title-only layout
let slide: Slide = pptxDoc.slides.add(SlideLayoutType.TitleOnly);
// Add text to the title shape
let titleShape: Shape = slide.shapes[0] as Shape;
titleShape.textBody.addParagraph('Hello World');
// Save the PowerPoint presentation
await pptxDoc.save('Output.pptx');

.NET Document Chunking Library: Prepare enterprise documents for RAG and AI applications

For many applications, generating documents is already a solved problem. Preparing those documents for AI, however, is an entirely different challenge.

If you’ve built a retrieval-augmented generation (RAG) application, you’ve likely discovered that simply splitting extracted text into fixed-size chunks rarely produces the best results.

Enterprise documents contain valuable context in their structure, including headings, tables, worksheets, slides, sections, and page boundaries. Ignoring that structure can reduce retrieval accuracy and make responses less reliable.

The new .NET Document Chunking Library is designed to address this challenge. It extracts, normalizes, and chunks content from Word, PDF, Excel, PowerPoint, and Markdown documents into meaningful, embedding-ready chunks while preserving the context that AI systems depend on.

Rather than treating a document as plain text, the library understands document structure and supports Markdown-aware, recursive, table-aware, and token-aware chunking strategies. This makes it easier to prepare content for vector databases, semantic search platforms, AI assistants, knowledge bases, and RAG applications without building custom parsing and chunking logic from scratch.

A practical example is an internal knowledge assistant that needs to answer questions from policy documents, spreadsheets, training presentations, and technical manuals. Preserving headings, table relationships, citations, and source metadata can significantly improve retrieval quality and make generated answers easier to verify.

Read the full blog post on the Syncfusion Website

Headroom vs Caveman: A Practical Guide to Reducing AI Coding Costs

Lucy Muturi — Fri, 18 Sep 2026 13:28:39 +0000

TL;DR: AI coding agents often consume thousands of tokens while scanning repositories, analyzing logs, and generating detailed responses. This article compares Headroom and Caveman, two open-source tools that reduce token usage from different directions. Learn how input compression, output optimization, and Syncfusion Code Studio integrations can help lower AI costs while maintaining productivity and development quality.

You start your day inside Syncfusion^® Code Studio with a simple goal: review a pull request, investigate a bug, and ship a feature before lunch.

A few hours later, you’ve accomplished all three, but your AI usage dashboard tells a different story. Thousands of tokens spent. More credits burned than expected. And if you’re part of a team, somebody is already asking why AI costs seem to grow every month.

Two open-source projects, Headroom and Caveman , target this problem from opposite directions. But to understand why they work, it helps to know what is driving those costs in the first place.

Why AI coding costs rise so quickly

When developers think about token usage, they often focus on the prompt and the answer. In practice, a large share of cost comes from everything the model reads before it responds.

That often includes:

Source files
Build logs
Error traces
Tool output
Previous conversation history
Configuration files
Generated diffs and pull request context

For small questions, token usage may stay modest. For repository-wide analysis, debugging sessions, security reviews, or multi-step agent workflows, token consumption can increase fast. That makes token optimization a real engineering concern for teams using AI every day.

Headroom vs Caveman at a glance

Although these tools are often mentioned together, they solve different problems.

Area	Headroom	Caveman
Focus	Input tokens	Output tokens
Optimizes	Files, logs, JSON, conversation history	Assistant responses
Best For	Large-context workloads	Verbose assistant output
Installation Style	MCP integration	Agent skill
Data Processing	Compression before model reads	Response shortening after generation

The simplest way to think about them is this:

Headroom reduces what the model reads
Caveman reduces what the model writes

For many Code Studio tasks, both costs appear in the same request. A repository audit, for example, may require the model to read hundreds of files and then produce a long report. That is where the two tools can work well together.

Note: Headroom and Caveman are independent open-source projects. Syncfusion Code Studio can integrate with them, but they are developed and maintained separately.

While the concept is straightforward, the real question for developers is how these tools fit into an actual Code Studio workflow.

Headroom: Reduce what the model reads

Most developers assume token costs come primarily from prompts and responses.

In reality, a large portion of usage often comes from context.

Before an AI coding agent generates a single line of output, it may read:

Source code files
Build logs
Error traces
Tool outputs
Previous conversation history
Configuration files

Headroom targets that part of the workflow.

It sits between your coding agent and the model, automatically compressing incoming context before it reaches the LLM. The system detects whether the content contains source code, JSON, logs, or plain text and applies compression techniques appropriate for that content type. Headroom is designed to keep the original information recoverable when needed.

For developers working with large repositories, verbose logs, or long-running agent sessions, reducing the number of input tokens can significantly reduce overall costs.

Typical use cases include:

Full repository analysis
Large debugging sessions
Log investigation
Security audits
Agent workflows that process thousands of files

Curious about the technology behind Headroom’s compression pipeline? Explore the project documentation and implementation details on GitHub.

Caveman: Reduce what the model writes

While Headroom focuses on context, Caveman focuses on responses.

Many AI assistants are naturally verbose.

A simple answer often arrives wrapped inside paragraphs of introductions, caveats, and explanatory filler.

For example:

Standard response

You should wrap the object in useMemo because a new reference is created during every render cycle.

Caveman response

New reference every render. Wrap with useMemo. The recommendation remains identical. The difference is that it uses fewer tokens to deliver the same message.

Caveman accomplishes this by modifying the assistant’s communication style. It is designed to preserve code, commands, URLs, and error messages. Only surrounding prose is shortened.

This makes Caveman particularly useful for:

Code reviews
Architecture discussions
Debugging sessions
Refactoring guidance
Repetitive developer conversations

Want to explore Caveman’s compression modes, slash commands, benchmarks, and installation options in more detail? Visit the project on GitHub.

A real Syncfusion Code Studio example

Consider a common request inside Syncfusion Code Studio:

Analyze this repository. Review all files, identify bugs, security issues, performance concerns, and code quality problems. Group findings by severity and recommend fixes.

This type of prompt is expensive because the agent performs two costly operations:

Reads large amounts of source code.
Produces a detailed report.

Without optimization, the repository audit produced the following results

Measurement	Tokens
Input Tokens	789,566
Output Tokens	61,005

These numbers represent the baseline experience without any token-optimization tools enabled. Large repositories, extensive logs, and detailed reports can quickly drive token consumption upward, making repository-wide audits one of the most expensive AI-assisted development tasks.

Running a repository audit in Syncfusion Code Studio

Now let us set up both tools in Syncfusion Code Studio.

Setting up both tools in Syncfusion Code Studio

One reason these projects have gained traction is that neither requires major workflow changes.

Installing Headroom in Code Studio

In Code Studio, Headroom works as an MCP server. This is the cleanest way to connect it because Code Studio picks it up automatically once the configuration file is in place.

Open a terminal and run:

pip install "headroom-ai[mcp]"

In the root of your project, create a folder called .codestudio if it does not already exist. Inside that folder, create a file called mcp.json and paste this configuration:

mcp.json

{
    "servers": {
        "headroom": {
            "command": "headroom",
            "args": [
                "mcp",
                "serve"
            ]
        }
    }
}

This tells Code Studio where to find the Headroom MCP server and how to start it.

Enable Headroom in the Tools tab

Open Syncfusion Code Studio and navigate to the Tools tab. If Headroom appears in the list of available MCP tools, enable it by selecting the checkbox next to it.

To use Headroom, simply add a short instruction to your prompt, such as:

Use the Headroom MCP tool to compress the context and reduce token usage.

When configured correctly, the agent can route large context through Headroom before sending it to the model. This helps reduce input token consumption without requiring any changes to your workflow.

Installing Caveman in Code Studio

Caveman installs as a skill directly into Code Studio. One command handles everything.

Open a terminal and run:

npx skills add JuliusBrussee/caveman -a codestudio

The terminal will show a list of available skills. Select caveman from that list and confirm. The installer creates a file at .codestudio/skills/caveman/SKILL.md inside your project. That file is the skill definition that teaches your agent how to compress its replies.

Activate Caveman at the start of a session

At the beginning of any new chat session in Code Studio, type /caveman and press Enter. That slash command switches the agent into Caveman mode for the rest of that session. From that point on, every reply the agent writes comes back trimmed and direct. Code is never touched. Only the surrounding prose gets compressed.

That is the full setup. Headroom requires a small MCP configuration, while Caveman installs as a skill with a single command.

Note: You can add Code Studio instructions to automatically invoke both tools on every request, so you never have to activate them manually.

Using Headroom and Caveman in Syncfusion Code Studio

Read the full blog post on the Syncfusion Website

Motion vs GSAP in React: Which Animation Library Should You Choose?

Lucy Muturi — Fri, 18 Sep 2026 11:56:11 +0000

TL;DR: Choosing between Motion and GSAP isn’t about which library is better, but which one fits your project. This comparison explores how both libraries handle React animations, page transitions, exit animations, performance, timelines, and developer experience. Learn where Motion’s React-first approach simplifies UI animation workflows and where GSAP’s powerful timeline engine and ScrollTrigger capabilities make it the stronger option for complex interactive experiences.

Building animations in React is not just about making elements move. It is about making motion work with component state, mounting and unmounting, route changes, and interaction patterns that are common in modern apps.

That is why React developers often compare Motion and GSAP. Both can produce polished animations. The bigger difference is how each library fits React’s rendering model and the kind of work your project needs to do.

If your animations are mostly tied to component state, enter and exit transitions, gestures, and reusable UI patterns, Motion usually feels more natural. If your project depends on tightly choreographed sequences, advanced scroll effects, or animation logic that goes beyond React components, GSAP often gives you more control.

In this article, we will compare Motion and GSAP in React across three common scenarios:

Exit animations
Hover and tap interactions
Page transitions

We will also look at accessibility, performance, and the kinds of projects where each library makes the most sense.

Motion and GSAP at a glance

Before diving into code, here is the short version.

Use case	Motion	GSAP
React component animation	Excellent	Good
Declarative animation	Strong	Limited
Exit animations	Excellent	Requires more orchestration
Hover and tap interactions	Built in	Manual handling
Timelines	Good	Excellent
Scroll-driven animation	Good	Excellent
SVG-heavy animation	Good	Excellent
Framework independence	React-focused	Excellent
Complex sequencing	Good	Excellent
Learning curve for React teams	Lower	Higher

Note: Motion package naming

Motion is the current package name for the library previously known as Framer Motion. The recommended package is now motion, with React imports from motion/react. The older framer-motion package still exists for compatibility, but the examples in this article use motion/react for consistency.

Why animation feels different in React

Before React, most frontend animation was done imperatively. You selected an element, changed styles, and told the browser exactly what to do.

JSX

// 1. Select the element
const box = document.getElementById('myBox');

// 2. Imperatively change styles
box.style.backgroundColor = 'blue';
box.style.width = '200px';
box.style.padding = '15px';

That model works well when you are directly controlling the DOM.

React changes the mental model. Instead of manually changing DOM nodes, you describe the UI as a function of state and props. React decides when to update the DOM.

JSX

import React, { useState } from 'react';

export default function App() {
  const [isActive, setIsActive] = useState(false);

  return (
    <button onClick={() => setIsActive(!isActive)}>
      {isActive ? 'Active' : 'Inactive'}
    </button>
  );
}

That difference matters for animation.

In React, the hard part is not whether an element can animate. The hard part is coordinating animation with component lifecycle. If a component unmounts, React can remove its DOM node immediately. If you want an exit animation to finish first, something has to keep that node around long enough for the animation to complete.

The same kind of coordination problem appears when React reuses a DOM node or rerenders a subtree while an animation is still in progress. This is where Motion and GSAP take different approaches.

Motion: built for React components

Motion was designed to work directly with React’s component model. Instead of selecting DOM nodes and animating them manually, you declare animation behavior on components.

JSX

import { motion } from 'motion/react';

< motion.div
  initial={{ opacity: 0, y: 30 }}
  animate={{ opacity: 1, y: 0 }}
  transition={{ duration: 0.4, ease: "easeOut" }}
>
  Dashboard Panel
</motion.div>

This reads like ordinary React because the animation lives alongside the component definition.

For the common React use case, state changes drive UI changes, and animations follow from those changes, Motion removes a lot of manual work. You usually don’t need to wire refs, effects, and cleanup logic just to animate a component into view.

The biggest advantage appears when components leave the screen. React normally removes a component as soon as it is no longer rendered. Motion’s AnimatePresence lets exit animations finish before the DOM node is removed.

JSX

import { motion, AnimatePresence } from 'motion/react';

<AnimatePresence>
  {show && (
    <motion.div
      key="modal"
      initial={{ opacity: 0 }}
      animate={{ opacity: 1 }}
      exit={{ opacity: 0 }}
    />
  )}
</AnimatePresence>

Motion also provides built-in patterns for common UI interactions.

Hover states
Tap interactions
Drag gestures
Page transitions

That makes it especially comfortable in product UIs, admin panels, dashboards, and design systems where motion is tied closely to component behavior.

Another strength is variants. Variants let parent and child animations coordinate naturally through the component tree.

JSX

// Staggered card list -- each card staggers in 80ms after the previous one
import { motion } from 'motion/react';

const containerVariants = {
  hidden: { opacity: 0 },
  visible: {
    opacity: 1,
    transition: {
      staggerChildren: 0.08,
    },
  },
};

const cardVariants = {
  hidden: { opacity: 0, y: 20 },
  visible: { opacity: 1, y: 0, transition: { duration: 0.3 } },
};

export function IssueList({ issues }) {
  return (
    <motion.ul variants={containerVariants} initial="hidden" animate="visible">
      {issues.map((issue) => (
        <motion.li key={issue.id} variants={cardVariants}>
          <IssueCard issue={issue} />
        </motion.li>
      ))}
    </motion.ul>
  );
}

The parent controls the stagger. Each child only defines what its own states mean. That pattern scales well for state-driven UI animation.

GSAP: animation-first, DOM-oriented, extremely flexible

GSAP approaches animation from the opposite direction. It works directly with DOM elements and gives you precise control over timing, sequencing, and complex motion.

In React, that usually means using refs and lifecycle-aware hooks.

JSX

import { useRef, useEffect } from 'react';
import gsap from 'gsap';

function Box() {
  const boxRef = useRef(null);

  useEffect(() => {
    const ctx = gsap.context(() => {
      gsap.from(boxRef.current, { opacity: 0, y: 20, duration: 0.4 });
    }, boxRef);

    return () => ctx.revert(); // cleanup on unmount
  }, []);

  return <div ref={boxRef} className="box" />;
}

GSAP does not depend on React. That is one of its biggest strengths. It works across frameworks and gives you a consistent animation model even when your UI is not purely component-driven.

For React projects, GSAP now provides @gsap/react, which includes a useGSAP() hook designed to make integration cleaner. It helps scope and clean up GSAP objects created during the hook run.

Where GSAP stands out most is complex sequencing. If you need a highly choreographed animation involving multiple elements with precise overlaps and offsets, GSAP timelines are one of the strongest tools available in frontend animation.

JSX

useEffect(() => {
  const ctx = gsap.context(() => {
    const tl = gsap.timeline();
    tl.from('.hero-title', { opacity: 0, y: 40, duration: 0.6 })
      .from('.hero-subtitle', { opacity: 0, y: 20, duration: 0.4 }, '-=0.2')
      .from('.hero-cta', { opacity: 0, scale: 0.9, duration: 0.3 }, '-=0.1');
  });

  return () => ctx.revert();
}, []);

Motion can handle sequencing, but GSAP is usually the better fit for hand-crafted, timeline-heavy motion, advanced scroll effects, and animation outside standard React component patterns.

React animation examples in Motion and GSAP

To make the differences concrete, here are a few common React animation scenarios implemented in both libraries.

Example 1: Exit animation before unmount

Exit animations are where React animation gets more interesting. The challenge is that React removes the DOM node as soon as the component stops rendering, unless something intercepts that process.

Motion

ExitAnimationMotion.jsx

import { motion, AnimatePresence } from 'motion/react';

export function ToastNotification({ show, message }) {
  return (
    <AnimatePresence>
      {show && (
        <motion.div
          key="toast"
          className="toast"
          initial={{ opacity: 0, y: -20 }}
          animate={{ opacity: 1, y: 0 }}
          exit={{ opacity: 0, y: -20 }}
          transition={{ duration: 0.3 }}
        >
          {message}
        </motion.div>
      )}
    </AnimatePresence>
  );
}

This is a strong example of Motion’s React-first design. AnimatePresence keeps the element mounted long enough for the exit animation to finish.

GSAP:

This example uses the @gsap/react useGSAP() hook, which is the recommended pattern for React integrations.

ExitAnimationGSAP.jsx

// production-ready
import { useRef, useState, useEffect } from 'react';
import gsap from 'gsap';
import { useGSAP } from '@gsap/react';

gsap.registerPlugin(useGSAP);

export function ToastNotification({ show, message }) {
  const [shouldRender, setShouldRender] = useState(show);
  const toastRef = useRef(null);

  useEffect(() => {
    if (show) setShouldRender(true);
  }, [show]);

  useGSAP(() => {
    if (!shouldRender || !toastRef.current) return;

    if (show) {
      gsap.fromTo(toastRef.current,
        { opacity: 0, y: -20 },
        { opacity: 1, y: 0, duration: 0.3 }
      );
    } else {
      gsap.to(toastRef.current, {
        opacity: 0,
        y: -20,
        duration: 0.3,
        onComplete: () => setShouldRender(false),
      });
    }
  }, {
    dependencies: [show, shouldRender],
    scope: toastRef,
    // Kills the previous run's tween before this run starts
    //This is what makes rapid show/hide toggling safe.
    revertOnUpdate: true,
  });

  if (!shouldRender) return null;

  return (
    <div ref={toastRef} className="toast">
      {message}
    </div>
  );
}

This implementation is workable, but it shows the extra coordination GSAP often needs in React. You have to keep the component mounted after show becomes false, wait for the exit animation to complete, then remove it.

If your app uses many modals, drawers, tooltips, and toasts, this difference adds up quickly.

Best fit in this scenario: Motion

Example 2: Hover and Tap Interactions

Buttons, cards, and interactive controls often need hover and press feedback.

Motion

InteractiveButtonMotion.jsx

import { motion } from 'motion/react';

export function AnimatedButton({ children, onClick }) {
  return (
    <motion.button
      onClick={onClick}
      whileHover={{ scale: 1.05 }}
      whileTap={{ scale: 0.95 }}
      transition={{ type: 'spring', stiffness: 400, damping: 17 }}
      className="btn-primary"
    >
      {children}
    </motion.button>
  );
}

This is concise and expressive. Motion’s gesture props fit UI-level interactions well.

GSAP:

This example uses Pointer Events, contextSafe(), and explicit overwrite handling with @gsap/react.

InteractiveButtonGSAP.jsx

// production-ready
import { useRef } from 'react';
import gsap from 'gsap';
import { useGSAP } from '@gsap/react';

gsap.registerPlugin(useGSAP);

export function AnimatedButton({ children, onClick }) {
  const btnRef = useRef(null);

  // contextSafe() marks handler-triggered tweens as trackable/cleanable,

  // same as tweens created directly inside useGSAP().
  const { contextSafe } = useGSAP({ scope: btnRef });

  const animate = contextSafe((vars) => {
    gsap.to(btnRef.current, { ...vars, overwrite: 'auto' });
  });

  const handlePointerEnter = () => animate({ scale: 1.05, duration: 0.2, ease: 'power2.out' });
  const handlePointerLeave = () => animate({ scale: 1, duration: 0.2, ease: 'power2.out' });
  const handlePointerDown = () => animate({ scale: 0.95, duration: 0.1, ease: 'power2.in' });
  const handlePointerUp = () => animate({ scale: 1.05, duration: 0.1, ease: 'power2.out' });

  return (
    <button
      ref={btnRef}
      onClick={onClick}
      onPointerEnter={handlePointerEnter}
      onPointerLeave={handlePointerLeave}
      onPointerDown={handlePointerDown}
      onPointerUp={handlePointerUp}
      onPointerCancel={handlePointerLeave}
      className="btn-primary"
    >
      {children}
    </button>
  );
}

GSAP can absolutely handle this, but the interaction logic is more manual. That is not a flaw in GSAP so much as a sign that it operates at a lower level. For common UI interaction states, Motion usually asks for less code.

Best fit in this scenario: Motion

Read the full blog post on the Syncfusion Website

Build Modern .NET MAUI Apps with .NET 11 [Webinar Show Notes]

Lucy Muturi — Thu, 17 Sep 2026 10:31:35 +0000

TL;DR: Could .NET 11 finally solve some of .NET MAUI’s biggest developer pain points? In this webinar show notes, discover how CoreCLR, faster XAML and Hot Reload workflows, stronger native platform features, AI-assisted development, and new Syncfusion controls are transforming cross-platform app development beyond incremental updates.

.NET MAUI continues to evolve as Microsoft focuses on improving performance, reliability, developer productivity, and the native application experience across Android, iOS, Mac Catalyst, and Windows.

In this webinar, Principal Product Manager David Ortinau from Microsoft explored the improvements arriving with .NET MAUI in .NET 11 and demonstrated how developers can begin applying them to real cross-platform applications.

From a new runtime foundation and XAML improvements to navigation, gestures, maps, security, and updated Syncfusion controls, .NET 11 introduces changes throughout the development experience.

If you missed the webinar or would like to watch it again, the recording is on our YouTube channel and embedded below.

Time stamps

[00:00] Introduction and .NET 11 RC1

[02:00] State of .NET MAUI in 2026

[04:42] Syncfusion’s contributions to .NET MAUI

[08:08] CoreCLR becomes the .NET MAUI runtime

[09:29] ReadyToRun and Native AOT options

[14:32] .NET MAUI 11 feature highlights

[14:54] CollectionView improvements on Windows

[15:34] Maps, status bar, and splash screen improvements

[17:28] XAML improvements in .NET 11

[17:55] XAML incremental Hot Reload

[18:41] Syncfusion .NET MAUI Toolkit updates

[19:35] Developer Balance sample with .NET 11

[20:34] Long-press gestures

[22:13] Syncfusion GridSplitter

[23:14] Syncfusion InteractiveViewer

[24:02] Chart tooltips

[24:38] Live .NET 11 application demo

[25:45] GridSplitter demo

[26:43] Long-press gesture demo

[27:34] SwipeView styling

[28:04] InteractiveViewer demo

[29:31] .NET 11 code walkthrough

[32:12] Adapting the experience for Android and mobile

[34:03] Tab badges and navigation updates

[38:13] Q&A: Linux and macOS options with MAUI Labs

[38:46] MAUI Sherpa

[40:08] MAUI Dev Flow and AI-assisted development

[41:35] Q&A: Syncfusion’s .NET MAUI roadmap

[42:13] Q&A: Hot Reload improvements in .NET 11

[44:35] TabbedPage, Shell, and navigation guidance

[45:53] Shell route templates

[46:50] Map pin clustering

[48:00] Passkeys and passwordless authentication

[49:26] Material 3 support

[51:01] Safe-area and edge-to-edge improvements

[51:32] Light and dark splash screen themes

[52:36] Compiled XAML and resource loading

[53:58] C# expressions in XAML

[55:48] .NET MAUI support lifecycle and upgrading

[57:45] .NET Run, .NET Watch, and testing improvements

[58:35] Key takeaways for adopting .NET MAUI 11

[59:51] Audience Q&A

[01:08:03] Q&A: Reducing .NET MAUI app size

[01:10:58] Closing remarks

Moving .NET MAUI to CoreCLR

One of the most significant changes in .NET 11 is the move to CoreCLR as the runtime across .NET MAUI platforms.

For developers, adopting it is straightforward: target .NET 11 and the application runs on CoreCLR.

This transition gives .NET MAUI access to a runtime that has been heavily optimized and tested throughout the broader .NET ecosystem. It also creates opportunities for continued improvements to debugging, Hot Reload, telemetry, logging, stability, and runtime performance.

Developers targeting Android can also evaluate different deployment strategies depending on their application requirements.

ReadyToRun

ReadyToRun provides options for improving runtime performance, with the tradeoff of increased application size.

Native AOT

Native AOT raises the bar for trimming compatibility and requires developers to address related warnings and dependencies, but it can deliver highly optimized startup performance and smaller application binaries.

The right approach depends on the individual application, making performance measurement and benchmarking an important part of the upgrade process.

Improving the XAML development experience

.NET 11 includes substantial work to XAML.

Source generation is playing a larger role in the XAML pipeline, with opportunities to reduce allocations and improve performance. Developers can also choose how certain resources are loaded, including lazy-loading scenarios that can help optimize applications.

C# expressions in XAML provide another way to reduce unnecessary boilerplate.

Instead of creating a value converter for every simple piece of presentation logic, developers can use concise C# expressions for appropriate scenarios while keeping larger pieces of logic in code-behind or application code.

XAML incremental Hot Reload

Hot Reload continues to receive significant investment for .NET MAUI. .NET 11 includes improved XAML incremental Hot Reload, while .NET Watch is becoming an increasingly important part of the Hot Reload workflow across platforms.

For client application development, where full rebuild cycles can be costly, reducing the amount of work required to see a UI change can have a major impact on everyday productivity.

Build performance is also receiving attention, including support for multithreaded build scenarios where appropriate.

Building better native experiences

Several .NET 11 improvements focus on capabilities developers frequently need when creating native experiences.

Long-press gestures

Long-press gestures can now be implemented through a cross-platform .NET MAUI API. These gestures are useful for secondary or advanced actions and don’t require developers to build separate, platform-specific implementations.

The webinar demonstrated this in a task application where tapping opens an item while a long press exposes additional actions.

SwipeView styling

SwipeView has also received improvements, including more flexible styling of icons and text. Combined with theme bindings, developers can build swipe experiences that remain visually consistent in light and dark modes.

Using the Syncfusion .NET MAUI Toolkit

The webinar also highlighted several controls available through the open-source Syncfusion .NET MAUI Toolkit. These controls are used within the Developer Balance sample to extend the application while keeping the UI responsive in desktop and mobile form factors.

Grid Splitter

The Grid Splitter allows desktop and data-dense applications to divide available space into adjustable panes. Users can resize, expand, or collapse areas of the interface, and developers can also control the behavior programmatically. This is particularly useful when larger screens provide enough space to display multiple pieces of information simultaneously.

Interactive Viewer

The Interactive Viewer provides built-in panning, zooming, and rotation for content larger than the available display area. Instead of manually creating gesture and transformation handling, developers can place content inside the viewer and configure the experience.

Potential scenarios include diagrams, images, maps, documents, and other dense visual content.

Chart tooltips

Chart tooltips provide another layer of information for data visualization. Developers can determine which information should appear when users interact with chart elements, complementing existing legends and making data easier to explore.

Designing responsive cross-platform applications

Building cross-platform software doesn’t mean every screen must use exactly the same layout.

The webinar demonstrated a desktop interface that uses additional screen space for controls and panels while the Android version provides a more compact mobile experience.

.NET MAUI applications can adapt based on factors such as device idiom or screen dimensions. For example, desktop and tablet experiences may use flyout navigation, while smaller phones may rely on tabs or gestures.

The goal is to share as much application code as practical while still delivering an experience that feels appropriate and native on each platform.

Navigation improvements

.NET 11 also continues the modernization of .NET MAUI navigation. Underlying handlers are becoming more consistent among Shell, TabbedPage, FlyoutPage, and related navigation components.

Tab badges

Developers can display badges in tab-based navigation, including scenarios using either Shell or TabbedPage.

Rather than prescribing a single navigation architecture, the guidance is to choose the approach that works best for the application’s requirements. Shell provides a convenient higher-level experience, while the lower-level navigation primitives remain available for more customized layouts.

Shell route templates

Shell route templates make it easier to represent values directly within navigation paths. Instead of relying only on query-string parameters, applications can define templated route segments and retrieve values when navigating to the corresponding page.

This can result in cleaner and more expressive navigation structures.

Making maps easier to use

Maps receive several improvements in .NET 11. One new capability is pin clustering. When many map pins occupy the same geographic area, clustering groups them together until the user zooms further into the map. This helps prevent dense datasets from overwhelming the interface and provides behavior familiar to users of modern mapping applications.

Adding passwordless authentication with passkeys

Security is another focus area for modern application development.

.NET MAUI 11 provides improved support for passkeys, helping developers implement passwordless authentication without having to assemble the complete platform integration themselves.

Supporting modern Android experiences with Material 3

Material 3 support has continued to expand in recent .NET MAUI releases and is highlighted as an important part of .NET 11. Developers can opt into Material 3 styling for Android applications through project configuration rather than recreating the experience manually.

The webinar also discussed improvements around edge-to-edge layouts and safe areas, helping applications adapt to modern Android presentation requirements.

Light and dark splash screen themes

Applications that follow system appearances can now more easily provide splash screens appropriate for both light and dark themes. This prevents situations where an application configured for dark mode begins with an unexpectedly bright splash screen.

Developers can configure this at the cross-platform project level and implement more customized platform-specific behavior when needed.

Expanded .NET CLI and testing support

The developer workflow receives several updates alongside the UI and runtime improvements.

.NET Run now provides broader support for MAUI workflows and can offer interactive device selection when a target device hasn’t already been specified.

.NET Watch is supported across platforms as part of the ongoing Hot Reload work.

Testing support has also expanded, with test projects supported across the .NET MAUI platforms.

Using AI to improve the development workflow

AI-assisted development is also becoming part of the .NET MAUI workflow. The session discussed using development agents to help with tasks such as:

Upgrading projects between .NET versions.
Reviewing release documentation.
Running application tests.
Interacting with applications.
Benchmarking performance.
Investigating startup time and memory usage.
Identifying opportunities to reduce application size.

Tools and experiments such as MAUI Dev Flow demonstrate how agents can interact with running applications rather than requiring developers to perform every testing step manually.

The goal is not simply generating code faster. AI can also help developers validate, benchmark, and understand the applications they are building.

Evaluating application size and performance

There is no single configuration that will produce the best result for every application.

Developers should investigate where application size comes from and optimize based on the actual deployment target. Potential strategies include:

Removing unnecessary assets and dependencies.
Loading large media only when required.
Targeting only the required device architectures.
Choosing the appropriate store bundle configuration.
Evaluating ReadyToRun options.
Using Native AOT when the application’s dependencies and trimming requirements support it.

Each option comes with tradeoffs between application size, performance, compatibility, and development effort. Benchmarking the actual application remains the best way to determine which approach makes sense.

Getting started with .NET MAUI 11

The simplest next step is to take an existing application and run it on .NET MAUI 11. Developers can then evaluate startup time, application size, memory behavior, and compatibility before deciding which additional .NET 11 capabilities they want to adopt.

From incremental Hot Reload and Shell route templates to passkeys, maps, updated XAML features, and new Syncfusion Toolkit controls, teams can adopt the improvements that provide the most value for their applications.

.NET MAUI 11 continues the framework’s focus on better performance, stronger tooling, richer native capabilities, and more productive cross-platform development.

Related Blogs

This article was originally published at Syncfusion.com

Multi-Agent AI Systems: A Smarter Way to Detect and Manage Technical Debt

Lucy Muturi — Tue, 15 Sep 2026 11:56:03 +0000

TLDR: Multi-agent AI systems use specialized AI agents to analyze repositories across architecture, security, performance, testing, and code quality. By combining multiple perspectives, they help teams identify risks earlier, prioritize improvements, and address technical debt more systematically.

Modern development teams ship features at an incredible pace. AI coding assistants have accelerated development even further, making it possible to generate large amounts of code in minutes.

But as repositories grow, writing code is no longer the hardest part. Maintaining quality across thousands of files, multiple services, and dozens of contributors becomes increasingly difficult.

Most teams still rely on:

Manual code reviews,
Static analysis tools,
Security scans,
Periodic architecture reviews, and
Technical debt audits.

These practices are valuable, but they often operate as separate checks rather than providing a unified view of repository health.

A performance bottleneck might remain unnoticed until users complain.

Architectural issues may only surface when new features become difficult to implement.
Security vulnerabilities can go undetected until much later in the development cycle.

What teams need isn’t just faster code generation. They need a better way to understand repository health and prioritize improvements.

This is where multi-agent AI systems can make a meaningful difference.

What is a multi-agent AI system?

A multi-agent AI system uses multiple specialized AI agents that collaborate to analyze and improve a repository. Instead of asking one AI assistant to inspect everything, responsibilities are divided among specialized reviewers.

Different agents focus on areas such as:

Architecture,
Security,
Performance,
Testing,
Code quality, and maintainability.

Together, they can provide broader repository coverage by analyzing different aspects of software quality simultaneously. The actual value depends on how well the agents are scoped, coordinated, and supported with relevant context.

A typical multi-agent system may:

Analyze repository structure,
Identify risks and bottlenecks,
Detect quality issues,
Recommend improvements,
Prioritize findings, and
Track progress over time.

This transforms governance from an occasional review activity into a more systematic engineering process.

When does a multi-agent approach make sense?

Not every repository needs a multi-agent architecture.

A multi-agent approach often makes sense when:

The repository is large or rapidly growing.
Multiple quality dimensions need evaluation.
Different teams own different parts of the system.
Audits are performed repeatedly.
Findings must be consolidated and prioritized.

A single-agent approach may be better when:

The repository is relatively small.
Tasks are narrowly scoped.
Execution cost is more important than broad coverage.
There is limited cross-domain complexity.

The goal is not to replace simpler processes, but to introduce multiple specialized perspectives when the repository’s complexity justifies it.

Why single-agent approaches can struggle with complex repositories

A single AI assistant behaves much like a capable generalist developer. That approach works well when reviewing a component, investigating a bug, or solving a focused problem.

Modern applications, however, rarely contain isolated concerns.

For example:

A performance improvement may introduce security considerations.
An architectural change can affect testing coverage.
A deployment modification may impact reliability.

As complexity grows, teams often benefit from multiple specialized perspectives.

When agents are well-scoped and properly coordinated, a multi-agent approach can provide broader coverage, reduce blind spots, and make findings easier to organize.

The goal isn’t simply finding more issues. It’s helping teams identify the issues that matter most before they become expensive problems.

Single-agent vs. Multi-agent approaches

Aspect	Single-agent approach	Multi-agent approach
Responsibilities	One agent handles multiple concerns	Tasks are divided among specialized agents
Coordination	Simpler	Requires orchestration
Domain coverage	Broad but potentially shallow	Specialized across domains
Complexity	Lower	Higher
Resource usage	Usually lower	Can be higher
Failure handling	Fewer coordination points	More coordination and failure points
Best suited for	Focused tasks	Complex problems requiring multiple perspectives

Multi-agent systems are not automatically better. They introduce additional coordination, execution, and management complexity. Their value comes when specialization provides benefits that justify that added complexity.

Multi-agent architectures in practice

Multi-agent systems are commonly implemented using either centralized or decentralized coordination.

Architecture	Best for	Trade-off
Centralized	Consistent coordination and shared decision-making	Dependency on central controller
Decentralized	Flexible agent-to-agent collaboration	More complex coordination

For repository governance scenarios, the choice depends on whether consistency or flexibility is the higher priority.

Specialized AI auditors for code governance

One of the biggest advantages of multi-agent AI systems is specialization. Rather than asking one agent to evaluate everything, different agents focus on different aspects of software quality.

1. Architecture auditor

Evaluates structural integrity, coupling, scalability concerns, and service boundaries.

Example: Detects excessive dependencies between services that make future changes more difficult.

2. Security auditor

Identifies hardcoded secrets, authentication risks, vulnerable dependencies, and common security weaknesses.

Example: Flags API keys committed directly into source control.

3. Performance auditor

Reviews query efficiency, resource usage patterns, response time risks, and optimization opportunities.

Example: Identifies N+1 database query patterns that may increase latency.

4. Testing auditor

Evaluates test coverage, edge-case handling, and testing gaps.

Example: Detects payment processes with insufficient automated testing.

5. Code quality and maintainability auditor

Identifies duplication, readability concerns, documentation gaps, and maintainability issues.

Example: Highlights duplicate business logic appearing across multiple services.

Together, these auditors help teams develop a more holistic understanding of repository health.

Real-world example: Auditing a large SaaS repository

Consider a SaaS platform with:

Multiple microservices,
Hundreds of monthly pull requests,
Several engineering teams, and
Growing technical debt.

The team recently adopted AI-assisted development and significantly increased delivery speed. However, repository health became harder to understand.

Sample prioritized findings

Finding	Auditor	Priority
Exposed credentials in configuration	Security	Critical
Missing test coverage in payment process	Testing	High
Expensive database query affecting API response time	Performance	High
Increasing service coupling	Architecture	Medium

Individually, these findings are useful. Together, they reveal broader risks that might otherwise be missed.

Instead of receiving disconnected warnings, the engineering team receives a consolidated, prioritized view of repository health.

This is where multi-agent systems provide meaningful value: helping teams move from isolated observations to informed engineering decisions.

From findings to action

Analysis alone does not improve software quality. Teams must still decide what to fix first and how to implement changes.

Refactoring and planning

A planning component can:

Consolidate findings,
Remove duplicate recommendations,
Prioritize issues,
Evaluate impact versus effort, and
Provide implementation guidance.

Implementation support

Implementation-focused agents may:

Suggest refactorings,
Generate code recommendations,
Track remediation progress, and
Assist with follow-up work.

However, implementation should remain subject to developer review and approval, particularly for security-sensitive, architectural, or production-impacting changes.

The role of these systems is to help teams discover and organize improvements, not replace engineering judgment.

Running your first multi-agent audit in Code Studio

Getting started with multi-agent governance in Syncfusion Code Studio is straightforward. The idea is simple: create a set of specialized AI auditors, point them at your repository, and let them analyze different aspects of code quality in parallel.

Step 1: Create your AI agents

Start by creating the agents you want to use in the .codestudio/agents/ directory.

Select the Configure Custom Agents option in the chat interface. Create as many agents as required.

Creating AI agents in Code Studio

Common examples include:

Security auditor,
Architecture auditor,
Performance auditor,
Testing auditor, and
Code quality auditor.

Each agent is defined using a simple Markdown configuration that describes its purpose and responsibilities.

Multi-agent AI systems allow each auditor to focus on a specific area, resulting in more comprehensive and actionable insights than a single general-purpose reviewer.

Step 2: Open your repository in Code Studio

Once your AI auditors are configured, open the repository you want to analyze in Code Studio and verify that your .codestudio/agents/ directory contains the agents you’ve created.

A typical structure might look like:

| .codestudio/

└─ agents/

├─ security-auditor.md

├─ architecture-auditor.md

├─ performance-auditor.md

└─ testing-auditor.md |

This directory acts as the discovery point for your audit configuration.

When an audit begins, Code Studio automatically identifies the available agents and invokes them based on their defined responsibilities. By organizing agents this way, you can easily customize the analysis for different repositories.

For example, a security-focused project might use additional security auditors, while a large enterprise application may include agents for architecture, maintainability, and DevOps reviews.

Read the full blog post on the Syncfusion Website

Angular Zoneless Change Detection Explained: Angular Without Zone.js

Lucy Muturi — Mon, 14 Sep 2026 11:30:00 +0000

TL;DR: Zoneless Angular replaces Zone.js-based change-detection scheduling with explicit Angular notifications such as signals, template events, and AsyncPipe emissions. The result can be more predictable rendering, simpler debugging, and greater control over UI updates. Before migrating, developers should verify external integrations, Reactive Forms workflows, third-party libraries, and tests for compatibility.

Angular’s popularity didn’t come from powerful APIs alone. It came from a developer experience that felt effortless.

Update a variable, and the UI updates automatically.

For years, Zone.js powered that experience by helping Angular know when application state might have changed. But as Angular applications grew larger and more complex, developers began facing challenges with performance tuning, debugging, and understanding exactly what triggered UI updates.

To address these challenges, Angular has introduced new reactive capabilities, including signals and zoneless change detection.

In Angular 20.2, zoneless change detection became stable, and Angular 21 enables it by default. Instead of relying heavily on Zone.js to detect asynchronous activity, Angular now uses more explicit mechanisms to determine when UI updates should occur.

Why Angular used Zone.js

Historically, Angular relied on Zone.js to monitor asynchronous browser operations such as:

Timers
Promises
DOM events
Network callbacks

When one of these operations completed, Angular received a notification and scheduled change detection.

The process looked roughly like this:

                    Async operation

                          ↓

              Zone.js detects completion

                          ↓

                 Angular is notified

                          ↓

                Change detection runs

                          ↓

                     Views update

This model worked well and removed much of the complexity involved in keeping UI and application state synchronized.

However, it also introduced challenges:

Change detection could run more often than necessary.
Debugging sometimes became harder because of zone-related call stacks.
Performance optimization could require significant investigation.
It was not always obvious what triggered a UI update.

As Angular evolved, the framework began moving toward more explicit reactive patterns.

Signals: The foundation of modern Angular reactivity

One of Angular’s most important additions is signals.

A signal represents a reactive state that Angular can track directly.

JavaScript

readonly count = signal(0);

add() {
  this.count.update(value => value + 1);
}

When the signal changes, Angular receives a precise notification that the state has been updated.

This allows Angular to react to specific state changes instead of relying solely on global asynchronous activity.

What Signals do not do

A common misconception is that signals replace Angular change detection.

They do not.

Signals provide:

Reactive state
Dependency tracking
Change notifications
Reactive relationships between values

Angular still performs change detection. Signals simply help Angular understand more precisely when updates are required.

Signals vs. RxJS

Another common question is:

Should signals replace RxJS?

Usually, no.

The two technologies solve different problems.

Signals are ideal for

Component state
Local reactive data
Derived UI state
Fine-grained updates

RxJS is ideal for

Event streams
WebSocket communication
Stream transformations
Complex asynchronous workflows
Service orchestration

In modern Angular applications, they frequently work together.

A common approach is:

RxJS manages asynchronous workflows.
Signals manage UI state.

How Zoneless Change Detection works

The core idea behind zoneless Angular is straightforward.

Instead of monitoring broad asynchronous activity, Angular reacts to recognized update notifications.

Traditional model:

                       Async activity

                            ↓

                  Zone.js tracks activity

                            ↓

                   Angular is notified

                            ↓

                  Change detection runs

Zoneless model:

                  Angular notification

                           ↓

                Angular schedules updates

                          ↓

                 Relevant views refresh

Angular can receive notifications through mechanisms such as:

Signal updates used by templates
Template and host event handlers
AsyncPipe emissions
ComponentRef.setInput()
ChangeDetectorRef.markForCheck()

Angular still schedules and batches updates efficiently. The difference is that updates are driven by explicit application state changes rather than broad asynchronous interception.

How to enable Zoneless Change Detection

Angular 20 applications can enable zoneless mode using.

JavaScript

provideZonelessChangeDetection():
import { bootstrapApplication } from '@angular/platform-browser';
import { provideZonelessChangeDetection } from '@angular/core';

bootstrapApplication(AppComponent, {
  providers: [
    provideZonelessChangeDetection()
  ]
});

Angular 21 applications use zoneless change detection by default.

If an application requires traditional Zone.js behavior, Angular also provides an explicit opt-in:

provideZoneChangeDetection()

Why Zoneless Change Detection can be more efficient

Under the traditional model, Angular often performed change detection because something might have changed.

With zoneless change detection, Angular updates when it receives a recognized notification.

Potential benefits include:

Reduced unnecessary work
More predictable rendering behavior
Easier debugging
Better performance tuning visibility

However, these improvements are not guaranteed.

Actual results depend on factors such as:

Application architecture
Component count
Update frequency
Signals adoption
Existing change-detection patterns

The best approach is to benchmark before and after migration rather than expecting universal gains.

Where Zoneless Angular has the biggest impact

Small applications may show little difference.

The biggest benefits often appear in applications with:

Real-time dashboards
Data-heavy interfaces
Collaborative systems
Frequent asynchronous updates
External integrations

These environments generate many state changes, making explicit update mechanisms more valuable.

Working with external integrations

Third-party integrations are often where zoneless behavior becomes most noticeable.

Consider:

JavaScript

readonly unread = signal(0);

vendorApi.onUnreadCountChanged(count => {
   this.unread.set(count);
});

The external callback itself is not important.

What matters is that Angular learns about the state change through a supported mechanism. Since the template consumes the signal, Angular can schedule the required UI update.

This represents a key mindset shift: State changes should be communicated through Angular-aware reactive mechanisms.

Template Bindings and Change Detection APIs

Many existing applications use APIs such as:

NgZone.run()
markForCheck()
detectChanges()

These APIs remain useful.

In zoneless applications:

markForCheck() remains a supported notification mechanism.
detectChanges() performs an immediate local check.
Existing NgZone.run() calls do not have to be removed simply because an application adopts zoneless mode.

Signals often reduce the need for manual notifications, but Angular’s existing APIs remain fully relevant.

Read the full blog post on the Syncfusion Website

Set Up Syncfusion for Your AI Coding Agent with One Prompt

Lucy Muturi — Thu, 10 Sep 2026 12:06:40 +0000

TL;DR: Give your AI coding agent one Syncfusion setup prompt before it starts coding. The onboarding flow detects your project platform, installs the appropriate Syncfusion skill pack, checks licensing requirements, and optionally connects your agent to current Syncfusion documentation through MCP.

No Syncfusion account or product license is required to install or explore Syncfusion Agent Skills.

AI coding agents such as Claude Code, Cursor, GitHub Copilot, and Windsurf can generate application code quickly. They can create components, configure projects, and implement features from a simple description.

But while your AI coding agent knows how to code, does it know your Syncfusion setup?

When working with Syncfusion, the agent also needs product-specific context: which platform the project uses, which packages and components apply, what APIs and configuration are relevant, and where to find current Syncfusion guidance.

Without that context, you may spend time correcting package choices, outdated API suggestions, missing configuration, or implementation based on assumptions.

Syncfusion Onboarding Skill for AI Coding Agent gives your agent that context before it starts coding — beginning with a single prompt.

One prompt to get started

Start by giving your AI coding agent this prompt:

Set up this project for Syncfusion before generating code. Fetch and follow the official instructions at https://ai.syncfusion.com, then report the detected platform, installed skill pack, MCP status, and any required licensing action.

The prompt directs your agent to the official Syncfusion onboarding instructions and gives it a consistent starting point for the project.

From there, the agent:

Detects your project platform from its files and structure.
Installs the appropriate Syncfusion skill pack for the detected platform.
Checks MCP and licensing requirements and identifies any action needed.
Reports the setup status, including the detected platform, installed skill pack, MCP status, and licensing action.

Once the setup is complete, you can start asking the agent to build with Syncfusion.

Example: Setting up Syncfusion in a React project

Imagine you’re building a React application and want to add a Syncfusion DataGrid. Before asking your AI coding agent to implement the grid, give it the Syncfusion setup prompt.

The agent first analyzes the project and completes the onboarding. An illustrative result might look like this:

Detected platform: React
Installed skill pack: React
MCP status: Not configured
Licensing action: Reported based on the project's licensing status

The agent can then use the React-specific Syncfusion skill pack when working on the DataGrid instead of relying only on its existing model knowledge.

Now you can give it a development request such as:

Build a React admin portal with a Syncfusion DataGrid that supports CRUD operations, filtering, sorting, paging, and Excel export.

The installed skill pack gives the agent Syncfusion-specific guidance for implementing the requested functionality.

Give the agent Syncfusion context first. Then ask it to build.

Why give your AI agent Syncfusion context?

Start with the right Syncfusion setup

You don’t need to determine the appropriate Syncfusion skill pack every time you start a project.

The onboarding flow examines the project, identifies the platform, and installs the relevant skill pack. This provides a consistent starting point, especially when moving between different Syncfusion technologies or working across multiple projects.

Give the agent product-specific guidance

AI coding agents can rely on pretrained knowledge that may not always reflect the latest product-specific setup or API usage.

Syncfusion Agent Skills provide structured guidance covering relevant components, packages, setup requirements, implementation patterns, and known limitations. This gives the agent more relevant Syncfusion context to work with instead of relying solely on its existing model knowledge.

Generated code should still be reviewed and tested, but giving the agent official product-specific guidance can reduce incorrect assumptions and unnecessary rework.

Surface licensing requirements early

Licensing shouldn’t become an afterthought after development is already underway. The onboarding flow checks whether any licensing action is required and reports it as part of the setup.

You can install and explore Syncfusion Agent Skills without a Syncfusion account, product license, license key, or MCP key. Standard Syncfusion product licensing still applies when Syncfusion components are used in an application.

This separation allows the agent to complete its Syncfusion setup without requiring it to handle product license credentials during Agent Skill installation.

Agent Skills and MCP: What does each one do?

Syncfusion onboarding does not require MCP.

Agent Skills and MCP serve different purposes in the AI development process:

Agent Skills provide implementation guidance. They help your AI coding agent understand how to work with Syncfusion components, packages, APIs, configuration, and implementation patterns.
MCP provides access to current documentation. When an MCP server is available and configured, the agent can retrieve current Syncfusion documentation and API information when it needs additional context.

Capability	Standard onboarding	With MCP
Platform detection	Yes	Yes
Syncfusion skill-pack installation	Yes	Yes
Syncfusion setup guidance	Yes	Yes
Licensing guidance	Yes	Yes
Access to current documentation through MCP	No	Yes

MCP is therefore optional. You can complete the onboarding and use Syncfusion Agent Skills without it, while MCP can provide additional access to current documentation during development.

Read the full blog post on the Syncfusion Website

Introducing the Fifth Set of Open-Source Syncfusion .NET MAUI Controls

Lucy Muturi — Tue, 08 Sep 2026 14:17:19 +0000

TL;DR: The Syncfusion Toolkit for .NET MAUI continues to grow with its fifth open-source release, introducing the Grid Splitter and the Interactive Viewer to build resizable layouts and rich content-viewing experiences. The release also includes performance improvements, stability enhancements, and bug fixes to help developers create more responsive and maintainable cross-platform applications.

Since launching the Syncfusion^® Toolkit for .NET MAUI, we’ve continued expanding the collection with new controls driven by common developer needs. Today, we’re excited to introduce the fifth set of open-source controls for .NET MAUI, adding Grid Splitter and Interactive Viewer to the Toolkit.

This release also includes quality improvements, performance enhancements, and bug fixes across existing controls.

Grid Splitter

Many desktop-style applications need resizable layouts that let users adjust the space allocated to different content areas. Whether you’re building a file explorer, dashboard, editor, or management application, users often expect to resize panels based on their workflow.

The new .NET MAUI Grid Splitter makes this easy by allowing users to resize, expand, and collapse adjacent layout regions using touch, mouse, or pointer interactions.

Key features

Resize neighboring panes with simple drag interactions.
Expand or collapse panels using built-in controls.
Support both horizontal and vertical layouts.
Set minimum and maximum pane sizes to maintain consistent layouts.
Add, remove, collapse, or expand panes programmatically at runtime.
Customize separator size, color, icons, and templates to match your application’s design.

The following image shows the Grid Splitter in action.

.NET MAUI Grid Splitter in action

Interactive Viewer

Displaying large images, diagrams, maps, or technical drawings often requires more than a standard image control can provide. Users need a smooth way to zoom in, move around, and inspect details without sacrificing usability.

The new .NET MAUI Interactive Viewer provides built-in zooming, panning, and rotation capabilities, making it easier to create rich viewing experiences across both desktop and mobile platforms.

Key features

Smooth zooming and panning for exploring visual content.
Rotate content to view it from different angles.
Quickly return to the original view with a reset option.
Control the viewing experience with configurable minimum and maximum zoom levels.

The following image demonstrates the Interactive Viewer.

.NET MAUI Interactive Viewer

Performance and quality updates

Alongside these new controls, we’ve continued improving the overall Toolkit experience with performance optimizations, stability enhancements, and bug fixes across existing controls.

These updates help ensure a more reliable and consistent experience when building .NET MAUI applications with the Syncfusion Toolkit.

Conclusion

With the addition of Grid Splitter and Interactive Viewer, the Syncfusion Toolkit for .NET MAUI continues to expand its collection of open-source controls for modern application development.

Whether you’re creating resizable workspaces, dashboard-style layouts, image inspection tools, map-based applications, or technical viewers, these controls can help you deliver richer user experiences while reducing the amount of custom code you need to maintain.

Both controls are available through the Syncfusion .NET MAUI Toolkit on NuGet and GitHub, along with documentation and sample projects to help you get started quickly.

If you’re looking for a broader set of enterprise-grade UI components, be sure to explore Essential Studio for .NET MAUI, which includes advanced controls such as DataGrid, ListView, Scheduler, Charts, and more.

We’d love to hear your feedback as we continue to enhance the Toolkit and expand its open-source offerings. If you have any questions, feedback, or need assistance, reach out through our support portal, support forum, or feedback portal where our team will be happy to help.

Happy coding!

Related Blogs

This article was originally published at Syncfusion.com

Why AI Coding Agents Go Off Scope and How Guardrails Fix It

Lucy Muturi — Mon, 07 Sep 2026 13:35:56 +0000

TL;DR: AI coding agents are only as reliable as the context they receive. Learn how context engineering, guardrails, custom agents, prompt files, and reusable skills help development teams reduce unwanted changes, enforce coding standards, and create predictable AI-assisted workflows in Syncfusion Code Studio.

A developer picks up what looks like an easy bug fix.

There’s a null reference error in a component. They open their AI coding assistant, attach the file, and ask for a fix. A few minutes later, the error is gone.

So are several other things.

The assistant renamed functions, reorganized state management, updated a utility method in another file, and introduced changes nobody asked for. The original bug is fixed, but the pull request is now filled with unrelated modifications that need review.

Most developers have experienced some version of this.

The AI didn’t malfunction. It simply worked with the information it was given.

As AI becomes part of everyday development workflows, one challenge keeps surfacing across teams: getting reliable, consistent output from coding assistants. While prompt engineering gets much of the attention, prompt quality is rarely the real issue.

The bigger factor is context.

What the AI can see, what rules it follows, and what actions it’s allowed to take often determine whether the result is helpful or creates more work.

This is where guardrails become essential.

In this article, we’ll look at how Syncfusion^® Code Studio helps teams create predictable AI-assisted workflows through context management, project-wide instructions, custom agents, and reusable skills.

The real reason AI goes off scope

When developers get unexpected output from an AI assistant, the first instinct is usually to improve the prompt.

Write a longer instruction
Add more constraints
Be more specific

Sometimes that helps.

But the same problem often returns during the next session because prompts are temporary. Every developer writes them differently. Every conversation starts from a slightly different place.

The result is inconsistency.

Two developers can ask the same coding assistant to solve the same problem and receive very different solutions, simply because the assistant was given different context.

The issue isn’t usually the model. It’s the environment around the model.

If an AI assistant can see an entire project, it treats that project as available for modification. If important information is missing, it fills gaps with assumptions. The broader the context, the larger the potential surface area for changes.

Reliable AI output starts when you intentionally control that environment. Instead of hoping the AI stays within boundaries, you define those boundaries up front.

Why Context and Guardrails Matter

AI doesn’t go out of scope because it’s careless. It goes out of scope because everything it can see becomes fair game. The broader the context, the greater the chance of unnecessary changes.

This is where context engineering and guardrails make a difference. Instead of relying on prompts alone, you create clear boundaries around what the AI can access, understand, and modify.

Without guardrails:

Code reviews become longer due to unrelated changes.
Team standards are applied inconsistently.
Technical debt accumulates more quickly.
Trust in AI-generated output gradually declines.

With guardrails:

AI works only within the intended scope.
Team conventions are applied consistently.
Output becomes easier to review and maintain.
Developers get more predictable results across projects and workflows.

The goal isn’t to restrict AI. It’s to give it the right context, rules, and boundaries so it can produce reliable results every time.

Control what the AI can see

One of the simplest ways to improve AI output is to reduce unnecessary context. If an assistant only needs three files to solve a problem, giving it thirty files rarely improves the result.

In Syncfusion Code Studio, Add Context allows developers to attach exactly what’s needed for a task:

Files
Folders
Symbols
Problems panel diagnostics
Screenshots
Active tools

Imagine an article feed page displaying a generic “Could not load articles” error.

A common reaction is to provide the assistant with every related file. The AI then interprets the issue as a broader architectural problem and starts suggesting changes across the application.

Instead, attaching only the error details and a screenshot provides the assistant with the information needed to identify the problem while keeping it focused on the task at hand.

The less irrelevant information the model sees, the less opportunity it has to wander outside the requested scope.

For a full breakdown of context types, see the Add Context documentation.

Adding task context in Code Studio

Define team standards once

Even when task scope is controlled, another problem remains. The AI still doesn’t know how your team expects code to be written.

Without shared guidance, every generated solution reflects the model’s assumptions rather than the project’s standards.

Code Studio addresses this through two complementary mechanisms.

Custom Instructions

Custom Instructions allow teams to define coding standards that automatically apply to specific parts of a codebase.

For example:

Front-end conventions can apply only to UI files.
Backend rules can apply only to API projects.
Testing requirements can apply only to test folders.

Developers don’t need to repeat these requirements in every prompt because they’re automatically included when relevant.

Explore the Custom Instructions documentation to learn how to automatically apply coding standards across files, folders, and projects.

AGENTS.md

While Custom Instructions focus on coding standards, AGENTS.md provides broader project knowledge.

Think of it as a handbook written for AI agents.

It can contain:

Architecture decisions
Technology stack guidelines
Setup requirements
Testing workflows
Project conventions
Team expectations

A simple way to think about the difference is:

Custom Instructions explain how code should be written.
AGENTS.md explains how the project works.

Together, they ensure that AI-generated output aligns with the team’s established practices rather than recreating them from scratch in every conversation.

See the Global Agents documentation to understand how project-wide knowledge and AI guidance can be shared consistently across every development workflow.

Control what the AI can do

Knowing the rules is important. Following a defined workflow is even more important.

That’s where Custom Agents come in.

A Custom Agent combines:

A specific role
Instructions
Approved tools
Relevant project context

into a reusable workflow.

Instead of asking a general-purpose AI assistant to perform a task, teams can create purpose-built agents for activities such as:

Bug fixing
Code reviews
Test generation
Security reviews
Documentation generation

Because the role and toolset are predefined, the agent operates within established boundaries.

For example, a bug-fixing agent can be restricted to:

Reviewing attached files
Editing code
Running builds

while avoiding unrelated project-wide actions.

This creates a more predictable workflow regardless of who on the team uses the agent.

For configuration details, see the Custom Agents documentation.

Using a custom agent for scoped bug fixes in Code Studio

Read the full blog post on the Syncfusion Website

Mono vs CoreCLR in .NET MAUI: Performance, Compatibility, and What Changes in .NET 11

Lucy Muturi — Mon, 07 Sep 2026 12:17:51 +0000

TL;DR: Starting with .NET 11 Preview 6, CoreCLR is the only runtime for .NET MAUI apps targeting Android, iOS, tvOS, and Mac Catalyst, replacing the previous Mono runtime path for these affected MAUI mobile targets. This article compares Mono and CoreCLR, explains the key runtime and performance differences, and provides practical guidance for testing your app before upgrading to .NET 11.

Upgrading a .NET MAUI application to .NET 11 is no longer just a framework update. The runtime underneath those applications is changing from the previous Mono-based path to CoreCLR.

This transition can affect startup behavior, memory usage, diagnostics, application size, and third-party library compatibility, even though most applications will not require a source-code rewrite.

This raises important questions for existing MAUI applications:

Is CoreCLR faster than Mono?
Will my application behave differently after upgrading?
Do I need to change my code?
What should I validate before moving to .NET 11?

In this article, we’ll compare Mono and CoreCLR, explore the architectural and performance differences between the two runtimes, examine what changes in .NET 11, and provide a practical migration and validation checklist to help you upgrade with confidence.

Mono vs CoreCLR at a glance

Dimension	Mono	CoreCLR (.NET 11 MAUI)
Execution/compilation model	Platform- and build-dependent, including JIT, interpreter, and AOT configurations	Tiered JIT with Tier 0 → Tier 1 optimization
GC	SGen / platform-specific Mono configuration	CoreCLR generational GC
AOT/deployment model	Mono AOT and, on some platforms/configurations, interpreter or full AOT	CoreCLR JIT-based execution by default; NativeAOT is a separate deployment and execution model where supported
Diagnostics	More limited depending on platform and scenario	Broader .NET diagnostics support on supported mobile scenarios

What is CoreCLR on .NET MAUI?

CoreCLR is the runtime used by .NET across desktop and server workloads, including ASP.NET Core and other .NET applications. For .NET 11 MAUI applications, it is the runtime path for the affected Android, iOS, tvOS, and Mac Catalyst targets.

CoreCLR and NativeAOT should be treated as separate technologies.

CoreCLR executes managed code using its JIT and related compilation technologies.
NativeAOT uses a separate ahead-of-time deployment and execution model and does not run on Mono or CoreCLR at runtime.

Both Mono and CoreCLR execute IL, provide garbage collection and runtime services, and expose the .NET Base Class Library (BCL). However, their execution and compilation architectures differ and those differences matter for mobile workloads where startup time, application size, memory usage, and runtime performance are important.

Architecture differences: Mono vs CoreCLR

1. JIT compilation strategy

Feature	Mono	CoreCLR
Execution/compilation model	Platform- and build-dependent: JIT, interpreter, and AOT configurations	Tiered compilation (Tier 0 → Tier 1)
Dynamic PGO	Mono-specific/runtime-dependent	Profile-guided optimization and runtime-driven optimization
Ahead-of-time compilation	Mono AOT for supported mobile configurations	`ReadyToRun` and `NativeAOT` are separate compilation options
Startup pre-compilation	Mono’s AOT pipeline	`ReadyToRun` (R2R), where enabled
Startup tiering	Not directly comparable as a single Mono mobile mode	Tier 0 → Tier 1 for hot methods

What does this mean for MAUI developers?

CoreCLR’s tiered compilation allows methods to begin with relatively fast Tier 0 compilation and receive more aggressive optimization as they become hot.
Mono’s mobile execution model varies by platform and build configuration, including JIT, interpreter, and AOT-based execution.

Therefore, tiered compilation alone should not be treated as the explanation for startup differences between Mono and CoreCLR.

2. Garbage collection

Feature	Mono	CoreCLR
GC implementation	SGen / platform-specific Mono configuration	CoreCLR generational GC
GC modes	Configuration- and workload-dependent	Configuration- and workload-dependent
Pause times	Workload-dependent	Workload-dependent
Arm64 optimizations	Available	CoreCLR Arm64 optimizations
Runtime configuration	Mono-specific behavior	CoreCLR runtime configuration

Why does GC matter for MAUI?

GC activity can contribute to UI pauses and memory pressure, but it is only one factor affecting rendering performance.

When comparing Mono and CoreCLR, measure:

GC activity
Allocation rate
Memory usage
Frame rendering
Startup time
CPU utilization

This gives you a more complete picture of application performance than GC pause time alone.

3. Threading and concurrency

Both Mono and CoreCLR support the standard .NET threading and asynchronous programming APIs, including Task, async/await, and synchronization primitives.

For most MAUI applications, the practical differences are more likely to appear in runtime behavior, diagnostics, and workload-specific performance than in application-level threading APIs. The more significant change is the diagnostics experience. CoreCLR provides a more consistent .NET diagnostics story across server, desktop, and supported mobile workloads.

4. Diagnostics and tooling

One of the significant benefits of CoreCLR is improved access to the broader .NET diagnostics ecosystem.

Tool	Mono	CoreCLR
dotnet-trace	More limited depending on platform and workflow	Broader support for mobile scenarios
dotnet-counters	More limited depending on platform and workflow	Broader support for mobile scenarios
dotnet-dump	More limited depending on platform and workflow	Scenario-dependent; verify support for the target platform and diagnostic workflow
Hot Reload	Supported with platform-specific limitations	Supported through IDE and dotnet watch workflows

CoreCLR provides a more consistent .NET diagnostics experience for supported mobile scenarios, including tools such as dotnet-trace and dotnet-counters. Availability and workflow can still depend on the target platform and diagnostic scenario.

5. Code generation and optimizations

Beyond the JIT itself, CoreCLR brings several compilation and optimization technologies to MAUI.

ReadyToRun

ReadyToRun can precompile assemblies to reduce the amount of work required at runtime. This can improve startup behavior in supported configurations.
Its applicability and benefit depend on the target platform and publishing configuration, so compare equivalent publishing configurations when benchmarking MAUI applications.

Profile-guided optimization

Profile-guided optimization uses runtime and profile information to optimize frequently executed code paths.

NativeAOT

NativeAOT is available as a separate ahead-of-time deployment and execution model for supported platforms and scenarios. If your application uses NativeAOT, evaluate its trimming, reflection, and native interoperability requirements separately from the standard CoreCLR execution path.

Performance: Mono vs CoreCLR on real devices

The .NET MAUI team has published performance comparisons between Mono and CoreCLR.

iOS and Mac Catalyst

CoreCLR has generally demonstrated:

Faster cold startup
Faster warm startup
Improved execution on PGO-friendly workloads

NativeAOT can provide additional startup and application-size benefits where it is used, but those results should be evaluated separately because NativeAOT represents a different execution model.

Android

The .NET MAUI team reports that, in its baseline measurements, CoreCLR is within 10% of Mono for Android startup and app size.

Android results are more workload-dependent. Some complex applications have reported startup regressions or increases in APK/AAB size, so the reported baseline should not be treated as a guarantee for every .NET MAUI application.

What the community has found

These baseline measurements do not capture every workload. Discussions in the .NET Android repository provide examples of applications where CoreCLR has shown different startup, size, or runtime behavior:

dotnet/android#10588: Startup time and application size increases in complex Android applications.
dotnet/android#10914: Specific scenarios where CoreCLR underperforms Mono.

These issues provide examples for investigation rather than benchmarks that represent all .NET MAUI applications.

Read the full blog post on the Syncfusion Website

How to Choose the Right DataManager Adaptor for React Gantt Chart Backend Integration

Lucy Muturi — Fri, 04 Sep 2026 15:16:45 +0000

TL;DR: Selecting the correct DataManager adaptor is one of the most important decisions when integrating React Gantt Chart with a backend service. Different adaptors support different API patterns, request formats, and response contracts, which can directly affect data loading, CRUD operations, performance, and maintainability. This guide helps you choose the right DataManager adaptor for your backend by explaining when to use built-in adaptors and how to avoid common integration issues.

Integrating a React Gantt Chart with a backend API can seem straightforward until the data loads incorrectly, edits fail to persist, or the component remains empty despite successful HTTP responses. In many cases, the root cause is not the Gantt Chart configuration itself but the DataManager adaptor sitting between the component and your server.

The adaptor determines how requests are generated, how responses are interpreted, and how CRUD operations are sent back to the backend. Choosing the wrong adaptor can lead to subtle issues that are often difficult to diagnose.

This guide explains how each DataManager adaptor works, when to use it, and how to match it to your backend architecture. You’ll learn the differences between UrlAdaptor, WebApiAdaptor, ODataV4Adaptor, GraphQLAdaptor, RemoteSaveAdaptor, and custom adaptors, along with practical examples, expected request and response contracts, and troubleshooting techniques that can save hours of debugging.

Note: All code examples in this article use Syncfusion React Gantt Chart and Syncfusion EJ2 DataManager APIs, and the adaptor behaviors discussed are specific to those implementations.

Why adaptor selection matters

Most remote-binding issues in Syncfusion React Gantt Chart are caused by a mismatch between the selected adaptor and the backend contract.

Common examples:

A team connects a custom REST API with an adaptor meant for a different server pattern. The Gantt Chart loads no tasks because the response shape does not match what DataManager expects.
A team uses an OData v4 service with the wrong OData adaptor. Requests succeed, but the response is not interpreted correctly.
A team gets initial loading to work, but edits fail because the configured CRUD endpoints or payloads do not match the adaptor’s expectations.

The simplest rule is: Choose the adaptor based on your backend protocol and response contract first, then configure the Gantt.

What DataManager does in React Gantt

In a React Gantt Chart application, DataManager acts as the communication layer between the component and your backend. Whenever the Gantt Chart needs data or sends an update, DataManager works with the selected adaptor to translate those operations into requests the server can understand and convert responses back into a format the component can use.

A simplified workflow looks like this:

The Gantt Chart requests data or submits an edit.
DataManager routes the operation through the configured adaptor.
The adaptor builds the appropriate HTTP request.
The server processes the request and returns a response.
The adaptor transforms the response into the structure expected by the Gantt.
The component renders the results or updates the UI.

Three adaptor methods are especially useful when troubleshooting integration issues:

Method	Purpose	Common symptom when misconfigured
processQuery	Builds outgoing requests	Incorrect URLs, missing query parameters, unexpected payloads
processResponse	Parses server responses	Successful requests but no data displayed
beforeSend	Customizes requests before transmission	Authentication, token, or CORS-related failures

Understand the difference between read and CRUD operations

A common mistake is assuming that successful data loading guarantees editing will work as well. In reality, the initial read operation and subsequent CRUD operations follow separate paths.

During the read flow, the Gantt Chart retrieves task data and renders the timeline. During the CRUD flow, DataManager sends insert, update, delete, or batch requests and expects a valid response from the server.

If tasks load successfully but edits fail to persist, the issue is usually related to CRUD endpoints, payload formats, or server-side processing rather than the initial read configuration.

Before choosing an adaptor

Before selecting an adaptor, document the backend contract first.

Make sure you understand:

The read endpoint URL
The insert, update, delete, or batch endpoints
The expected request payload format
The expected response format
The authentication mechanism
The primary key field
The hierarchy field, such as ParentID
Whether sorting, filtering, and paging occur on the client or server

Having these details upfront makes adaptor selection much easier and helps prevent the most common remote-binding issues later in the project.

A quick adaptor selection framework

Start with the backend you already have.
Use ODataV4Adaptor when your service is an OData v4 endpoint that follows OData conventions for querying and responses.
Use GraphQLAdaptor when your application communicates through GraphQL queries and mutations.
Use WebApiAdaptor when your backend follows ASP.NET Web API patterns that align with Syncfusion’s documented DataManager expectations.
Use RemoteSaveAdaptor when the dataset is small enough to load into browser memory, and you want sorting, filtering, and searching to occur locally after the initial load.
Use UrlAdaptor when you’re working with a custom REST API and need flexible remote communication without OData or GraphQL conventions.
Choose a custom adaptor only when a built-in adaptor almost fits your requirements, but additional request or response customization is necessary.

Expected Request and Response Contracts by Adaptor

One of the fastest ways to identify integration issues is comparing the actual network response with the contract expected by the selected adaptor.

Adaptor	Typical read response shape	Typical save pattern	Verify first
UrlAdaptor	`{ result: [...], count: n }` for remote operations	CRUD or batch endpoints you define	Whether the server returns result and count when required
WebApiAdaptor	DataManager-compatible result structure	REST-style endpoints matching adaptor expectations	Whether server-side query handling matches DataManager conventions
ODataV4Adaptor	`{ "@odata.count": n, "value": [...] }`	OData-style service behavior	Whether the endpoint is truly OData v4
GraphQLAdaptor	Configured nested paths such as `getTasks.result`	GraphQL mutations	Whether result and count map to real response paths
RemoteSaveAdaptor	Initial read payload, then local operations	Remote save on add, edit, delete, or batch	Whether client-side interaction fits the dataset size
Custom adaptor	Depends on your transformation	Customizable	Whether a built-in adaptor would be enough

Before modifying task mappings, editing settings, or component configuration, verify that the request and response format aligns with the adaptor being used.

If the contract does not match, the Gantt Chart may fail to render data correctly even when requests return successful HTTP responses.

The following examples show what those contracts look like in practice.

UrlAdaptor read response

JSON

{
  "result": [
    {
      "TaskID": 1,
      "TaskName": "Project initiation",
      "StartDate": "2026-08-01T00:00:00Z",
      "EndDate": "2026-08-05T00:00:00Z",
      "Duration": 5,
      "Progress": 40,
      "ParentID": null
    }
  ],
  "count": 1
}

OData v4 read response

JSON

{
  "@odata.context": "https://localhost:xxxx/odata/$metadata#Tasks",
  "@odata.count": 1,
  "value": [
    {
      "TaskID": 1,
      "TaskName": "Project initiation",
      "StartDate": "2026-08-01T00:00:00Z",
      "EndDate": "2026-08-05T00:00:00Z",
      "Duration": 5,
      "Progress": 40,
      "ParentID": null
    }
  ]
}

GraphQL response mapping

JSON

{
  "data": {
    "getTasks": {
      "count": 1,
      "result": [
        {
          "TaskID": 1,
          "TaskName": "Project initiation",
          "StartDate": "2026-08-01T00:00:00Z"
        }
      ]
    }
  }
}

If the response does not closely match the adaptor contract, fix the mismatch before changing the Gantt Chart configuration.

Adaptor comparison matrix

Adaptor	Best for	Main caution
UrlAdaptor	Custom REST APIs	Requires a clear server contract
WebApiAdaptor	ASP.NET Web API patterns	Not a generic adaptor for arbitrary APIs
ODataV4Adaptor	OData v4 services	Must match actual OData v4 behavior
GraphQLAdaptor	GraphQL backends	Response path mapping must be exact
RemoteSaveAdaptor	Small datasets with fast local interaction	Can become stale in multi-user apps
Custom adaptor	Edge cases	Easy to overuse

UrlAdaptor for custom REST APIs

Use UrlAdaptor when your backend is a custom REST API and does not expose OData or GraphQL conventions. This is often the best fit for Node.js, Python, Java, Go, or ASP.NET Core APIs where you own the contract.

Why it is useful

UrlAdaptor gives you flexibility. You define the API shape, and DataManager handles the remote request-response flow. For Gantt Chart projects, it is often the most practical choice when you need custom business rules, validation, or batch updates.

The following example configures a React Gantt Chart component to load and update task data through a custom REST API.

JavaScript

import { DataManager, UrlAdaptor } from '@syncfusion/ej2-data';
import { GanttComponent, Inject, Edit, Toolbar } from '@syncfusion/ej2-react-gantt';

const dataManager = new DataManager({
  url: 'https://localhost:xxxx/api/tasks',
  batchUrl: 'https://localhost:xxxx/api/tasks/batch',
  adaptor: new UrlAdaptor(),
  crossDomain: true
});

const taskFields = {
  id: 'TaskID',
  name: 'TaskName',
  startDate: 'StartDate',
  endDate: 'EndDate',
  duration: 'Duration',
  progress: 'Progress',
  parentID: 'ParentID'
};

const editSettings = {
  allowEditing: true,
  allowAdding: true,
  allowDeleting: true,
  mode: 'Auto'
};

<GanttComponent dataSource={dataManager} taskFields={taskFields} editSettings={editSettings}>
  <Inject services={[Edit, Toolbar]} />
</GanttComponent>

Common issues

Symptom	Likely cause	Fix
Gantt Chart shows no records	Response shape does not match expected format	Return result and count when required
Edits do not persist	batchUrl or CRUD mapping is incomplete	Implement and test the batch or CRUD endpoints
Dates render incorrectly	Date format is inconsistent	Return ISO-style dates
Hierarchy is broken	Parent-child mapping is incomplete	Verify parentID mapping and root handling

WebApiAdaptor for ASP.NET Web API patterns

Use WebApiAdaptor when your backend follows ASP.NET Web API patterns that support DataManager or OData-style query conventions. It is not a generic adaptor for arbitrary REST APIs.

Example server pattern

public IActionResult Get([FromQuery] DataManagerRequest request)
{
    var tasks = _repository.GetAllTasks();
    return Ok(new DataResult
    {
        Result = tasks,
        Count = tasks.Count
    });
}

Note: DataManagerRequest and DataResult come from Syncfusion.EJ2.Base namespace. Add the corresponding NuGet package and using directive before compiling this example.

React configuration

JavaScript

import { DataManager, WebApiAdaptor } from '@syncfusion/ej2-data';

const dataManager = new DataManager({
  url: 'https://localhost:xxxx/api/tasks',
  adaptor: new WebApiAdaptor(),
  crossDomain: true
});

Common issues

Response shape does not match what DataManager expects
Server does not process query parameters for sorting, filtering, or paging
CRUD routes do not match expected controller patterns

If your API is just a custom REST API, UrlAdaptor is usually the safer starting point.

Note: The exact request and response contract may vary based on your Syncfusion version and Web API implementation. Always verify expected payload formats against the documentation for the version you deploy.

Read the full blog post on the Syncfusion Website

Tired of Fragile AI Integrations? Learn MCP Before Your Next Project

Lucy Muturi — Wed, 02 Sep 2026 11:04:45 +0000

TL;DR: Your AI application works today, but what happens when it needs to connect with more tools, data sources, and business systems? Model Context Protocol (MCP) provides a consistent way for AI applications to interact with external resources. The MCP Handbook explains the concepts, architecture, and implementation patterns needed to build AI solutions that remain maintainable as they grow.

Building an AI prototype has never been easier. Modern AI models can quickly power chatbots, assistants, and workflow automation. The challenge begins when those applications need to access multiple systems, retrieve information from different sources, and perform actions across business tools. Without a consistent integration approach, complexity grows rapidly.

Model Context Protocol (MCP) addresses this challenge by providing a standard interface between AI applications and external systems. To help developers apply these concepts in real-world projects, we’ve created the MCP Handbook, a practical guide focused on architecture, implementation patterns, and production-ready practices.

How Model Context Protocol fits into modern AI development

As AI development evolves, concepts such as prompts, context, RAG, agent skills, and MCP are often discussed together. While they work together, each serves a different purpose:

Term	Purpose
Prompt	Defines what the AI should do
Context	Provides information needed to complete the task
RAG	Retrieves relevant knowledge before generating a response
Agent Skills	Provides reusable instructions and capabilities for specific tasks
MCP	Provides a consistent way for AI applications to interact with external tools and resources

A simple way to remember:

Prompts define the task
Context provides the information
RAG retrieves knowledge
Agent Skills perform specialized actions
MCP connects AI applications with external capabilities.

Understanding how these pieces work together helps teams build AI systems that extend beyond basic chat experiences.

How Model Context Protocol works

At a high level, MCP acts as a bridge between AI applications and external systems. Instead of creating separate integrations for every API, database, documentation source, or business application, developers expose capabilities through MCP servers. AI clients can then discover and use those capabilities through a common interface.

A typical interaction looks like this:

A user sends a request.
The AI determines whether additional information or actions are required.
The MCP client identifies available tools, resources, or prompts.
The MCP server provides the requested capability.
Data is retrieved, or an action is executed.
Results are returned to the AI application.
The AI generates a response using that information.

This approach simplifies integration management and promotes reuse across multiple AI applications.

Why MCP matters

Consider an AI assistant that needs to access customer data, search documentation, generate reports, create support tickets, and send notifications.

For a proof of concept, separate integrations may be sufficient. As additional AI applications are introduced, maintaining those integrations becomes increasingly difficult. MCP solves this problem by enabling teams to expose reusable capabilities via MCP servers, which can be shared across multiple AI solutions.

The result is:

Simpler architecture
Easier maintenance
Greater reusability
More flexibility as requirements evolve

This makes MCP especially valuable for organizations building multiple AI-powered applications.

Read the full blog post on the Syncfusion Website

DEV Community: Syncfusion, Inc.

Sneak Peek: 4 New Libraries Coming to Syncfusion Document SDK 2026 Volume 3

JavaScript DOCX Library: Create Word documents directly in JavaScript

Why developers should consider this library

Create a DOCX document programmatically

JavaScript XLSX Library: Automate excel reports and spreadsheet generation

Why developers will find it useful

Create an XLSX workbook in code

JavaScript PPTX Library: Create and edit PowerPoint presentations programmatically

Why it’s worth exploring

Generate PowerPoint presentations dynamically

.NET Document Chunking Library: Prepare enterprise documents for RAG and AI applications

Headroom vs Caveman: A Practical Guide to Reducing AI Coding Costs

Why AI coding costs rise so quickly

Headroom vs Caveman at a glance

Headroom: Reduce what the model reads

Caveman: Reduce what the model writes

A real Syncfusion Code Studio example

Setting up both tools in Syncfusion Code Studio

Installing Headroom in Code Studio

Enable Headroom in the Tools tab

Installing Caveman in Code Studio

Activate Caveman at the start of a session

Motion vs GSAP in React: Which Animation Library Should You Choose?

Motion and GSAP at a glance

Why animation feels different in React

Motion: built for React components

GSAP: animation-first, DOM-oriented, extremely flexible

React animation examples in Motion and GSAP

Example 1: Exit animation before unmount

Motion

GSAP:

Example 2: Hover and Tap Interactions

Motion

GSAP:

Build Modern .NET MAUI Apps with .NET 11 [Webinar Show Notes]

Time stamps

Moving .NET MAUI to CoreCLR

ReadyToRun

Native AOT

Improving the XAML development experience

XAML incremental Hot Reload

Building better native experiences

Long-press gestures

SwipeView styling

Using the Syncfusion .NET MAUI Toolkit

Grid Splitter

Interactive Viewer

Chart tooltips

Designing responsive cross-platform applications

Navigation improvements

Tab badges

Shell route templates

Making maps easier to use

Adding passwordless authentication with passkeys

Supporting modern Android experiences with Material 3

Light and dark splash screen themes

Expanded .NET CLI and testing support

Using AI to improve the development workflow

Evaluating application size and performance

Getting started with .NET MAUI 11

Related links

Related Blogs

Multi-Agent AI Systems: A Smarter Way to Detect and Manage Technical Debt

What is a multi-agent AI system?

When does a multi-agent approach make sense?

Why single-agent approaches can struggle with complex repositories

Single-agent vs. Multi-agent approaches

Multi-agent architectures in practice

Specialized AI auditors for code governance

1. Architecture auditor

2. Security auditor

3. Performance auditor

4. Testing auditor

5. Code quality and maintainability auditor

Real-world example: Auditing a large SaaS repository

From findings to action

Refactoring and planning

Implementation support

Running your first multi-agent audit in Code Studio