slate: Open Source Browsers & Extensions

What is slate?

Slate is a completely customizable framework for building rich text editors, written in TypeScript and released under the MIT licence, for JavaScript and React developers who need an editor that goes well past what a fixed schema can offer.

What it is

Slate is a framework for building rich text editors for the browser, living in the JavaScript and React ecosystem and written in TypeScript. Its central design choice is that all of its logic is implemented as a series of plugins, so developers are never constrained by what is or is not in "core". The README describes it as a pluggable implementation of contenteditable built on top of React, and names Draft.js, Prosemirror and Quill as inspirations. The stated goal is to let teams build rich, intuitive editors like those in Medium, Dropbox Paper or Google Docs without the codebase becoming mired in complexity.

The concrete problem it addresses is the hardcoded editor schema and the awkward APIs around it. The author's account of the prior libraries he tried lists the recurring failures: schemas that supported bold and italic but not comments, embeds or domain-specific needs; convoluted programmatic document transforms, which matter for advanced behaviours; serialization to HTML or Markdown treated as an afterthought that required boilerplate; view layers reinvented instead of reusing React; internal data representations that made realtime collaborative editing impossible without effectively rewriting the editor; monolithic repositories that hid reusable internal tooling; and flat document models that made tables, embeds and captions hard to reason about or outright impossible. Slate is built as the answer to those failures.

Key capabilities

Plugin-based architecture: all editor logic is implemented as a series of plugins, so behaviour is not limited to what ships in "core".
Pluggable implementation of contenteditable built on top of React, reusing an existing view technology rather than rolling a new one.
Customizable schema, supporting domain-specific content such as comments and embeds alongside conventional rich text.
Programmatic document transforms designed to be workable, which the README identifies as critical for advanced behaviours.
Serialization to formats such as HTML and Markdown treated as a design concern rather than an afterthought.
Nested document support for structures including tables, embeds and captions, where flat documents become difficult or impossible.
Collaborative editing considered in the internal data representation from the outset, so realtime use cases do not require rewriting the editor.

Who uses it and how

React teams building editing surfaces with the shape of Medium, Dropbox Paper or Google Docs, rather than a comment box or a textarea replacement.
Products with domain-specific content needs, such as comments or embeds, that a fixed-schema editor cannot express.
Applications that need programmatic document transformation and export to HTML or Markdown as part of a publishing or content pipeline.
Products that need realtime, collaborative editing, since the data model is designed for it rather than retrofitted.
Contributor-driven teams: the project is not backed by a huge company, so fixes and advanced features typically come from the people who need them, and active contributors are invited to become maintainers via the Slack channel.

Getting started

The README points to the homepage at slatejs.org, which carries the Documentation, Demo and Examples links, plus a Contributing section. The excerpt provided does not list an install command or a published package name, so the documentation site is the starting point.

How it compares

Slate names Draft.js, Prosemirror and Quill as the libraries its author tried first and as its inspirations, and positions itself against the same class of rich text editors. The contrast it draws is on customizability, programmatic transforms, serialization, reusing React as the view layer, designing for collaboration in advance, and handling nested documents. It is licensed under MIT, so adoption carries no licence cost.

When to use it — and when not to

Slate is explicitly in beta: the core API is usable now, but advanced use cases may need pull requests for improvements or bug fixes, some APIs are not finalized, and breaking changes will arrive as better solutions are found, with no 1.0 release schedule. As a library rather than a hosted service, there is no database, storage or SMTP for a self-hoster to operate, but there is also no commercial vendor behind it, and the repository carries a substantial open issue count. Teams that need a frozen API or a support contract should look elsewhere; teams that want control over the editor and are willing to contribute should find it a reasonable fit.

project readme (upstream, from github) — read inline

A completely customizable framework
for building rich text editors.

Why? · Principles · Demo · Examples · Documentation · Contributing!

Slate lets you build rich, intuitive editors like those in Medium, Dropbox Paper or Google Docs—which are becoming table stakes for applications on the web—without your codebase getting mired in complexity.

It can do this because all of its logic is implemented with a series of plugins, so you aren't ever constrained by what is or isn't in "core". You can think of it like a pluggable implementation of contenteditable built on top of React. It was inspired by libraries like Draft.js, Prosemirror and Quill.

🤖 Slate is currently in beta. Its core API is useable right now, but you might need to pull request improvements for advanced use cases, or fixes for some bugs. Some of its APIs are not "finalized" and will have breaking changes over time as we discover better solutions. There isn't currently a 1.0 release schedule, we're still getting the architecture right.

