GrapesJS vs. Gutenberg: Welchen visuellen Editor solltest du wählen?

Beide sind echte visuelle Editoren und beide werden aktiv gewartet. Sie sind für unterschiedliche Aufgaben gebaut, daher ist die nützliche Frage, welchen Job du hast.

Die Wahl hängt weniger davon ab, welcher Editor mehr Funktionen hat, sondern mehr davon, wie dein Produkt funktionieren muss.

Fast jeder Unterschied weiter unten auf dieser Seite ergibt sich aus einer Sache: wofür jedes Projekt gebaut wurde.

Keines von beiden ist eine Kritik an der anderen. Ein CMS, das deine Veröffentlichungspipeline besitzt, ist genau das, was du willst, wenn die Website das Produkt ist. Ein Framework, das nichts besitzt, ist genau das, was du willst, wenn der Editor in etwas leben muss, das du bereits hast.

Gutenberg ist eine WordPress-native Bearbeitungserfahrung. GrapesJS ist ein Framework, um dein eigenes visuelles Bearbeitungserlebnis zu erstellen.

Lies jede Spalte von oben nach unten. Die Ebenen sind in beiden Schichten dasselbe Prinzip – etwas beherbergt einen Editor, der Editor produziert Inhalte, der Inhalt wird gespeichert und dann gerendert – aber die beiden Projekte treten an entgegengesetzten Enden in diese Kette ein.

Beachten Sie, wo jede Kette beginnt. Das erste Feld von Gutenberg ist WordPress: Der Editor existiert, weil es ein Publishing-System darum herum gibt. Die GrapesJS-Kette beginnt mit Ihrer Anwendung, und das Framework belegt genau ein Glied. Dieser einzige Unterschied erklärt die Speicherzeile, die Plugin-Reihe und die White-Label-Zeile in der untenstehenden Tabelle.

Fähigkeiten, nicht Werte. Wenn eine Fähigkeit auf beiden Seiten existiert, sagt die Reihe das an, und wenn eine Seite sie durch Arbeit und nicht durch eine Einstellung erreicht, sagt die Reihe das an.

Jede Zeile wurde aus der eigenen Dokumentation der beiden Projekte vorgelesen. 2026-09-03. Keine Zeile markiert eine Fähigkeit, die eines der Projekte tatsächlich besitzt: Gutenberg registriert benutzerdefinierte Blöcke, unterstützt Blockmuster und Vorlagen, stellt Filter und slot fills für seine Schnittstelle offen und veröffentlicht seinen Editor in npm – das sind die Zeilen, die "erweiterbar" und "möglich" statt "nein" lesen.Quellen: Block Editor Handbook · Block-Registrierung · Block-Editor-Paket · Seiteneditor · GrapesJS-Dokumentation · Components · Speicher

Sehen Sie, wie sich ein eigenständiger visueller Editor von der nativen WordPress-Bearbeitungserfahrung unterscheidet. Dies ist eine echte GrapesJS-Instanz, die auf dieser Seite läuft – ziehen Sie Blöcke herein, wählen Sie alles aus, um es neu zu gestalten, wechseln Sie die Canvas-Breite und öffnen Sie den Asset-Manager.

Was du dir ansiehst, ist die Standardoberfläche des Frameworks. Jedes Panel, jeder Knopf und jede Steuerung darin ist austauschbar – das ist der Unterschied, den die Zeile "benutzerdefinierte Editor-Schnittstelle" in der Tabelle beschreibt.

Gutenberg kann verwendet werden, um Seiten und Layouts durch WordPress-Blöcke zu erstellen, aber seine Hauptaufgabe ist der WordPress-Blockeditor und das Inhaltsbearbeitungssystem.

Die Frage verbirgt meist vier verschiedene Dinge. Wenn man sie trennt, ist die Antwort einfach.

