Having used PM for less than two years, I’ve developed large modules like smart tables; and having used Slate to this day, I’ve gone through major version upgrades from 0.47 to 0.5+, so I feel somewhat qualified to speak on the topic. Since many in the community often ask me about the differences between the two, I decided to write a blog post to briefly summarize them.
Slate Pros:
-
Quick to learn, works out of the box, with easy-to-grasp concepts and readable code, especially for those familiar with React. Its view layer is entirely React-based, making it possible to get up to speed within a week.
-
Highly customizable. You can modify core modules like
slateandslate-reactto extend plugins and architecture according to your business needs. Modifying the underlying code is relatively easier compared to PM. -
Well-suited for collaborative scenarios like Sharedb. Its JSON-based design seems almost tailor-made for Slate.
Slate Cons:
-
The author is slow to fix bugs, as he doesn’t work on it full-time. Maintenance largely depends on the community. Some APIs are clearly flawed (e.g.,
.include, which has tripped me up), while others throw exceptions or returnnullinconsistently. The author often asks for PRs instead of fixing issues himself. -
Unstable APIs. It’s still in the 0.x version and hasn’t reached a stable release, so future architectural changes could be significant.
-
The official version is practically unusable, especially for CJK language users dealing with input method events. You’ll need to download and modify it yourself.
-
Performance optimization is challenging. Since the view layer is entirely React-based, optimizing it largely depends on optimizing React, which isn’t inherently fast.
-
Poorly written code can easily crash the editor, leaving it unusable. There’s no robust error-handling mechanism beyond modifying the framework code.
-
Unclear data flow can lead to bugs. For example, you can directly assign
editor.children, overwriting existing editor content without any warnings. -
Cursor and Mark issues are hard to hack. The code feels beginner-level (in my opinion).
-
Poor documentation, with some parts inconsistent with actual API behavior.
-
Tightly coupled with React.
-
Mobile support isn’t great and requires modifications.
ProseMirror Pros:
-
The author maintains it full-time and is very responsive to community questions.
-
It’s been in stable release for over three years, with consistently stable APIs.
-
Backed by big companies—Google uses the author’s other project, CodeMirror (e.g., in Chrome DevTools’ Elements tab)—so it’s highly credible.
-
Clear data flow (though hard to understand at first).
-
Less prone to crashes than Slate. Errors won’t render the entire editor unusable, making it more stable.
-
The author is a freelancer who accepts paid bug fixes, charging €200 per hour (I emailed him; that’s the rate if I recall correctly).
-
The document tree model is very useful. Its strict Schema constraints and text/token-based positioning system are brilliant, though they make collaboration tricky.
-
Not tied to any view framework. You can use React, Vue, or Angular for the view layer, though custom components are rarely needed. For basic elements like paragraphs, headings, and lists, you only need to describe the DOM structure via the API.
-
Good mobile support.
ProseMirror Cons:
-
Some concepts and code are hard to grasp (the author’s technical depth feels unfathomable).
-
Modular and not out-of-the-box, requiring some setup effort to get running.
-
Implementing collaborative solutions is harder compared to Slate. The author opened an issue in 2017 promising a collaboration demo but still hasn’t delivered.
-
Steeper learning curve, often taking two weeks or even a month to start developing basic features.
-
Since it implements its own view layer (though developers can use APIs to render custom components like React), debugging framework-level view issues is tricky.
-
Modifying the source code is nearly impossible due to high costs, so fixes usually depend on the author.
For a more detailed comparison, check out this answer, which is mostly accurate:
Meituan’s Xuecheng uses PM:
Summary
Slate is suitable for large companies because it’s quick to get started (large companies rely on input-output ratios—otherwise projects can’t secure resources. How do you explain to leadership if after two months it’s still just a demo?). Thus, results can be delivered rapidly, but refining it to perfection requires significant manpower for deep customization, making it ideal for large companies: quick adoption early on, followed by adding personnel for heavy modifications. Additionally, its extensibility is exceptional—after customization, it can meet almost any requirement (for example, we’ve implemented various modules and features like inline comments, hierarchical heading folding, embedding third-party modules, etc.).
Prosemirror is better suited for small and medium-sized companies. It has decent cross-platform support, and if bugs arise, you can confidently rely on the author to fix them—or even pay them to resolve issues if absolutely necessary. Although the learning curve is steeper, a core developer at a small or medium-sized company should be able to produce a demo after about two weeks of exploration.
-
Previous
Unboxing: First Impressions of AirPods Pro 2nd Generation -
Next
Issues Encountered When Converting HEIC/HEIF Images Using Sharp
From the author:
I often wish that when facing some key decisions in life, someone could tell me the best course of action so that I would not waste my precious time. Putting myself in others' shoes, I therefore write blogs often, hoping to record in this tiny corner of the vast Internet the once-in-a-lifetime experiences that matter to me, and to help those who seek help.
