Comment by jhchen | Hacker News Reader

Comment by jhchen | Hacker News Reader

Parent Full thread

(Quill maintainer here)

There was a separate comment about Draft, so I answered that one there and will just comment on ProseMirror here.

ProseMirror's main is insight is the need to maintain a document model in parallel with the actual DOM. While most modern editors also do this, ProseMirror also allows their document model to be extended and customized, which only Quill and possibly Draft[1] is also capable of. I think this is the right idea and foundation to build on top of (Quill also made this choice).

I don't think it's fair to judge implementation or specifics beyond its ideas just yet since it is still in the development stages and things can change and improve, as stated on its README:

"NOTE: This project is in BETA stage. It isn't thoroughly tested, and the API might still change across 0.x releases. You are welcome to use it, but don't expect it to be very stable yet."

[1] "Possibly" because Draft uses inline styles and only two levels of content (block and inline) so it's far more limiting.

Thanks. One issue I believe ProseMirror has yet to solve well is the concept of embeddable widgets.

For example, I should be able to embed a "video object", which represents some content that isn't directly editable, and which may exist somewhere else, and is perhaps internally represented using opaque ID that references some backing store. I want to be able to render this as a nice little video renderer that has a little edit button or a context-menu, and which can be edited to change its size, select a time subrange, subtitles and so on. The document editor should treat it as an opaque object that can render itself and marshal/unmarshal itself somehow, and which can be copied, pasted and moved around. Ideally it should also be possible to offer UI interactions, such as mouse clicks (for resizing).

Does Quill handle this better?

Quill does let you define Embed blots which essentially hand back complete control over the corresponding DOM node container. For example the formula module uses KaTeX to render formulas and it does not care what KaTeX does to descendant DOM nodes. You could attach listeners and add editing UIs within this if desired. I believe this approach should allow you to implement what you are describing.

Looks to me like a big difference is that Quill is HTML/DOM-oriented, whereas ProseMirror has a generic document model that is format-agnostic and allows custom parsing/serialization.

What does this mean and how did you come to this conclusion? There are a lot of broad adjectives in the sentence but it doesn't sound right.

Well, as far as I can tell, Quill doesn't have a document model as such. It only has a flat sequence of deltas, which are runs of text with associated formatting attributes.

ProseMirror, on the other hand, explicitly defines a document model as part of its API, arranged as a tree (DAG). This implies you can do things like represent LaTeX natively without having to flatten it, thus preserving the original structure. For example, an entire \section or \chapter could be a single node. (I don't know if this works in practice.) In theory, its design doesn't require a hard distinction between "text" and "embeds" because everything is both.

The benefit is that don't need a complicated, potentially lossy translation between the flat and non-flat versions. For example, if you're doing LaTeX, and there's a \title and \author in the document, you could keep this around as non-visible nodes that are preserved in the model and get serialized back when you export the edited document. (To be fair, I don't know if Quill supports invisible embeds, perhaps it does?)

Most editors nowadays maintain a parallel structure to the DOM. And since the DOM is a tree, that structure is also a tree. Quill's is Parchment[1] and goes a step further by also having an API and allow defining new nodes, which ProseMirror (and maybe Draft) also does.

Deltas are a simple, iterable output format for Quill. In practice it is much nicer to deal with this in many use cases than the Parchment tree.

[1] https://github.com/quilljs/parchment

Reply on news.ycombinator.com