Quill v2: Rich-Text-Editor veröffentlicht

 (quilljs.com)
2 Punkte von GN⁺ 2024-04-20 | 1 Kommentare | Auf WhatsApp teilen
  • Quill 2.0 ist ein kostenloser Open-Source-WYSIWYG-Editor für das moderne Web, mit dem sich Rich-Text-Bearbeitungsfunktionen direkt in Produkte integrieren lassen
  • Auf Basis einer modularen Architektur und einer ausdrucksstarken API kann man mit dem schlanken Core beginnen und den Editor an die eigenen Anforderungen anpassen
  • Entwickler können detailliert auf Inhalte, Änderungen und Events des Editors zugreifen; Ein- und Ausgabe erfolgen über JSON, sodass konsistentes Verhalten zu erwarten ist
  • Unterstützt aktuelle Browser auf Desktop, Tablet und Smartphone und zielt darauf ab, über Plattformen hinweg dasselbe Verhalten und erzeugte HTML bereitzustellen
  • Lässt sich vom kleinen Projekt bis zum Fortune-500-Unternehmen skalieren und eignet sich daher gut, um zunächst einen einfachen Editor einzuführen und ihn mit dem Produktwachstum zu erweitern

Quill 2.0 und der Einstieg

  • Quill 2.0 wurde veröffentlicht; die Release-Details sind in einem separaten Ankündigungsbeitrag zu finden: Quill 2.0 is released!
  • Quill ist ein kostenloser Open-Source-WYSIWYG-Editor, der für das moderne Web entwickelt wurde
  • Das Basisbeispiel lädt quill.snow.css und quill.js von einem CDN und erstellt anschließend mit new Quill('#editor', ...) den Editor
    • Die Beispielversion ist quill@2.0.3
    • In modules.toolbar wird #toolbar angegeben, als theme wird snow verwendet
  • In der Entwicklerkonsole des Browsers lässt sich die API direkt ausprobieren

Anpassung und Einsatzbereich

  • Quill lässt sich über seine modulare Architektur und API an die jeweiligen Anforderungen anpassen
  • Entwickler können über eine einfache API detailliert auf Inhalte, Änderungen und Events des Editors zugreifen
  • Ein- und Ausgabe nutzen beide JSON und bieten dadurch konsistentes und deterministisches Verhalten
  • Unterstützt aktuelle Browser auf Desktop, Tablet und Smartphone und stellt plattformübergreifend gleiches Verhalten sowie erzeugtes HTML bereit
  • Kann sowohl in kleinen Projekten als auch in Fortune-500-Unternehmen eingesetzt werden; man kann mit dem Quill Core starten und ihn bei Bedarf anpassen oder Erweiterungen hinzufügen
  • Die Zahl der GitHub Stars wird mit 47.204 angegeben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-20