1. 1

   WordPress-Inhaltseditor

   Der Bildschirm, auf dem ein Beitrag oder eine Seite geschrieben wird. Das ist die Kernaufgabe von Gutenberg: eine blockbasierte Schreibfläche, die das klassische Einzeltextfeld ersetzte.

2. 2

   WordPress-Seitenbearbeitung

   Mit einem Block-Thema bearbeitet dieselbe Blockoberfläche Vorlagen, Kopfzeilen, Fußzeilen und Vorlagenteile. Das macht "Page Building" zu einer fairen Beschreibung dessen, was Menschen darin tun.

3. 3

   Seiten aus Blöcken bauen

   Ein Layout aus Blöcken, Mustern und wiederverwendbaren Vorlagen zusammenstellen. Gutenberg macht das, ebenso wie die kommerziellen WordPress-Page-Builder, die ihm vorausgingen.

4. 4

   Eigenständiges visuelles Editor-Framework

   Eine Bibliothek, die du in eine Anwendung einbettest, die du besitzt, ohne dass CMS angehängt ist. Das ist GrapesJS, und es ist das eine Element auf dieser Liste, für das Gutenberg nicht gedacht ist.

Also: Ja, für die ersten drei, und das meinen die meisten Leute. Wenn du nach einer Alternative zum Gutenberg-Page-Builder suchst, weil du die vierte möchtest – einen Editor, den du in dein eigenes Produkt einbauen kannst – dann ist das eine andere Kategorie von Werkzeugen, und es ist die, um die es auf dieser Seite geht.

Das sind reale, häufige Situationen, und in jeder einzelnen davon macht das Hinzufügen eines zweiten Editors das Projekt eher schlechter als besser.

Jedes dieser Produkte ist ein Produkt, bei dem der Editor ein Feature ist, das du auslieferst, und nicht ein Bildschirm, auf dem dein Team sich einloggt.

Ein Vergleich impliziert eine Wahl, und das ist der Fall, wenn es keine gibt. Man muss WordPress nicht unbedingt ersetzen.

WordPress kann weiterhin Inhalte, Benutzer, Berechtigungen und Backend-Workflows verwalten, während GrapesJS die visuelle Bearbeitungsebene bereitstellt. Die beiden sind in dieser Anordnung Peers: Der eine besitzt die Daten und die umgebenden Regeln, der andere besitzt, was ein Autor sieht.

Drei Routen, keine davon automatisch

• Durch den WordPress REST API

  Ihre Anwendung hostet den Editor und liest und schreibt Inhalte über die eigenen REST-Endpunkte. WordPress bleibt unberührt; Authentifizierung und Funktionsprüfungen sind der Teil, der sorgfältig behandelt werden muss.

• Als WordPress-Plugin

  Der Editor ist auf einem Admin-Bildschirm in der Warteschlange und speichert über eine Route, die du selbst registrierst, mit einem nonce und einer Fähigkeitsprüfung. Inhalte bleiben in WordPress, ebenso wie deine Nutzer.

• Über eine eigene Anwendungsschicht

  Ein Dienst befindet sich zwischen dem Editor und WordPress und besitzt die Kartierung in beide Richtungen. Am meisten Arbeit und die einzige Route, die überlebt, wenn sie mehr als eine Inhaltsquelle hat.

Die gleiche Aufteilung, noch einen Schritt weiter: WordPress hört auf, die Website zu rendern, und wird zu einem reinen Inhalts-Backend, während Editor und Frontend beide dein Profil sind.

• WordPress

  Bleibt das Content-Backend

  • Inhaltsspeicherung und Überarbeitungen
  • Nutzer, Rollen und Fähigkeiten
  • Medienbibliothek
  • Redaktioneller Workflow und Terminplanung

• GrapesJS

  Wird zur Bearbeitungserfahrung

  • Das visuelle Canvas
  • Deine Blöcke und Komponententypen
  • Styling-Steuerungen und Einschränkungen
  • Welche Oberfläche du auch immer für Autoren entscheidest,

