Slate: a schema-less rich text editor framework for React

The problem Slate targets: editors whose schema you cannot change

The README opens with a list of complaints the author had with Draft.js, ProseMirror and Quill. The first is that the editor's schema was hardcoded and hard to customize: bold and italic worked, but comments, embeds or domain-specific blocks did not. The second is that programmatic document transforms were convoluted, which matters when you need to change content from code rather than from a keystroke. The rest of the list covers serialization to HTML or Markdown being an afterthought, a custom view layer that forces you to learn a new system, collaborative editing not being designed for in advance, monolithic repositories, and flat document models that make tables or captions hard.

Slate is aimed at the developer who has hit that wall. It is not a finished editor product. It is a framework for assembling one, and the README frames the target as editors like Medium, Dropbox Paper or Google Docs. If your requirement is a comment box with bold and links, the framework is heavier than the problem.

How Slate works: a nested document model, commands and first-class plugins

The README describes six principles. The core logic assumes very little about the schema of the data you are editing, so nothing in the library trips you up when you go past the basic cases. The document model is a nested, recursive tree, like the DOM, which is what makes tables and nested block quotes possible while still allowing a single level of hierarchy for simple content. Selections and ranges follow the DOM, and the standard event handlers are exposed, so the README claims that pretty much anything you can do in the DOM you can do in Slate.

Editing happens through commands, which the README describes as high-level and intended to read and write intuitively, so custom behavior stays expressive. The most important claim is that plugins are first-class entities, meaning the editing experience is customized through plugins rather than by working around the library's assumptions. The data model, specifically how operations are applied to the document, was designed to allow collaborative editing.

The repository layout supports this picture: packages/ holds the workspaces, config/ holds the rollup build configuration, site/ is a Next.js site, and playwright/ holds browser tests. The root package.json is private and declares workspaces under packages/*, so slate and slate-react are published from this monorepo rather than from separate repositories.

Installing Slate and wiring up a first editor

The README points to the documentation at docs.slatejs.org and a demo at slatejs.org rather than printing install steps. The package names are visible in the repository: the core package is slate and the React bindings are slate-react, and the most recent releases listed are [email protected] and [email protected]. Add both to a React project with your package manager of choice.

If you work inside this repository instead of consuming the packages, the root package.json defines the scripts. yarn start runs the watch and serve tasks in parallel, and the serve script changes into site/ and runs Next.js, which is what serves the local demo. The open script in package.json is `open http://localhost:3000`, which confirms the port the site is served on.

yarn install
yarn start

The build path is separate. yarn build runs the rollup build and then the Next.js build, and yarn test runs the mocha and jest suites.

yarn build
yarn test

For a first real use, the README's own framing is the guide: define a document as a nested tree, render it with the React bindings, and add behavior as plugins and commands rather than editing a hardcoded schema. The documentation site is where the concrete initial-value shape and editor component setup live; the README does not inline them.

The beta notice and the contributor-driven maintenance model

The README carries a blockquote that begins "Slate is currently in beta." It states that the core API is usable now, that advanced use cases may require you to submit pull requests for improvements, and that some bugs may need fixes you write. It also states that some APIs are not finalized and will have breaking changes over time, and that there is no 1.0 release schedule.

A second blockquote says Slate is contributor-driven and not backed by a huge company, so contributions are voluntary and done by the people who need them. The README's advice is blunt: if you need something improved, added or fixed, contribute it yourself or no one will. The Slack channel is named as the place to say you want to become a more active maintainer.

The repository is not archived, and the last push was on 2026-09-03, with releases in August 2026, so work is happening. That does not contradict the README. The project ships, but the API contract is explicitly unsettled, and the maintenance capacity is the people who use it. Plan for upgrade work, not for a vendor relationship.

Where Slate is the wrong tool

Slate is the wrong choice when you want an editor, not a framework. There is no bundled toolbar, no default schema of marks and blocks to inherit, and no promise that the API you write against today survives the next minor release. The README says breaking changes are expected as better solutions are found. For a product where editing is a side feature, that is an expensive dependency.

The second failure mode is support. Because the project is contributor-driven, a bug that affects only your domain-specific block may sit until you fix it. The README does not document a support contract, a roadmap or a deprecation policy, so you cannot plan upgrades around published guarantees. If your team cannot read and patch a TypeScript editor library, the beta warning is a real constraint rather than boilerplate.

The third is scope. If your content is plain paragraphs and links, the nested document model and the command layer are machinery you will pay for and not use. The README's own framing is Medium, Dropbox Paper and Google Docs, not a comment field.

Slate compared with ProseMirror and Draft.js

The README names the alternatives directly: Draft.js, ProseMirror and Quill, and says Slate was inspired by them. The stated difference is where the schema lives. With ProseMirror, the schema is a defined part of the model, so the document structure is declared and the editor enforces it; Slate's core assumes very little about the schema, which pushes that responsibility to your plugins. That trade is the whole argument: you get freedom from baked-in assumptions, and you take on the work of defining and enforcing structure yourself.

The second difference is the view layer. The README criticizes editors that roll their own views instead of using existing technology like React, and Slate is built on React. If your application is already React, you keep one rendering model instead of learning a second one. If it is not, that advantage disappears.

The third is the data model. The README says the way operations are applied was designed for collaborative editing, and lists collaborative editing as a problem the older libraries did not design for in advance. Draft.js is named among the inspirations but the README does not compare the two beyond that, so treat any deeper comparison as something to check in the documentation rather than in the README.

Licence and the cost of keeping up

The repository ships a License.md and the project is MIT, which permits commercial use and modification with the licence and copyright notice retained. Nothing in the README adds terms beyond that. This is not legal advice; if your organization has a policy on third-party licences, the file to read is License.md at the repository root.

The upgrade cost is the part worth budgeting. Releases are versioned per package, with [email protected] and [email protected] among the most recent, and the README states that APIs are not finalized and will break. The repository uses changesets, visible in the .changeset/ directory and the changesetversion script, and publishing goes through lerna with separate latest, next and experimental dist tags. Practically, that means you should pin the versions you install and read the release notes for slate and slate-react before moving them, because the two packages version independently and a mismatch between them is a failure mode the README does not discuss.

Editorial conclusion

Adopt Slate if you are building a React application that needs a document model you control, and you accept that the README calls the project beta and contributor-driven. Do not adopt it if you need a finished, drop-in editor with a stable API and a company behind it, or if your content is a simple comment box. Before committing, verify that the packages you install (slate and slate-react) match the versions you intend to pin, and read the beta notice in the README, which states that some APIs are not finalized and will change.

Frequently asked questions

Official sources

1. ianstormtaylor/slate on GitHub
2. License: MIT
3. Project website
4. README
5. Releases