Craft.js review: build your own React page editor

What Craft.js is, and who it is for

Craft.js is the most honest library in this dataset about what it does not do. It gives you a node tree, drag-and-drop behaviour, selection state and serialisation. It gives you no panels, no toolbar, no settings sidebar, no layer tree UI and no blocks. Those are your components, written by you, using Craft.js hooks.

That sounds like a disadvantage until you have shipped a product where the editor is embedded in an application with a strong visual identity. Every other option in this category either imposes an interface you must override, or hands you a hosted UI you cannot change. Craft.js starts from nothing, which means there is nothing to fight.

It is the right choice when the editing experience is a differentiator, when the editor is narrow and opinionated — a form builder, a dashboard composer, an email layout tool constrained to your templates — and when you have the engineering time. It is the wrong choice on a deadline.

Architecture: a tree, and hooks into it

The model is small enough to describe completely. Everything on the canvas is a node. A node has a type (one of your React components), props, and a place in the tree. Two hooks connect your components to it: useNode gives a component access to its own node — its props, its connectors, whether it is selected — and useEditor gives any component access to the editor as a whole.

Connectors are the clever part. connect marks a DOM element as the node's rendered output; drag marks it as a drag handle. A component becomes draggable and selectable by attaching a ref. Rules on a node type control what may be dropped into it, which is how you enforce structure.

State serialises to JSON that you store. Because the node types are your components, the stored document has the same portability characteristics as Puck's: it means everything inside your app and nothing outside it.

Getting started

From our benchmark, and note how much of it is defining components rather than configuring an editor — that ratio is the library's defining feature.

import { createRoot } from 'react-dom/client';
import { Editor, Frame, Element, useNode } from '@craftjs/core';

function Heading({ text }) {
  const { connectors: { connect, drag } } = useNode();
  return <h1 ref={(ref) => connect(drag(ref))}>{text}</h1>;
}
Heading.craft = { displayName: 'Heading' };

function Container({ children }) {
  const { connectors: { connect } } = useNode();
  return <div ref={(ref) => connect(ref)} style={{ padding: 16 }}>{children}</div>;
}
Container.craft = { displayName: 'Container' };

createRoot(document.getElementById('app')).render(
  <Editor resolver={{ Heading, Container }}>
    <Frame>
      <Element is={Container} canvas>
        <Heading text="Hello editor" />
      </Element>
    </Frame>
  </Editor>,
);

It reached a rendered editor in a median of 94 ms, second fastest in our benchmark, for the obvious reason: it renders almost nothing. Comparing that number with GrapesJS's 309 ms without noting what each library put on screen would be meaningless, which is why the benchmark page shows the screenshots next to the timings.

Strengths

Your editor looks like your product. No panels to restyle, no CSS specificity war with a vendor's stylesheet, no compromise between the editor's design language and yours.

The lightest option by a wide margin. 29.2 kB gzip against Puck's 90.4 kB and GrapesJS's 294.6 kB. If you were going to build custom UI anyway, you are not paying for UI you throw away.

A very small API. Two hooks and a rules object. You can read the surface in an afternoon, and there is little hidden behaviour to discover at 2am.

Drag-and-drop is genuinely hard, and this part is done. Nested drop targets, indicators, hit testing and the tree operations underneath them are the part most teams underestimate when they consider writing an editor from scratch. This is exactly the part Craft.js gives you.

Nothing is hosted. MIT licensed, no service, no account, no vendor.

Limitations

You are building an editor. Toolbars, settings panels, a layers view, block palettes and undo/redo UI are all yours. Our build-versus-buy calculator defaults to 120 hours for editor UI alone, and with Craft.js none of that is optional.

A quiet upstream. Releases are infrequent. For a library this small and stable that is survivable, but assume you may end up maintaining a fork, and price that in.

Almost no ecosystem. No plugin marketplace, few third-party integrations, and the examples you find online are usually one-off demos rather than maintained packages.

No styling system. Like Puck, users change props, not CSS — except here you also build the controls that change them.

Documentation stops where products start. The tutorial is good and takes you to a working editor. Questions about SSR, very large trees, and migrating stored state between component versions are answered in GitHub issues rather than documentation.

Pricing

Free, MIT licensed, no service and no ceiling. The cost is entirely engineering time, and it is the highest in this dataset for a customer-facing editor. That is a rational trade when the editing experience differentiates your product, and a poor one when it does not — which is the question the build-versus-buy page exists to make explicit before you commit a quarter to it.