Author of Quill here. Interested in hearing Marjin’s thoughts but here are some of my main observation is at a high level Prosemirror is much more willing than Quill to sacrifice simplicity for power. This value difference manifests in the target audience, architecture and API design:
Quill can be used for the get going quickly drop in use case. Prosemirror specifically warns against this: “If you're looking for a simple drop-in rich text editor component, ProseMirror is probably not what you need. (We do hope that such components will be built on top of it.) The library is optimized for demanding, highly-integrated use cases, at the cost of simplicity.”
Prosemirror’s schema, as documented, is more flexible than Quill’s. Prosemirror appears to allow anything, whereas Quill imposes some constraints. For example Quill requires all nodes to either be a leaf and cannot have children or a container and must at least one child. There cannot be a node that can optionally have children as is allowed in Prosemirror. In my experience the constraints Quill imposes lead to a more consistent and bug free experience across browsers. I will be curious to try out the edge cases I have encountered at this new 1.0 Prosemirror to see if it handles them the way an end user typist would expect. If Quill can benefit from a shift in the flexibility in its schema, it will do so.
Quill is far more battle tested. Slack, Salesforce, LinkedIn, Intuit and many others are using Quill in their main user-facing production products, not an internal employee only tool. Prosemirror has a great start with the NY Times but there is a large difference in adoption at the moment.
Sure. I think it's fair to say that ProseMirror is a more ambitious project, reaching for features that aren't part of (even the new crop of) existing libraries.
* Firstly, the schema feature. ProseMirror's content expressions [1] are a regular language that can be used to describe a sequence of child nodes. The editor will make sure the content of the node always matches this expression. This allows significantly more interesting things than Quill's array of allowed children—i.e. "heading block＊ section＊" to say that a given node must first contain a heading, then any number of blocks (say, paragraph, list, figure, aside, etc), then any number of subsections. (HN's half assed markup doesn't seem to allow escapes on asterisks, so I used ＊'s)
* Quill uses imperative data structures and events throughout. I've really become convinced of the power of functional Redux-style architectures for this kind of component—I've found it makes it much easier to write bullet-proof extensions. (This may be a matter of taste.)
* Table support doesn't appear to exist in Quill yet. A table module with features like colspan/rowspan and cell selections has been written as a relatively small plugin [2] for ProseMirror.
* Exposing all the system interals (and designing them in a way that makes them usable), rather than hiding stuff behind a small API, means that people can do really advanced things as extensions. This was a lot of work, and wasn't initially planned, but the kind of users we're aiming for require it.
* As for real-world use, yeah, we've just released 1.0, your project is older. Still, our users (including Atlassian, which has already rolled out ProseMirror in user-facing products) have been doing very advanced stuff already, and my ten years of experience with CodeMirror mean that I more or less know what I'm going to run into.
(Also your website claims, wrt to ProseMirror: "Quill’s architecture is more modular, allowing for easier customization of internals. Core modules that handle basic functionality like copy/paste and undo/redo can be swapped out in Quill." I think that's a mischaracterization.)
Also, ProseMirror is definitely seeing wider adoption than the parent implies. Even from this thread alone, we're seeing Atlassian and startups pop-up attesting to its good design.
Your points are fundamentally correct, and I would argue that your parent is attempting to limit the potential of ProseMirror, in order to preserve the need for Quill.
The issue isn't so much about room as it is about bandwidth. Specifically, mental bandwidth.
There use to be loads and loads of JS frameworks of dubious merit and with equally dubious developers. Now there's generally an agreed upon few (Angular 2.0, React, Vue) that are pretty solid and seem to be helmed by mostly sensible people.
Unfortunately, we're still in the early stages of open-source WYSWIG/WYSWIM;. By the later stages, I hope we can thin out the technically unsound editors with insecure authors.
Quill can be used for the get going quickly drop in use case. Prosemirror specifically warns against this: “If you're looking for a simple drop-in rich text editor component, ProseMirror is probably not what you need. (We do hope that such components will be built on top of it.) The library is optimized for demanding, highly-integrated use cases, at the cost of simplicity.”
Prosemirror’s schema, as documented, is more flexible than Quill’s. Prosemirror appears to allow anything, whereas Quill imposes some constraints. For example Quill requires all nodes to either be a leaf and cannot have children or a container and must at least one child. There cannot be a node that can optionally have children as is allowed in Prosemirror. In my experience the constraints Quill imposes lead to a more consistent and bug free experience across browsers. I will be curious to try out the edge cases I have encountered at this new 1.0 Prosemirror to see if it handles them the way an end user typist would expect. If Quill can benefit from a shift in the flexibility in its schema, it will do so.
Quill is far more battle tested. Slack, Salesforce, LinkedIn, Intuit and many others are using Quill in their main user-facing production products, not an internal employee only tool. Prosemirror has a great start with the NY Times but there is a large difference in adoption at the moment.