• Dein Frontend

  Rendert das Ergebnis

  • Dein Framework und dein Routing
  • Dein Leistungsbudget
  • Dein Caching und dein Einsatz
  • Dein Aufschlag, nicht das eines Themas

Was dir diese Vereinbarung bringt

• Ein individuelles Lektorat-Erlebnis, das für deine Autoren und nicht für WordPress konzipiert ist
• Eine klare Trennung zwischen Editor und Frontend
• WordPress bleibt das Inhalts-Backend, wobei sein Workflow intakt ist
• Eine Frontend-Architektur, die nach ihren eigenen Vordiensten gewählt wurde
• Ein viel einfacherer Weg, den Editor unter das Branding eines anderen zu bringen.

Es lohnt sich, die Kosten klarzustellen: Sobald WordPress aufhört, die Seite zu rendern, hören themaabhängige Plugins auf, sie zu beeinflussen, Vorschauen müssen gegen dein Frontend neu erstellt werden, und alles, was ein Block in PHP gerendert hat, muss jetzt woanders rendern.

Das ist die Frage hinter den meisten Migrationsplänen: Können die Blöcke, die wir bereits haben, mitkommen? Der Vergleich der beiden Formen beantwortet das schneller als jeder Absatz.

// A Gutenberg block, as authored in a
// WordPress plugin.
registerBlockType( 'acme/hero', {
  attributes: {
    title:       { type: 'string' },
    description: { type: 'string' },
  },
  supports: { align: [ 'wide', 'full' ] },
  edit:  ( props ) => <HeroEdit { ...props } />,
  save:  ( props ) => <HeroSave { ...props } />,
} );

// The same idea in GrapesJS: a component
// type, plus a block that inserts it.
editor.Components.addType('hero', {
  model: {
    defaults: {
      traits: ['title', 'description'],
      attributes: { class: 'hero' },
      components: [
        { type: 'text', tagName: 'h1' },
        { type: 'text', tagName: 'p' },
      ],
    },
  },
});

editor.BlockManager.add('hero', {
  label: 'Hero',
  category: 'Sections',
  content: { type: 'hero' },
});

Ja, aber die Migration ist meist eine architektonische Umstellung und kein einfacher Export- oder Importvorgang.

Es gibt keinen Konverter, und es wird wahrscheinlich nie einen geben – siehe die beiden obigen Codebeispiele für den Grund. Stattdessen gibt es eine ziemlich vorhersehbare Arbeitsabfolge.

Drei Formen, in zunehmender Reihenfolge der Arbeit. Wir geben hier absichtlich keine Dauern: Die gleiche Anzahl der Blöcke kann zwei Wochen oder ein Viertel betragen, je nachdem, was diese Blöcke tun.

1. 1Einfach

   Meistens Standardblöcke

   Der Inhalt besteht größtenteils aus Kernblöcken, und die Layouts sind konventionell.

   • Meistens Standardblöcke
   • Begrenzte benutzerdefinierte Funktionalität
   • Eine kleine Anzahl von Vorlagen
   • Styling, das im Stylesheet des Themas lebt
2. 2Mittel

   Individuelle Blöcke und individuelles Design

   Eine eigene Blockbibliothek und ein Bearbeitungserlebnis, das schon einmal angepasst wurde.

   • Benutzerdefinierte Blöcke
   • Individuelles Design
   • Muster
   • Eine angepasste Editor-Oberfläche
   • Integration mit externen Diensten
3. 3Komplex

   Dynamisches Rendering und tiefe Integration

   Die Blöcke sind wirklich PHP, und die WordPress-Installation ist das, worauf das Unternehmen basiert.

   • Dynamische Blöcke
   • Rendering in PHP
   • WooCommerce
   • Benutzerdefinierte WordPress-Plugins
   • Tief integrierte WordPress-Workflows
   • Große Template-Bibliotheken

