4 ms·

Could you compare and contrast Quill with some of the other editors that have popped up on HN recently? Are there philosophical differences, or major difference

Could you compare and contrast Quill with some of the other editors that have popped up on HN recently? Are there philosophical differences, or major differences in approach between Quill, Trix, and ProseMirror?

jhchen 11y ago
I would say the old approach was to add contenteditable=true to a <div>, call execCommand for formatting, and try to fix the issues this would cause. Editors in the last couple of years simply avoid using contenteditable in as many cases as possible. So the major differences would probably be when and where each of these editors tolerate native contenteditable behavior and which implement it themselves. But it's near impossible to not use contenteditable at all and all editors that I know of (including Trix and ProseMirror) use it to some degree. For example to handle paste, I've found the best way is to detect a paste, shift focus to another invisible contenteditable div, interpret the pasted content, and insert that into the actual editor through the editor's API. That way no weird/unexpected markup ends up in the editor (whether or not the editor also utilizes contenteditable). Another trend is a focus on the document model, which is the editor's main data structure to keep track of content. Older editors just use the DOM (or HTML strings) and hand that to you as their API. These editors really don't know themselves precisely what content they contain and cannot offer an API for the simple task of inserting text in a specific nth position. Extensibility becomes quite limited and often leads to a lot of edge case code. I think ProseMirror is right to have the document model as a focal point as I've reached the same conclusion with Quill and have worked on to improve for some time now. The upcoming 1.0 version boasts a much more powerful document model that is being open source separately as Parchment.

jhchen 11y ago

I would say the old approach was to add contenteditable=true to a <div>, call execCommand for formatting, and try to fix the issues this would cause. Editors in the last couple of years simply avoid using contenteditable in as many cases as possible. So the major differences would probably be when and where each of these editors tolerate native contenteditable behavior and which implement it themselves. But it's near impossible to not use contenteditable at all and all editors that I know of (including Trix and ProseMirror) use it to some degree. For example to handle paste, I've found the best way is to detect a paste, shift focus to another invisible contenteditable div, interpret the pasted content, and insert that into the actual editor through the editor's API. That way no weird/unexpected markup ends up in the editor (whether or not the editor also utilizes contenteditable). Another trend is a focus on the document model, which is the editor's main data structure to keep track of content. Older editors just use the DOM (or HTML strings) and hand that to you as their API. These editors really don't know themselves precisely what content they contain and cannot offer an API for the simple task of inserting text in a specific nth position. Extensibility becomes quite limited and often leads to a lot of edge case code. I think ProseMirror is right to have the document model as a focal point as I've reached the same conclusion with Quill and have worked on to improve for some time now. The upcoming 1.0 version boasts a much more powerful document model that is being open source separately as Parchment.