Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How does Quill compare technically with DraftJS?


(Quill maintainer here)

Draft’s own description of itself is "Rich Text Editor Framework for React" and is more comparable with Parchment[1], both being a foundation in which you can build a rich text editor. But there are many pieces missing for it to be a full fledged editor like Quill.

* UI Draft only has buttons you can toggle for formats. There are no dropdowns to select which header size—just six h1, h2, h3, h4, h5, h6 buttons. There are no tooltips or link, video, or image UIs to assist with editing.

* API - Quill’s API is designed for the editing use case. Draft is built on React and inherits many primitives and ideas that are more appropriate for websites, rather than linear content like text. Which APIs is nicer for which use case may be subjective so I will just link Quill’s API’s [2] and Draft’s API [3] and ask the reader to think of some common tasks, like making a range of text bold, and try to figure out how to accomplish these tasks from reading through the respective APIs.

* Markup - With the exception of nested lists, Quill’s markup is clean and semantically correct. Draft uses <span> tags with inline styles with lots of attributes for bookkeeping.

[1] https://github.com/quilljs/parchment [2] http://quilljs.com/docs/api/ [3] https://facebook.github.io/draft-js/docs/overview.html


(worked with both Draft and pre-1.0 Quill)

I'm not sure these points are fair...like you said Draft is a primitive to build editors and has much less out of the box, so it's not a good comparison. However:

* Draft does not only have buttons for toggling formats - it has nothing. The point is that you can build a UI and functionality around it to do arbitrarily complex things with it. The way it's described here makes it sound like the entirety of what you can do with Draft is toggle formats, which is not at all true. Like you said this is where Draft and Quill become most apples and oranges, it becomes a trade-off between finer grain control and more functionality out of the box.

* Agreed that API preference is subjective, Draft definitely has some parts of its API that could be more clear or could be better aligned with what it's trying to accomplish.

* A really important thing to note with markup that's misrepresented here is that Draft doesn't output that markup as a result - it's only used to render the content in the editor. The content is stored in an immutable data structure that lets you leverage a ton of React's upsides in terms of rendering performance. That structure can also be easily turned independent of the rendered UI into clean HTML to be persisted.


I do not believe it is a fine control vs out of the box tradeoff. Draft gives you one. Quill gives you both. Previously Quill was limited in what content it could understand but this is the major change in 1.0. I'd encourage you to take another look.

Regarding the third point on markup, everything you say is true, except the first part about misrepresentation. When I said markup I am precisely talking about the HTML markup used to render the contents of the editor. Some people do care about the HTML markup being semantic during the edit session. Sounds like you don't or are okay with computing this yourself, and that's fine, but again this is extra work for the end user. Quill also has an internal state[1] that is easy to iterate over and convert into whatever output/markup.

[1] http://quilljs.com/guides/working-with-deltas/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: