私は以前2年弱PMを使用し、スマートテーブルなどの大規模モジュールを開発してきました。Slateは現在まで使用しており、0.47から0.5+へのメジャーバージョンアップを経験しているため、ある程度発言権があると考えています。業界内でよく両者の違いについて質問されるため、ブログで簡単に説明することにしました。
Slateの長所：
-
習得が早く、すぐに使い始められる。概念が理解しやすく、コードもわかりやすい。特にReactに慣れている人にとっては、ビューレイヤーが完全にReactベースなので、基本的に1週間で理解できる。
-
カスタマイズ性が高く、自社の業務シナリオに合わせてslateやslate-reactなどのコアモジュールを改造し、さまざまなプラグインやアーキテクチャを拡張できる。PMと比べて低レイヤーの修正が比較的簡単。
-
sharedbのようなコラボレーションシナリオにうまく対応できる。JSONベースの設計はほぼSlateのために用意されたようなもの。
Slateの短所：
-
作者のバグ修正が遅く、フルタイムで開発しているわけではない。基本的にコミュニティによるメンテナンスに依存しており、.includeのような明らかに不合理なAPI（実際に被害を受けた）や、例外をスローするAPIとnullを返すAPIが混在しているなど、設計が不十分な部分がある。しかし作者は自分で修正するのではなくPRを出すよう求める。
-
APIが不安定で、まだ正式リリースされておらず0.xバージョンのまま。将来的にアーキテクチャが大きく変わる可能性がある。
-
公式バージョンは基本的に使えない状態で、特にCJK言語ユーザーのIMEイベントなどに対応するには、ダウンロードして自分で改造する必要がある。
-
パフォーマンス最適化が困難。ビューレイヤーが完全にReactベースのため、この部分のコード最適化はReactの最適化から始めるしかない。Reactは汎用フレームワークであり、速度面での優位性はない。
-
コードが適切に書かれていないと、エディタがクラッシュして使用不能になることが容易に起こる。フレームワークコードを修正する以外に有効なフォールトトレランス機構がない。
-
データフローが不明確でバグが発生しやすい。例えばeditor.childrenに直接代入して既存のエディタ内容を上書きでき、エラーも発生しない。
-
カーソル問題やMark問題のハックが難しく、コードは初心者レベル（個人的な見解）。
-
ドキュメントが不十分で、実際のAPI動作と一致しない部分がある。
-
Reactに強く依存している。
-
モバイル端末のサポートが現時点では不十分で、改造が必要。
ProseMirrorの長所：
-
作者がフルタイムでメンテナンスしており、非常に熱心でコミュニティの質問に積極的に回答する。
-
正式リリースから3年以上経過しており、APIが非常に安定している。
-
大企業の支持があり、Googleも作者の別プロジェクトCodeMirror（Chrome DevtoolsのElementタブで使用）を採用しているため、信頼性が高い。
-
データフローが明確（ただし理解しにくい）。
-
Slateほど簡単にクラッシュせず、エラーが発生してもエディタフレームワーク全体が使用不能になることはなく、安定性が高い。
-
作者はフリーランスで、寄付で生計を立てており、バグ修正の有償サポートを正式に提供している。時間制で1時間200ユーロ（メールで確認した限りでは、間違っていなければ）。
-
ドキュメントツリーモデルが非常に使いやすく、Schemaの厳格な制限とテキスト/Tokenオフセットベースの位置決めシステムが優れている。ただしコラボレーションには向かない。
-
任意のビューフレームワークに依存せず、React、View、Angularなどでビューフレームワークを開発できる。ただしparagraph、heading、listなどのカスタムコンポーネントは通常必要なく、APIでDOM構造を記述するだけでよい。
-
モバイル端末のサポートが良好。
ProseMirrorの短所：
-
一部の概念が理解しにくく、コードも難解（作者の技術力は計り知れないと感じる）。
-
モジュールが分散しており、すぐに使える状態ではなく、ある程度の習得コストが必要。
-
PMベースのコラボレーションソリューションの実装は、Slateと比べて困難。作者は2017年にコラボレーションデモを作成するissueを開いたが、まだ完成していない。
-
習得難易度が高く、基本的な機能の開発を開始するのに2週間から1ヶ月かかることもある。
-
独自実装のビューレイヤー（開発者はReactコンポーネントなどのカスタムコンポーネントをレンダリングするためにAPIを使用することも可能）のため、フレームワーク自体のビューレイヤーに問題が発生した場合、特定と修正が難しい。
-
ソースコードの改造はほぼ不可能で、コストが非常に高く、作者による修正に依存するしかない。
こちらの回答者の比較も参考になります。大きな問題はなさそうです：
美团の学城ではPMを使用しています：
まとめ
Slateは大企業に向いています。なぜなら習得が早く（大企業は投資対効果を重視するため、プロジェクトがリソースを得られず、2ヶ月経ってもデモレベルのままでは上司に説明がつきません）、迅速に成果を出せます。ただし、完璧に仕上げるには基盤部分の大幅なカスタマイズに人的リソースが必要なので、大企業に適しています。初期は素早く習得し、後から人員を増やして改造できます。また拡張性が非常に高く、カスタマイズ後はほぼあらゆる要件を満たせます（例えば私たちは下線コメント、階層見出しの折りたたみ、サードパーティモジュールの埋め込みなど様々なモジュールと機能を実装しました）。
Prosemirrorは中小企業に向いています。各プラットフォームのサポートも比較的良好で、バグがあれば作者に修正を任せられます。どうしても修正できない場合は有償で作者に依頼することも可能です。習得コストは高いものの、中小企業の主力開発者が2週間ほど試行錯誤すればデモを作成できるレベルでしょう。
ブログ主より：
人生の重要な選択に直面したとき、最善の方法を誰かが教えてくれて、貴重な時間を無駄にせずに済めばと、私はよく願っています。だからこそ、自分の経験を踏まえて頻繁にブログを書き、広大なインターネットのこの小さな片隅に、私にとって一度きりの人生経験を記録し、助けを求める人々の力になれればと思っています。
