Lexical review: Meta's editor framework, and what it asks of you

What Lexical is, and who it is for

Lexical is a text editor framework built by Meta for the editing surfaces inside its own products, and its design shows exactly that origin: an immutable editor state, transactional updates, a strict reconciliation model, and no opinion whatsoever about what an editor should look like.

It suits teams whose editor is a serious, long-lived part of their product and who care about behaviour on very large documents. It does not suit a team that needs a rich-text field working this sprint, because it asks for more assembly than anything else in this dataset before an editor exists on screen.

Like Tiptap, Plate and Editor.js, it is a document editor. It has no canvas, no layout model and no styling for end users, so it is not an alternative to GrapesJS or Puck regardless of how the category is described.

A note on its first release date

Our dataset records Lexical's first release as January 2022, not the 2014 date the npm registry reports as the package's creation. The name lexical was used by an unrelated package that published 0.0.1 in June 2014 and 0.0.2 three days later; Meta's Lexical begins at 0.1.0 on 10 January 2022, which matches the first publish of @lexical/react.

We mention it because it is a clean illustration of our methodology: reading a registry field is verification only if you also read what the field means. A comparison site that scraped time.created would tell you Lexical is a decade older than it is.

Architecture: state first, everything else after

The editor state is immutable and every change is a transaction. Updates run inside editor.update(), node transforms normalise the document, and listeners observe changes. Nothing mutates in place, which is what makes the model predictable under collaboration and undo.

Plugins are React components that register commands, listeners and nodes against the composer. That is why the minimal application is longer than Tiptap's: a usable editor needs the composer, a rich text plugin, a content-editable element, an error boundary and a history plugin, all wired explicitly. Nothing is bundled for you, and nothing is hidden from you.

The trade is stated honestly by the project itself: it is a framework for building editors, not an editor.

Getting started

From our benchmark, unedited. Twenty-five lines — the most of the eight applications we measured, and every line is doing something the other frameworks decided for you.

import { createRoot } from 'react-dom/client';
import { LexicalComposer } from '@lexical/react/LexicalComposer';
import { RichTextPlugin } from '@lexical/react/LexicalRichTextPlugin';
import { ContentEditable } from '@lexical/react/LexicalContentEditable';
import { LexicalErrorBoundary } from '@lexical/react/LexicalErrorBoundary';
import { HistoryPlugin } from '@lexical/react/LexicalHistoryPlugin';

const config = {
  namespace: 'benchmark',
  onError(error) {
    throw error;
  },
};

function App() {
  return (
    <LexicalComposer initialConfig={config}>
      <RichTextPlugin
        contentEditable={<ContentEditable style={{ padding: 16, minHeight: 200 }} />}
        placeholder={<div>Hello editor</div>}
        ErrorBoundary={LexicalErrorBoundary}
      />
      <HistoryPlugin />
    </LexicalComposer>
  );
}

createRoot(document.getElementById('app')).render(<App />);

Median 159 ms to a rendered editor, marginally faster than Tiptap at 171 ms. Within this group those numbers are noise; the twenty-five lines against eleven are not.

Strengths

A genuinely well-designed state model. Immutable, transactional, and easy to reason about. Teams who have fought a mutable editor model will recognise immediately why this matters.

Small core, strong performance. 104.9 kB gzip with the rich-text and history plugins, and the architecture is built for large documents rather than demos.

Production credibility. Meta runs it at a scale nobody else in this category can claim, which is a meaningful signal for a dependency you intend to keep for years.

MIT, with no commercial tier. Nothing is gated behind a paid plan — a real difference from Tiptap, where collaboration and AI are products.

Deliberately unopinionated. If your editing surface is unusual — not a document, not a page — this is the framework least likely to fight you.

Limitations

The most assembly required in this dataset. Twenty-five lines for an editor with no toolbar. Everything visible is yours to build, and the gap between "it renders" and "a person would use this" is wide.

Pre-1.0 API. Version 0.50.0 at the time of writing. The project is stable in practice and the version line still signals that public API changes are permitted.

Documentation has a middle gap. Concepts are explained well and the playground is a real reference implementation, but recipes for the features every product needs — mentions, uploads, toolbars — usually mean reading playground source rather than a guide.

Smaller third-party ecosystem than Tiptap's, and packages break more often against a moving pre-1.0 core.

Not a page builder, and not a rich-text drop-in either: budget for the interface work before comparing it with anything that ships one.

Pricing

Free under MIT, no paid tier, no hosted service. The cost is entirely engineering time, and for this framework that cost is higher than for its neighbours — which is the trade you are making for the state model and the performance.

See Tiptap vs Lexical for the direct comparison, and Editor.js vs Lexical if the requirement is structured blocks rather than free-form rich text.