Wenn Ihr Projekt in der dritten Spalte steht, ist die Frage, die sich zuerst stellen sollte, nicht "Wie migrieren wir?", sondern "Welcher Teil davon braucht tatsächlich einen anderen Editor?" – die Antwort lautet oft ein Bildschirm, nicht die ganze Seite.

Du musst nicht jede Editor-Funktion selbst bauen. Erweitere GrapesJS mit Plugins für gemeinsame Funktionen und Integrationen – so wie ein WordPress-Projekt ein Plugin verwendet, anstatt eines zu schreiben.

Blocks

Fertige Blöcke, die ein Autor auf das Canvas zieht, von einfachen Layout-Teilen bis hin zu kompletten Kopf- und Fußzeilen.

Durchstöbern Sie die Kategorie

Kernblöcke

Plugin Basic Blocks

Das Startblockset, von dem die meisten Editoren ausgehen.

KostenlosPlugin ansehen

Layoutblöcke

Users Blocks

Eine größere Bibliothek für Teams, die am ersten Tag Layout-Vielfalt benötigen.

59,00 $Plugin ansehen

Headerblöcke

Super Header for GrapesJS

Header-Abschnitte, die ein Autor konfigurieren kann, ohne Markup zu berühren.

39,00 $Plugin ansehen

Footer-Blöcke

Super Footer for GrapesJS

Footer-Abschnitte mit demselben Konfigurationsmodell.

39,00 $Plugin ansehen

Rich Text Editing

Tausche den eingebauten Inline-Texteditor gegen eine vollständige Bearbeitungsleiste aus. Vertraute Namen, die innerhalb des Canvas laufen.

Durchstöbern Sie die Kategorie

Inline-Bearbeitung

GrapesJS Inline Text Editor — Compatible with CKEditor 5

Eine vollständige Bearbeitungsleiste innerhalb des Canvas.

69,00 $Plugin ansehen

Inline-Bearbeitung

TinyMCE 8 Inline Text Editor

Eine vertraute Werkzeugleiste für Autoren, die von einem anderen System wechseln.

69,00 $Plugin ansehen

Inline-Bearbeitung

Froala Inline Text Editor

Eine dritte Option, falls deine Nutzer sie bereits kennen.

69,00 $Plugin ansehen

Toolbar-Extras

Grapesjs RTE Extensions

Zusätzliche Steuerungen auf der integrierten Inline-Symbolleiste.

KostenlosPlugin ansehen

Speicher und Integrationen

Wo der Editor speichert. Dies ist die Schicht, in die eine WordPress REST-Route eingefügt wird – dieselbe Schnittstelle, ein anderer Endpunkt.

Durchstöbern Sie die Kategorie

Backend-Speicher

Directus Storage

Direkt in ein headloses Backend speichern.

KostenlosPlugin ansehen

Backend-Speicher

Grapesjs Firebase Storage

Speichere in einer gehosteten Datenbank ohne eigenen Server.

KostenlosPlugin ansehen

Lokale Speicherung

IndexedDB Storage

Bewahren Sie Entwürfe im Browser auf, bevor irgendetwas verschickt wird.

KostenlosPlugin ansehen

Mehrseitig

Pages Manager

Verwandeln Sie eine einzelnes Canvas in ein mehrseitiges Projekt.

25,00 $Plugin ansehen

CSS-Frameworks und Styling

Tailwind- und Bootstrap-Blocksets, sodass das Markup, das der Editor erstellt, mit dem Designsystem übereinstimmt, das du bereits ausgeliefert hast.

Durchstöbern Sie die Kategorie

Tailwind

Grapesjs Tailwind

Gestalte mit den Utility-Klassen, die du ohnehin auslieferst.

KostenlosPlugin ansehen

Tailwind-Blöcke

Plugin Blocky for Tailwind CSS

Eine Blockbibliothek, die auf diesen Klassen basiert.

