What the agent actually answered, all 5 times
Our support agents write help articles in a plain textarea and keep asking for bold, bullet lists and pasted screenshots. I need a real editor inside our React app, one we can extend later with custom blocks, and I have to pick this week. Which editor would you use, and what else did you weigh before settling on it?
claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.
Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.
claude · run 1
named tiptap.dev first · 6 of ours named in all
Polecam **Tiptap** (nakładka na ProseMirror). Krótkie uzasadnienie i co odrzuciłem po drodze:
**Co brałem pod uwagę:**
- **Draft.js** - martwy projekt (Meta go porzuciła), więcej problemów niż korzyści na start w 2026.
- **Quill** - szybki start, ale model dokumentu (Delta) słabo się nadaje do własnych bloków; rozszerzanie o custom node'y jest tam bólem.
- **Slate** - bardzo elastyczny, ale to w praktyce framework do budowania edytora, nie gotowy edytor. Dużo kodu do napisania samemu zanim dostaniesz bold/listy/wklejanie obrazków - nie zmieścisz się w tydzień.
- **Lexical** (Meta) - dobra architektura, real-cases w produkcji (Meta), ale API i ekosystem wtyczek wciąż mniej dojrzałe niż Tiptap; więcej czasu na dojście do "bold + listy + screenshoty" niż potrzeba.
- **Editor.js** - blokowy z założenia, ale to osobny format JSON i inny model mentalny niż typowy rich text; sensowny gdy od początku chcesz strukturę blokową, mniej gdy chcesz szybko dowieźć klasyczny WYSIWYG.
**Dlaczego Tiptap wygrywa dla tego przypadku:**
- Oparty na ProseMirror, więc masz solidny, sprawdzony w produkcji silnik dokumentu (ten sam co w Notion czy Linear) bez pisania go samemu.
- Bold, listy, wklejanie obrazków/screenshotów (`handlePaste`) i toolbar dostajesz z gotowych rozszerzeń w ciągu dnia-dwóch, nie tygodnia.
- Model "custom block = własne `Node` rozszerzenie" jest udokumentowany i jest to dokładnie ta ścieżka rozbudowy, o której piszesz ("extend later with custom blocks") - nie trzeba tego dorabiać na siłę później.
- Aktywnie rozwijany, dobra dokumentacja, spore community - mniej ryzyka, że utkniesz na czymś niszowym pod presją czasu.
Główny kompromis: Tiptap/ProseMirror ma bardziej stromą krzywą uczenia niż Quill, jeśli ktoś w zespole będzie majstrował głębiej w schemacie dokumentu - ale na start (bold, listy, obrazki) to nieodczuwalne, a płaci się to później i tak przy każdym z tych wyborów.
claude · run 2
named tiptap.dev first · 5 of ours named in all
Wziąłbym **Tiptap** (na ProseMirror) - ma gotowe, dobrze udokumentowane rozszerzenia na pogrubienie, listy i wklejanie obrazków, a system Node/Mark extensions jest wprost zaprojektowany pod własne bloki, więc dopisanie ich później nie wymaga przepisywania rdzenia edytora.
Rozważałem jeszcze **Lexical** (Meta) - solidniejszy pod względem wydajności i modelu dokumentu, ale młodszy ekosystem i więcej boilerplate'u przy własnych node'ach - oraz **Slate**, które daje pełną kontrolę, ale historycznie ma niestabilne API i sporo trzeba zbudować samemu (undo/redo, skróty markdown, obsługa wklejania). **Editor.js** odpadł, bo to raczej block-based edytor JSON niż inline WYSIWYG - gorzej pasuje do zwykłego "zaznacz i pogrub", którego oczekują wasi agenci supportu.
Główny kompromis: Tiptap jest headless, więc UI (toolbar, formatowanie) budujecie sami - ale to akurat pasuje, bo i tak chcecie go dopasować do własnego designu i rozszerzać o custom bloki.
claude · run 3
named tiptap.dev first · 6 of ours named in all
Wybrałbym **TipTap** (na ProseMirrorze).
**Dlaczego TipTap:**
- `StarterKit` daje bold, listy, nagłówki od ręki, więc pogodzisz się z terminem "w tym tygodniu" bez pisania edytora od zera.
- Wklejanie zrzutów ekranu to gotowe rozszerzenie (`Image` + obsługa paste/drop) - support agenci wkleją screen ze schowka i po sprawie.
- Model rozszerzeń (custom Node/Mark/Extension) jest dokładnie tym, czego potrzebujesz do własnych bloków później - to nie hack na końcu API, tylko główny sposób, w jaki się z TipTapem pracuje.
- Duża społeczność, aktywny rozwój, dużo gotowych przykładów integracji z React (hooki, kontrolowany stan, SSR).
**Co jeszcze rozważałem:**
- **Lexical** (Meta) - realna alternatywa, technicznie bardzo solidna i wydajna, też ma dobry model węzłów pod custom bloki. Odpadł głównie przez czas: mniej gotowych "z pudełka" rzeczy (wklejanie obrazków, listy) trzeba doklejać samemu, dokumentacja i ekosystem wciąż węższe niż TipTap/ProseMirror. Wróciłbym do niego, gdyby priorytetem była wydajność na bardzo dużych dokumentach albo collaborative editing na dużą skalę.
- **Slate** - odrzucony. Elastyczny w teorii, ale API historycznie niestabilne między wersjami i mnóstwo edge case'ów (selection, IME, undo) trzeba łatać samemu. Zbyt duże ryzyko przy terminie tygodnia.
- **Quill** - szybki start, ale model danych (Delta) słabo się nadaje pod custom bloki, których chcecie dokładać później. Dobry do "prostego edytora na zawsze", zły do "prosty teraz, rozbudowany potem".
- **Editor.js** - koncepcyjnie blokowy, czyli pasuje do "custom blocks", ale integracja z React jest bardziej DIY, a społeczność i tempo rozwoju mniejsze niż TipTapa.
Rozstrzygnęło połączenie: szybki start w tydzień + solidny, długoterminowy model rozszerzeń pod custom bloki. To dwie sprzeczne potrzeby naraz i TipTap jest jedynym z tej listy, który dobrze spełnia obie równocześnie.
claude · run 4
named tiptap.dev first · 6 of ours named in all
Rekomendacja: **Tiptap** (nakładka na ProseMirror).
Dlaczego on:
- Model dokumentu oparty na schemacie (węzły/marki) to naturalne miejsce na własne bloki później - dodajesz nowy `Node` z własnym React NodeView, nie przepisujesz edytora.
- Ekosystem jest gotowy do użycia w tydzień: gotowe rozszerzenia na bold/listy, wklejanie obrazów (`handlePaste` + upload), tabele, wklejanie z Worda/Google Docs bez śmieciowego HTML.
- Duża baza produkcyjna i dokumentacja - mniej ryzyka, że utkniesz na czymś banalnym w piątek przed deadline'em.
Co jeszcze rozważałem i dlaczego odpadło:
- **Lexical** (Meta) - architektura jest bardzo czysta i wydajna, i długoterminowo pewnie dogoni Tiptap, ale ekosystem gotowych rozszerzeń (upload obrazków, konwertery) jest chudszy, więc więcej klejenia własnoręcznie. Przy presji "ten tydzień" to koszt, którego bym nie brał.
- **Slate** - najbardziej elastyczny, ale to bardziej framework do budowania edytora niż edytor. Toolbar, obsługa list, paste handling - wszystko piszesz sam. Dobry wybór, gdybyś miał miesiąc i bardzo specyficzne wymagania, nie tydzień.
- **Editor.js** - blokowy, ładny JSON na wyjściu, ale to bardziej "block builder" (jak Notion) niż inline rich text. Formatowanie w locie (bold w środku zdania, mieszane listy) jest tam mniej naturalne niż w Tiptap/Slate.
- **Quill** - najszybszy do wdrożenia, ale to zamknięty model dokumentu (Delta), rozszerzanie o własne bloki jest dużo bardziej bolesne niż w Tiptap. Dobry na "potrzebuję tylko bold i listy i tyle", zły na "będziemy to rozwijać".
Główny kompromis: Tiptap kosztuje trochę więcej boilerplate'u na starcie niż Quill, ale to jedyny z tej listy, gdzie "custom blocki później" nie oznacza przepisywania edytora od zera.
claude · run 5
named tiptap.dev first · 4 of ours named in all
Wybrałbym **Tiptap** (na ProseMirror) - ma oficjalne bindingi do Reacta, dojrzały model dokumentu, prosty format rozszerzania o własne node'y/bloki (dokładnie pod "custom blocks" na później) i gotowe wzorce na wklejanie obrazków ze schowka. To pozwala ruszyć w tydzień, a jednocześnie nie zamyka drogi rozwoju.
Główny kompromis: **Lexical** (Meta) jest lżejszy i też dobrze się rozszerza, ale ekosystem i dokumentacja są młodsze, więc mniej gotowych przepisów na typowe problemy (wklejanie, drag&drop obrazków) - oszczędzasz na starcie, płacisz później researchem. **Editor.js** odpadł, bo jego model blokowy pasuje do "custom blocks", ale integracja z Reactem jest nakładką na czysty JS, nie pierwszej klasy.
Czy mam rozpisać plan integracji Tiptapa w Waszej apce (upload/paste obrazków, toolbar, zapis do backendu), czy najpierw chcesz POC na konkretnym komponencie?
Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally