Websites herunterladen, die Quill nutzen

Über Quill

Ein Rich-Text-Editor gehört zu den wenigen Frontend-Komponenten, die verraten, wozu eine Website da ist. Niemand lädt Quill, um eine Marketingseite darzustellen. Die Bibliothek taucht dort auf, wo Menschen auf einer Website schreiben statt lesen: in Kommentarfeldern, Support-Tickets, internen Tools, Redaktions-Backends, Notizen und Messaging, überall dort, wo Inhalte entstehen statt konsumiert zu werden.

Die technische Bauweise erklärt, warum sich Teams dafür entscheiden. Erschienen 2014 unter der Lizenz BSD und in JavaScript geschrieben, stellt der Editor ein Dokument als Folge von Operationen dar statt als bloßen Block aus Markup, was einer Anwendung die programmatische Steuerung der Inhalte und eine tragfähige Grundlage für gemeinsames Bearbeiten verschafft. Mit eigenen Formaten, Modulen und Themes lässt sich die Software erweitern, und sie bindet die umgebende Anwendung an kein bestimmtes Framework.

Stand Oktober 2026 erkennen wir den Editor auf 10.265 Websites in der Kategorie Rich text editors. 3.817 davon verorten wir in den USA, und die vorherrschende Endung ist .com. Die Verteilung spiegelt wider, wo Softwareprodukte entwickelt und verkauft werden, und nicht, wo das allgemeine Web zu Hause ist, was man bei einer Komponente auch erwarten würde, die erst auftaucht, wenn eine Website angemeldete Nutzer oder ein ernst zu nehmendes Formular hat.

Das Versionsverhalten bestätigt diesen Befund. In den Daten tauchen 16 Versionen auf, am häufigsten sehen wir Version 1.3.6, also eine Konzentration auf eine langlebige Release-Linie statt einer Streuung über die neuesten Releases. Ein Editor lässt sich nur teuer wechseln, weil die gespeicherten Inhalte vom eigenen Dokumentmodell des Editors geprägt sind. Eine Migration bedeutet deshalb, in historische Daten einzugreifen, und nicht nur, eine Abhängigkeit auszutauschen. Teams schieben das auf, und dieser Aufschub zeigt sich in einem Bestand, der noch lange auf einer bewährten Linie bleibt, nachdem Neueres verfügbar ist.

Zwei Grenzen sollte man nennen. Erstens liegen die meisten Editoren hinter einem Login, und wir crawlen, was öffentlich erreichbar ist, sodass ein großer Teil der tatsächlichen Installationen für uns prinzipbedingt unsichtbar bleibt. Zweitens das Bundling: Anwendungen, die den Editor in eine einzige Anwendungsdatei kompilieren, hinterlassen nichts Erkennbares auf der Seite. Beide Effekte wirken in dieselbe Richtung, was bedeutet, dass die Zahl eine Untergrenze ist und im sichtbaren Bestand öffentlich zugängliche Formulare und Websites überrepräsentiert sind, die die Bibliothek als eigenes Asset laden.

Innerhalb dieser Grenzen beantwortet die Liste Fragen, die eine Abfrage pro Domain nicht klären kann. Anbieter von Kollaborationsinfrastruktur, Moderation, Spamfilterung oder Content-Speicherung wollen wissen, welche Websites überhaupt von Nutzern verfasste Inhalte annehmen, denn das ist die Eingangsvoraussetzung für die ganze Kategorie. Sicherheitsforscher wollen den Bestand kennen, weil Editoren eine wiederkehrende Quelle von Problemen bei der Bereinigung von Eingaben sind, und ein solcher Fehler wiegt umso schwerer, je mehr Websites die Komponente öffentlich erreichbar einsetzen. Konkurrierende Editor-Projekte wollen Größe und geografische Verteilung der installierten Basis kennen, bevor sie entscheiden, ob sich ein Migrationspfad lohnt. All das sind Fragen an den Bestand, die sich mit einem Auszug beantworten lassen und Domain für Domain nicht.