59,00 $Plugin ansehen

Bootstrap 5

GrapesJS Bootstrap v5 Blocks

Erzeugt einen aktuellen Bootstrap-Aufschlag.

KostenlosPlugin ansehen

Bootstrap 4

Bootstrap 4 Blocks for GrapesJS

Dasselbe gilt für Projekte, die noch auf der vorherigen Hauptversion sind.

KostenlosPlugin ansehen

Sieben konkrete Produkte, von denen jedes ein Editor mit einer anderen Aufgabe ist.

Der Kern ist framework-agnostisch: Er rendert in ein DOM-Element, sodass die Integration hauptsächlich eine Frage ist, welcher Lebenszyklus-Hook den Initialisierer aufruft.

Ein Hinweis, der es deutlich zu erwähnen lohnt: GrapesJS ist kein nativer React-, Vue- oder Angular-Komponenteneditor. Er bearbeitet HTML und CSS in einer eigenen Canvas, und der Framework-Wrapper ist die Art und Weise, wie du ihn mountest und steuerst – nicht wie das Canvas rendert. Wenn du die eigenen Komponenten deines Frameworks im Canvas live rendern lassen möchtest, ist das eine andere Anforderung und ein anderes Set an Werkzeugen.

Finde die Reihe, die zu dem passt, was du baust. Fünf davon zeigen auf Gutenberg, und das ist keine Höflichkeit – dort sollten diese Projekte beginnen.

Die meisten Teams, die zu diesem Vergleich kommen, liegen irgendwo auf einer Skala zwischen "Gutenberg ist in Ordnung" und "wir bauen ein Produkt". Es gibt drei Positionen, nicht zwei.

• Option 1

  Behalte Gutenberg

  Wähle das, wennNative WordPress-Bearbeitung reicht aus, und die Reibung, die du spürst, ist eher ein Theme- oder Plugin-Problem als ein Editor-Problem.

  Die günstigste Option mit großem Abstand und die richtige häufiger, als eine Seite wie diese normalerweise zulässt. Nichts auf dieser Seite ist ein Grund, eine funktionierende WordPress-Seite von ihrem eigenen Editor zu entfernen.

  Was die Arbeit ist

  • Keine Migration
  • Kein zweites System zu warten
  • Alles, was dein Team bereits weiß
  Block Editor Handbook
• Option 2

  Gutenberg erweitern

  Wähle das, wennDu brauchst zusätzliche Blöcke, zusätzliche Steuerungen oder einen strafferen Bearbeitungsbildschirm – aber das WordPress-Bearbeitungsmodell selbst ist genau das Richtige für dich.

  Gutenberg ist wirklich erweiterbar. Benutzerdefinierte Blöcke, Blockmuster, block supports, Filter und slot fills decken einen sehr großen Teil dessen ab, was Leute meinen, wenn sie sagen, der Editor macht nicht das, was er will.

  Was die Arbeit ist

  • Registrieren Sie Ihre eigenen Blöcke
  • Begrenze, was Autoren ändern dürfen
  • Anpassung der Bearbeitungsoberfläche über Filter
  Block-Filterreferenz
• Option 3

  Fügen Sie GrapesJS hinzu

  Wähle das, wennDu brauchst ein separates oder deutlich anpassbareres visuelles Bearbeitungserlebnis – meistens, weil der Editor Teil dessen ist, was du verkaufst.

  Hinzufügen statt ersetzen: WordPress kann genau dort bleiben, wo es ist, Inhalte und Nutzer besitzen, während eine zweite Bearbeitungsfläche dem Fall dient, für den es nie gebaut wurde.

  Was die Arbeit ist

  • Ein visueller Editor, den du vollständig kontrollieren kannst
  • WordPress wurde als Inhalts-Backend beibehalten
  • Eine Integrationsschicht, die du besitzt
  WordPress-Integrationsleitfaden