@TomFrankly Great call on Gutenberg/media paste — that's what set a new standard for us too.We found that when source apps encode images in their own way (Word vs browser copy-paste), you need source-specific handling beyond just "paste and upload."
@ckeditor Makes sense. I assumed DOM tension was the shared root cause, but staying inside the backend framework is the bigger win. The Blazor example is clear: keeping editor state in C# removes a whole class of binding bugs.
@kettanaito The catch is those bones are exactly what's hard to keep: selection, caret, and IME come free with contenteditable, but on canvas you rebuild all three. Would love to see someone crack it.
@fuma_nama The MDX part is what catches me. Colored text and merged cells have no Markdown form. Curious what the escape hatch looks like when WYSIWYG goes beyond standard Markdown.
@liveblocks ProseMirror support is the part that catches my eye. Does LiveText sync custom node types with their attrs, or only the built-in schema? My editor leans heavily on custom nodes.
@tiptap_editor Very useful. Plugin interactions are the hardest part to debug in Tiptap: one plugin modifies the transaction, another one breaks, and you only see the final result. A panel showing what each plugin changed per transaction would save me hours.
@KasparsDancis Incremental highlighting is the right call. Canvas selection is the part that impresses me most, the browser handles that for me on the DOM side. Drag-selecting across wrapped lines must have taken a while.
Edit one word in a long list, and my diff view flagged the whole list as deleted + re-added.
Cause: text similarity returns 0 for strings over 200 chars — that guard is for base64 image URLs.
Fix: nested lists now align by type and diff their children recursively.
@PineDigitalCo "No context switch" is exactly right. The moment you leave the editor to find or build a block, you lose the content flow. Keeping everything inside the editing surface keeps blocks contextual.
@pavanpodila@vyuh_tech Building from scratch teaches you things no paper ever could. Out of everything you listed, which one forced you to rethink your initial approach the most?
@mbjschirp Genuine question — what would make a rich text editor not feel like a process mistake for you? Is it the interaction model, the output format, or just that you'd rather stay in code?
The real challenge wasn't supporting 6 frameworks. It was keeping all 6 in sync.
Vue 2 Options API, Vue 3 Composition API, React hooks, Angular change detection, Svelte reactivity — each one works differently.
Took longer than I expected.
@duncanfaulkner Proper roving tabindex on a rich text toolbar is harder than it looks — nice to see someone getting it right. Are you planning to add more block-level nodes like tables and code blocks, or keeping it lean?
@abd_mukadam Static renderers for editor output are so underrated — most people just dump raw HTML and wonder why the styling breaks on different screens. What made you split it out as a separate package instead of keeping it built-in?
@svenadlung DevTools for editors is such an underserved space. Top of my inspection wishlist: node/mark schema at the current selection, active plugin state, and a real-time transaction log. Is this Chrome-only or planning Firefox support too?
@euboid@tiptap_editor Diffing two ProseMirror docs outside a collab context is surprisingly under-served. I built a snapshot + version compare system for exactly this — block-level diff with scroll-synced side-by-side view. You can try it at cyteeditor.com/playground. Curious what your use case was?
324K Followers 525 FollowingProgressive JavaScript framework for building modern web interfaces. Created by @evanyou, maintained by https://t.co/GBCO6zpR6W.
595K Followers 176 FollowingSharing links, news, and humor about JS, TypeScript, and related front-end stuff 💛
Not affiliated with Oracle or Larry Ellison.