Plate

Plate's real argument is architectural, not feature-count. The framework splits cleanly into three layers: the platejs core runtime with React bindings, the headless @platejs/* plugin packages, and Plate UI components installed into your own app through the shadcn CLI. Because Plate UI follows the shadcn/ui philosophy — copy the code, own it, keep editing it — the distribution model is registry-based rather than a versioned npm blob. Running npx shadcn@latest add @plate/editor-ai pulls a complete AI editor template, kits, components and even API routes straight into your repository under your own styling conventions. For teams already on shadcn/ui and Radix UI, that means the editor stops looking like a foreign widget dropped into your design system. Components use predictable React and shadcn/ui conventions, and the plugins give you nodes, marks, serialization, collaboration and behavior as composable pieces rather than a monolith you configure through a settings object. Content serializes to HTML and Markdown. Install guides cover Next.js, React, RSC, Node.js and manual setup, and there are editor templates to copy when you don't want to start from an empty document. The AI angle deserves scrutiny because it's the part buyers will ask about. Plate ships an AI plugin and an MCP setup; the stated benefit of the open-code model is that agents get real context from your component source and consistent registry metadata, and the MCP setup lets AI tools inspect and apply Plate registry items. That's a meaningfully different integration shape than bolting a completion API onto a textarea — but it also means the AI surface is something you assemble, not something the vendor operates for you. The honest weaknesses are the mirror image of the strengths. Copy-in components mean updates to Plate UI are yours to manage manually; there is no package bump that quietly fixes a component. The third-party ecosystem is thinner than ProseMirror's or Lexical's, so edge-case answers are likelier to come from reading source than from years of forum posts. Mobile-native and desktop editor builds are not part of this framework — it's aimed at web and CLI usage. And because there is no hosted backend or admin dashboard, the collaboration plugin still leaves you running the sync infrastructure. Where it fits: SaaS products that need a distinctive editor surface, internal tools that need block types no off-the-shelf WYSIWYG offers, and teams whose roadmap already includes in-document AI actions. Where it doesn't: content teams who want to configure an editor without touching code, and any organization without someone who owns editor maintenance on an ongoing basis. The ~16k GitHub stars and an active Discord mean you are not alone, but you are still the integrator.