🤖 Slate is also contributor-driven. It is not backed by any huge company, which means that all contributions are voluntary and done by the people who need them. If you need something improved, added, or fixed, please contribute it yourself or no one will. And if you want to become a more active maintainer, let us know in the Slack channel.

Why?

Why create Slate? Well... (Beware: this section has a few of my opinions!)

Before creating Slate, I tried a lot of the other rich text libraries out there—Draft.js, Prosemirror, Quill, etc. What I found was that while getting simple examples to work was easy enough, once you started trying to build something like Medium, Dropbox Paper or Google Docs, you ran into deeper issues...

The editor's "schema" was hardcoded and hard to customize. Things like bold and italic were supported out of the box, but what about comments, or embeds, or even more domain-specific needs?
Transforming the documents programmatically was very convoluted. Writing as a user may have worked, but making programmatic changes, which is critical for building advanced behaviors, was needlessly complex.
Serializing to HTML, Markdown, etc. seemed like an afterthought. Simple things like transforming a document to HTML or Markdown involved writing lots of boilerplate code, for what seemed like very common use cases.
Re-inventing the view layer seemed inefficient and limiting. Most editors rolled their own views, instead of using existing technologies like React, so you have to learn a whole new system with new "gotchas".
Collaborative editing wasn't designed for in advance. Often the editor's internal representation of data made it impossible to use to for a realtime, collaborative editing use case without basically rewriting the editor.
The repositories were monolithic, not small and reusable. The code bases for many of the editors often didn't expose the internal tooling that could have been re-used by developers, leading to having to reinvent the wheel.
Building complex, nested documents was impossible. Many editors were designed around simplistic "flat" documents, making things like tables, embeds and captions difficult to reason about and sometimes impossible.

Of course not every editor exhibits all of these issues, but if you've tried using another editor you might have run into similar problems. To get around the limitations of their API's and achieve the user experience you're after, you have to resort to very hacky things. And some experiences are just plain impossible to achieve.

If that sounds familiar, you might like Slate.

Which brings me to how Slate solves all of that...

Principles

Slate tries to solve the question of "Why?" with a few principles:

First-class plugins. The most important part of Slate is that plugins are first-class entities. That means you can completely customize the editing experience, to build complex editors like Medium's or Dropbox's, without having to fight against the library's assumptions.
Schema-less core. Slate's core logic assumes very little about the schema of the data you'll be editing, which means that there are no assumptions baked into the library that'll trip you up when you need to go beyond the most basic use cases.
Nested document model. The document model used for Slate is a nested, recursive tree, just like the DOM itself. This means that creating complex components like tables or nested block quotes are possible for advanced use cases. But it's also easy to keep it simple by only using a single level of hierarchy.
Parallel to the DOM. Slate's data model is based on the DOM—the document is a nested tree, it uses selections and ranges, and it exposes all the standard event handlers. This means that advanced behaviors like tables or nested block quotes are possible. Pretty much anything you can do in the DOM, you can do in Slate.
Intuitive commands. Slate documents are edited using "commands", that are designed to be high-level and extremely intuitive to write and read, so that custom functionality is as expressive as possible. This greatly increases your ability to reason about your code.
Collaboration-ready data model. The data model Slate uses—specifically how operations are applied to the document—has been designed to allow for collaborative editing to be layered on top, so you won't need to rethink everything if you decide to make your editor collaborative.
Clear "core" boundaries. With a plugin-first architecture, and a schema-less core, it becomes a lot clearer where the boundary is between "core" and "custom", which means that the core experience doesn't get bogged down in edge cases.

Demo

Check out the live demo of all of the examples!

Examples

To get a sense for how you might use Slate, check out a few of the examples:

Plain text — showing the most basic case: a glorified ``.
Rich text — showing the features you'd expect from a basic editor.
Markdown preview — showing how to add key handlers for Markdown-like shortcuts.
Inlines — showing how wrap text in inline nodes with associated data.
Images — showing how to use void (text-less) nodes to add images.
Hovering toolbar — showing how a hovering toolbar can be implemented.
Tables — showing how to nest blocks to render more advanced components.
Paste HTML — showing how to use an HTML serializer to handle pasted HTML.
Mentions — showing how to use inline void nodes for simple @-mentions

Frequently asked questions

Is slate free to use?

slate is open source under the MIT licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does slate do?

A completely customizable framework for building rich text editors. (Currently in beta.)

What is slate written in?

slate is primarily written in TypeScript. Its source is publicly available at https://github.com/ianstormtaylor/slate, and it has 31,748 GitHub stars.