Meinungen auf Hacker News

  • In einem früheren Job habe ich einmal ein System gebaut, bei dem Nutzer formatierten Text in ein Quill-Textfeld eingaben und dieser in der Datenbank im Delta-Format gespeichert wurde.
    Später holte ein anderes Teammitglied die Inhalte in ein InDesign-Plugin, las die in Quill angewendeten Formatierungen aus und übertrug sie wieder auf InDesign-Stile.
    Der Ablauf war: Front-Office-Mitarbeiter gaben rechtliche Bekanntmachungen für eine Zeitung ein, und das Produktionsteam übernahm die Druckvorstufe in InDesign. Hätten wir wie die meisten Editoren HTML gespeichert, wäre das deutlich schwieriger gewesen; das Quill-Delta-Format hat es erheblich erleichtert.
    Ich hatte seit Jahren nichts mehr von Quill gehört oder es benutzt, daher freut es mich, dass es noch lebt.

  • Release Notes: https://github.com/quilljs/quill/releases/tag/v2.0.0
    Ankündigungsbeitrag: https://slab.com/blog/announcing-quill-2-0/
    Ich habe Quill ziemlich viel genutzt: Die Integration ist einfach, das JSON-Delta-Format ist recht ordentlich, und die Struktur ist eher schlicht.
    Allerdings denke ich jedes Mal beim Einsatz: „Sollte ich nicht einfach ProseMirror verwenden?“
    Wenn man schnell eine Editierfunktion braucht, ist Quill eine gute Übergangslösung. Sobald die Anforderungen an diese Funktion aber wachsen, kalkuliert man im Hinterkopf ständig mit ein, dass irgendwann ein Migrationsplan nötig wird.

    • Es wäre gut, wenn man den Einreichungslink auf [1] ändern könnte. Eigentlich geht es nämlich um die neue Version.
      Nebenbei frage ich mich manchmal, warum sich ein Rich-Text-Editor nicht standardisieren lässt.
      [1] https://slab.com/blog/announcing-quill-2-0/
    • Ich schaue mir gerade ProseMirror an, vor allem über tiptap2, das offenbar einen guten Wrapper darum bietet.
      Der tatsächliche Umstieg wirkt aber aufwendig, und mich würden die Erfahrungen anderer interessieren.
    • Wir mussten im Job Rich-Text-Bearbeitung implementieren und haben mehrere Optionen geprüft. Quill war einer der frühen Kandidaten, die wir uns angesehen haben, am Ende haben wir uns aber für ProseMirror entschieden.
      Ausschlaggebend waren der sehr niedrige Abstraktionsgrad und die umfangreiche Dokumentation; es erinnerte ein wenig an D3.
      Danach haben wir Custom Nodes, Custom Commands und eine eigene Toolbar gebaut, es mit Markdown und eigenen Markdown-Plugins integriert, und mit etwas Glue Code lässt es sich auch recht sauber an Vue anbinden.
      Bisher bin ich mit der Entscheidung für ProseMirror sehr zufrieden.

  • Ich weiß nicht, ob es seltsam ist, dass ich extrem starke Meinungen dazu habe, wie ein Texteditor die Return-Taste behandeln sollte.
    In einfachem Text ist Return eine neue Zeile, in formatiertem Text sollte Return ein neuer Absatz sein.
    Wenn man eine neue Zeile will, nimmt man Shift+Return.
    In früheren Versionen war das ein großes Problem, und ich weiß nicht, wie stark man dieses Verhalten heute anpassen kann.
    Ich gebe zu, dass ich mich zu sehr daran aufhänge, aber TipTap hat für mich gut gepasst.

    • Es sollte leicht konfigurierbar sein, aber ich glaube nicht, dass dieses Verhalten der Standard sein sollte.
      Es ist nicht allgemeiner, sondern tritt nur auf, wenn man in bestimmten Blocktypen Return drückt.
      Shift+Return ist auf Mobilgeräten zudem nicht nutzbar, und es ist lästig, eine versteckte Tastenkombination kennen zu müssen, um das gewünschte Verhalten zu bekommen.
      Der Rich-Text-Editor von Reddit funktioniert so, und ich gerate ständig damit aneinander.
      Am Ende geht es nur darum, zu vermeiden, dass man zweimal Return drücken muss.
      Ich verstehe die Eleganz, Nutzer immer innerhalb eines Absatzes zu halten und sie mit Shift+Return explizit einen Zeilenumbruch wählen zu lassen, aber in einem so schwierigen Bereich wie Rich-Text-Editoren würde ich User Experience über Eleganz stellen.
    • Stimme völlig zu. Selbst diese Shift+-Unterstützung ist wacklig, aber damit könnte ich vermutlich noch leben.
      Die Absatzbehandlung in den Quill-Beispielen wirkt unbeholfen.
    • Wenn ich das richtig gelesen habe, scheint es dem Verhalten der Texteingabefelder in Confluence/JIRA zu ähneln.

  • Die Dokumentation ist hervorragend. Ich wünschte, jedes Open-Source-Projekt hätte eine Seite wie „Why Quill“[1], damit man schnell versteht, ob die Projektphilosophie zu den eigenen Zielen passt.
    Noch besser wäre etwas wie „Why Not Quill“, damit man schnell erkennt, in welchen Situationen es nicht gut passt.
    Jedes Projekt geht Kompromisse ein; wenn man diese direkt und klar kommuniziert, haben Nutzer eine bessere Erfahrung.
    [1] https://quilljs.com/docs/why-quill

  • Aus dem Link allein ist es nicht offensichtlich, aber vermutlich wurde der Beitrag hochgevotet, weil v2 vor drei Tagen veröffentlicht wurde.
    Ich habe bis vor Kurzem mit Quill v1 gearbeitet, und das war ziemlich unschön.
    Tabellen per Plugin zum Laufen zu bringen war schmerzhaft, und es gab auch merkwürdige Scroll-Probleme.
    Ich hoffe, v2 hat vieles davon behoben, aber ich werde weiter TinyMCE verwenden, das funktional mehr bietet.

    • Ich mag TinyMCE ebenfalls und habe vor sechs Monaten einen Quill-Editor durch TinyMCE ersetzt.
      Allerdings fand ich es ärgerlich, dass man selbst bei statischem JS auf der Website einen API-Key braucht, und unangenehm war auch, dass sie vor ein paar Tagen die „Nutzung“ für Editor-Renderings im kostenlosen Tarif stark reduziert haben [0].
      Mich würde interessieren, ob das kein Problem ist.
      [0] https://news.ycombinator.com/item?id=40044544

  • Zuerst habe ich nicht verstanden, warum Quill wieder auftaucht, aber jetzt habe ich gesehen, dass die lange erwartete Version 2.0 vor drei Tagen veröffentlicht wurde.
    Siehe https://slab.com/blog/announcing-quill-2-0/

    • Ich finde, dieser Link und der Titel wären der bessere Einstiegspunkt für das Thema.

  • Bei einem früheren Projekt sind wir wegen der Nutzung von Quill ziemlich auf die Nase gefallen.
    Persönlich denke ich, dass das Problem darin lag, die Grenzen des Editors im Vergleich zu den Projektanforderungen nicht ausreichend geprüft zu haben; aber auch die Art, wie die Dokumentation die Erweiterbarkeit der Library betont, kann offenbar zu Schaden führen.
    Wenn man innerhalb dieser Grenzen bleibt, ist es eine hervorragende Library. Zu komplexe Dinge wie etwa verschachtelte Inhalte sollte man zum Beispiel vermeiden.
    Ein Abschnitt wie „Why You Should NOT Use Quill?“ auf der Website wäre wohl ziemlich hilfreich.

  • Es hängt sicher vom Fall ab, aber ich habe nicht vor, Quill noch einmal in einem Produktionsprojekt einzusetzen.
    Ich habe etwa 2016 angefangen, Quill 1.x zu verwenden, und war anfangs ziemlich angetan.
    Als ich twitterte, dass ich Quill evaluiere, meldete sich Jason von sich aus und half auch bei Fragen zur Implementierung.
    2019 hatte ich dann mit einigen Bugs zu kämpfen, Quill 1.x war im Wartungsmodus, und für 2.0 gab es praktisch keine Dokumentation [1].
    Ich kontaktierte Jason auf Twitter, um ein Gefühl für den Zeitplan zu bekommen [2], bekam aber im Grunde eine Antwort nach dem Motto: Hau ab.
    Seine Firma Slab hat mich inzwischen ebenfalls auf Twitter blockiert; vielleicht war eigentlich gedacht, mich nur vom persönlichen Account aus zu blockieren.
    Wenn man ein Startup aufbaut, hat jeder mal stressige Tage, also war mein Timing vielleicht schlecht.
    Meine Vermutung ist, dass er sich auf seine eigene Firma konzentrierte und gerade noch genug Zeit hatte, Quill für den internen Gebrauch am Leben zu halten, aber kaum Spielraum, es als Open Source zu releasen. Wenn das so war, hätte ich mir gewünscht, dass er es einfach offen sagt.
    Fünf Jahre später ist Quill v2 endlich erschienen, und ich freue mich, dass Slab immer noch existiert.
    Ich hoffe, dass es künftig die Kapazität gibt, Quill öffentlich zu warten; aber wenn man es in Produktion einsetzen will, sollte man prüfen, wie stark das Commitment beim Support ist, und auch einen Plan haben, falls die Antworten ausbleiben.
    Falls Jason in diesem Thread ist: keine bösen Gefühle, die Sache ist längst vorbei. Du kannst es ignorieren oder deine Sicht ergänzen.
    [1] https://github.com/quilljs/quill/issues/2435
    [2] https://twitter.com/nickbaum/status/1177240103925796865

    • Ich habe keine Erfahrungen mit Jason, aber ich habe viel zu viel Zeit damit verbracht, Quill-Code zu lesen, um seltsames Verhalten mit Workarounds zu patchen.
      Das war umso frustrierender, weil man eine Rich-Text-Editor-Library statt einer Eigenentwicklung ja gerade verwendet, um solche Dinge zu vermeiden.
      Zu v2 kann ich nichts sagen, aber der v1-Code ist nicht besonders gut strukturiert.
      Es gibt auch grundlegende Funktionen, deren Implementierung ich aus Angst vor einer Million kleiner Bugs aufgeschoben habe.
      Das mit Abstand Beste an Quill ist das Delta-Format.
      Wer aber mehr als Fett/Unterstrichen/Kursiv möchte, dem würde ich ProseMirror empfehlen.

  • Verwandte Beiträge. Gibt es noch mehr?
    Announcing Quill 1.0 - https://news.ycombinator.com/item?id=12437345 - September 2016, 82 Kommentare
    Quill – A cross browser rich text editor with an API - https://news.ycombinator.com/item?id=10446865 - Oktober 2015, 47 Kommentare
    Quill – An Open Source Rich Text Editor with an API - https://news.ycombinator.com/item?id=7716376 - Mai 2014, 60 Kommentare

    • Bei dieser Ankündigung geht es um Version 2, die offenbar vor ein paar Tagen veröffentlicht wurde.

  • Ich erinnere mich, vor etwa einem Jahr in einem Projekt https://github.com/facebook/lexical verwendet zu haben, und größtenteils funktionierte es direkt gut.
    Gibt es einen Grund, Quill stärker zu bevorzugen?