
Announcing Quill 1.0 - anurag
https://quilljs.com/blog/announcing-quill-1-0/
======
jhchen
Hey HN - Quill maintainer here. The 1.0 release has been a huge effort with
spanning almost a year, over a thousand commits, and hundreds of issues
closed, since it's announcement[1].

Feel free to AMA.

[1] [http://quilljs.com/blog/the-road-to-1-0/](http://quilljs.com/blog/the-
road-to-1-0/)

~~~
BafS
Congratulations for this project!

I have tried quite a few others editors on mobile (android Firefox) but none
of them seems to work correctly, Quill is much better but still has some
issues (for eg. If I type 'qwe' I have 'weq'), will you take in account the
mobile browsers for the future development? Or what is/are the worst
limitations/bugs?

~~~
jhchen
I'm sorry you are experiencing problems on your device/browser but I don't
think it's fair to say Quill does not take mobile browsers into account.

I personally have a Nexus 7 running Android 5.1, which I use to test Chrome
and Firefox. I also have an iPad and iPhone that I use to test Safari. Quill
works great in all of these platforms. Quill also uses SauceLabs to automate
testing of every push. I have filed browser bugs in the past on mobile
Firefox, but have been told sometimes the issue is from the keyboard driver
itself, which is two layers from the browser. With the distribution of Android
versions and the differences between devices, it is cost prohibitive for an
open source project to test and catch all Android issues.

Of course none of this explanation helps your particular situation. What you
can do to help your particular situation is:

1\. File a bug report so others can reproduce, identify, and fix the issue:
[https://github.com/quilljs/quill/issues/new](https://github.com/quilljs/quill/issues/new)

2\. Encourage SauceLabs to support Firefox on Android as a testing platform.

~~~
rcheu
It's very difficult to make a fully working browser/webview based editor on
Android. Every keyboard interacts with applications differently, sometimes
differing significantly between keyboard versions. I think a rewrite of the
Android keyboard composition interface is needed. Most of the issues occur
because the keyboard needs to keep track of the document state itself, and has
race conditions/inconsistencies with the editable which maintains the "true"
state.

All web based rich text editors on Android right now (Quill, Draft.js, Dropbox
Paper, Quip, etc.) have similar problems. One easier to reproduce problem is
to make a list and then exit the list by pressing enter twice. The next time
you backspace a few characters, the composition will be messed up (cursor will
jump around, characters get duplicated, etc.) There are other issues too--
oftentimes the keyboard will lose focus, backspacing will paste in characters,
jumping cursors, etc. These issues are keyboard/browser version specific too,
most of them disappear if you use Samsung's keyboard instead of the Google
one.

For Quora's Android editor I spent some time fixing all the issues I could
find with the latest Google keyboard+WebView, and fixed the majority. I built
the open source version of Google's keyboard (LatinIME), and a fork of
Chromium (Crosswalk) for the WebView so that I could debug both, which worked
pretty well. Then, Google updated the keyboard which introduced bugs, but
didn't update the open source project, making it difficult to fix the new
issues. There's also a separate rewrite in Chromium to use a separate thread
for the IME, which will change behavior again.

------
pfooti
As a long-time user of Quill, I must say: Congratulations to jhchen and
everyone else who worked on the project.

I use Quilljs because it's a great implementation of a modern-thinking WYSIWYG
text editor. The underlying parchment[0] library helps a lot to separate out
the data model from the rendered view (instead of relying on contenteditable
to handle your data model, like many other classic rich text editors do). My
users type stuff in Quill, and my front end shoots data in the rich-text[1]
format back to the back-end. I have a small (and not great, but functional for
my needs) library [2] I wrote to convert rich-text back into HTML, so we never
actually store user-entered HTML entities in our database (which helps a lot
for things like protecting against XSS attacks, and since rich-text is just a
JSON object, I can do interesting database queries that are a bit trickier to
pull off if it had been HTML).

On top of all of that, Quill emits delta objects on user interaction (that
conform to an operational transform model), so it's pretty straightforward to
wire it into a concurrent editing system. This isn't batteries-included (you
have to deal with resolving the operational transforms yourself, which is of
course tricky) but it's a great start in that direction.

0:
[https://github.com/quilljs/parchment](https://github.com/quilljs/parchment)

1: [https://github.com/ottypes/rich-text](https://github.com/ottypes/rich-
text)

2: [https://github.com/ericeslinger/delta-transform-
html](https://github.com/ericeslinger/delta-transform-html)

~~~
sampl
I'd love to see some work on doing OT with Quill deltas.

A simple Quill + Meteor/Firebase bridge could be a pretty great, easy to spin-
up, real-time collaborative document editing tool.

~~~
nateps
Quill's OT type is compatible with ShareDB, which provides a simple to use
backend that takes care of all this coordination. Here is a simple example of
using the two together:
[https://github.com/share/sharedb/tree/master/examples/rich-t...](https://github.com/share/sharedb/tree/master/examples/rich-
text)

------
neoCrimeLabs
"Announcing Quill 1.0" is such a nondescript title that tells nobody what
Quill actually is. Why not make the title something like "Announcing Quill
1.0, web based WYSIWYG text editor"

~~~
nacs
HN prefers to use the titles from the original site.

~~~
gelezinisvilkas
I still dont get why people dislike original titles :/

~~~
harperlee
Well the context in HN frontpage is much lower than in the site, so I guess
your granparent was trying to correct that.

------
awgneo
I just added Quill to a side project site a few days ago, having spent almost
three months comparing different WYSIWYG editors. So many of these libraries
have gotten bloated over the years or simply have too many bugs. Quill just
works for me all of the time. Definitely check it out!

------
wwalser
Having spent literal years creating and maintaining large WYSIWYG projects
based on TinyMCE and CKEditor, I can not sing the praises of the latest
iteration of these editors highly enough. Between sidestepping contenteditable
almost entirely and maintaining a behind the scenes source-of-truth they
really have created a compelling and usable experience in all modern browsers.
Something I always aimed for but always knew was another year of work away.

Tiny was actually a well written project and several of the maintainers were
exceptional programmers and designers. I think they saw the way out but were
never able to get there because of the sheer number of features they would
have had to build parity for in order to ship something new. Not to mention
the fact that 5 years ago old versions of IE would have still been in the
picture.

Kudos on the project and 1.0 release.

~~~
erlend_sh
I just hope the time has finally come for WordPress to adopt one of these
modern editors.

------
devilsenigma
Technically how does Quill compare to Trix? [https://trix-
editor.org](https://trix-editor.org)

Is there any blog post on their design/architecture? I couldn't find one.

~~~
jhchen
Disclosure: As the maintainer of Quill, I am much more aware if its strengths
and have worked hard to limit its weaknesses.

The main idea behind Trix as stated in their README[1]:

"Most WYSIWYG editors are wrappers around HTML’s contenteditable and
execCommand APIs... Trix sidesteps these inconsistencies by treating
contenteditable as an I/O device: when input makes its way to the editor, Trix
converts that input into an editing operation on its internal document model,
then re-renders that document back into the editor. This gives Trix complete
control over what happens after every keystroke, and avoids the need to use
execCommand at all."

I think the first portion is only historically true. Everyone has figured out
contenteditable/execCommand alone is a problem and all notable editors I have
seen released in the past few years have reasonable solutions--Trix's solution
included. Quill is slightly different in that it prevents problematic
operations in the first place and reimplements them itself, such as enter and
backspace, but the main idea is the same: maintain a document model as the
source of truth, define operations to mutate it, and build an editing
experience on top of this.

Some strengths unique to Quill:

* _API_ Quill has the most powerful API of any editor I have seen. You can make any text or formatting change in any part of the editor at any time. Trix by contrast only allows changes to the current selection.

* _Modules_ Quill's internals are broken into modules[2] that themselves can be configured or even swapped out. Many modules also include their own APIs. Trix does not have documentation in this regard, but looking at its codebase, it does not appear designed to support major modification of its internals.

* _Formats /Content_ Quill's document model itself is customizable, which allows users to define their own formats or customize existing ones. This capability is what kicked of 1.0 development, now being released today. This gives Quill extensive coverage of well known formats (tables to my knowledge is the only missing one), but more exotic formats/content like formulas, tweets or syntax highlighted code is also supported. Some editor frameworks have this same idea, but lack the actual editor and UI on top of this so you have to build a big portion of functionality to realize the full benefits.

One main idea I'd like to highlight is this: Text is no longer written to be
printed. It is written to be rendered on the web—a much richer canvas than
paper. Quill 1.0 was designed and built to support this next generation
canvas.

[1] [https://github.com/basecamp/trix#different-by-
design](https://github.com/basecamp/trix#different-by-design) [2]
[http://quilljs.com/docs/modules/](http://quilljs.com/docs/modules/)

~~~
chrisper
I noticed that Trix allows me to paste images directly (with Google Chrome).
Can I do that with Quill?

~~~
amk_
If it is copied as HTML containing the image, yes. Usually works if copying
(via highlight) from a page. Otherwise:
[https://github.com/quilljs/quill/pull/821](https://github.com/quilljs/quill/pull/821)

------
sideproject
I noticed how adding an image doesn't actually upload it to the server, but
rather encodes it - which becomes a very large text. What implication does
that have? What if I have a very large text with many images?

I've been using CKEditor, which has been somewhat of a go-to text editor for
many and it's been around for many years. Its image uploading seems to work
relatively well.

~~~
delibes
jhchen gave a nice simple example of how to just insert a URL in this issue -
[https://github.com/quilljs/quill/issues/863](https://github.com/quilljs/quill/issues/863)

In theory it should be possible to integrate file upload and CDN APIs such as
Filestack/Filepicker or others.

------
lobster_johnson
Can anyone tell how Quill compares to Draft and ProseMirror?

~~~
jhchen
(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.

~~~
lobster_johnson
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?

~~~
jhchen
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.

------
paulddraper
I got excited because I thought it was a make release of MathQuill, web-based
WYSIWG equation editor with LaTeX support.
[http://mathquill.com/](http://mathquill.com/)

Ah well, this looks great too :)

------
jacquesc
I tried Quill out a couple months ago, but dropped it after I spent days
trying to get @mentions working with no luck.

Has been very difficult to find a solid js library to handle Facebook/Github
style @mentions and autocompletes. Anyone able to get mention support working
with Quill?

I've used at.js several times and have found it to be a buggy, ugly codebase.
I wouldn't recommend it.

~~~
pfooti
I've ended up manually handling @mentions on my own by writing a quill plugin
(unfortunately the plugin is closed-source for now), but basically it amounts
to:

Create a new parchment format to represent the atmention data, and how it
should be rendered. In my case, I also flagged it as read-only (because in
ours, @username ends up rendering as a styled User Actual Name once it's done
being selected, and I didn't want to allow users to edit the name displayed).

Create a widget that inserts that @mention formatted text in the quill data
model.

Figure out when to trigger the widget. I listen to document deltas, and decide
when the user has inserted a character inside a word that is at least four
characters long and starts with an @, and then pop up the menu which I
populate with users who match the text that's entered so far.

I ended up rolling my own because stuff like at.js is pretty heavyweight, and
probably every system has its own constraints on atmentions (how to populate
the username list, formatting for the list itself (avatars or no?), what to do
on atmention-insert (notifications processing), and how to represent an
atmention in finished text). So I found it was _way_ easier to do it on my
own, since the only thing I was really getting from something like at.js was a
pop-up autocomplete list anyway, and those are pretty trivial to do in either
vanilla javascript with css show/hide stuff, or (in my case, angular 1.x) in
your already-existing front end framework.

------
jrgoj
One editor feature I've been looking for is the ability to lock down a region
of text so that the user can drag the region around within the text or add
text before/after the text. However, the contents of the region can't be
edited nor deleted.

------
alphaomegacode
Congratulations to the Quill team.

Don't know if I'm doing something wrong but if you enter something like this:
3tan(x/2) + 4 = 0, the x/2 renders just like that versus 'vertically'.

Great release nonetheless

~~~
jhchen
Quill just uses KaTeX [1] (which an excellent project) for rendering formulas.
Not sure how it determines vertical vs horizontal fractions.

[1] [https://khan.github.io/KaTeX/](https://khan.github.io/KaTeX/)

------
Scarbutt
Is tables a hard problem on this editors or there is no demand for them?

~~~
cyberferret
This is my question too. A lot of users on my projects would like table
support. It seems to be a feature severely lacking in a lot of .js editors.

~~~
Tloewald
It's not terribly difficult, but it's hard to make it work nicely owing to the
quirks of contenteditable regions. Personally, I think that if you're serious
about writing a rich text editor for the browser you should avoid using
contenteditable (as per Google Docs, for example) which lets you do pretty
much anything. There are plenty of reasonably decent contenteditable-based
editors out there, and they're all similarly broken when you get to difficult
stuff.

------
jelder
How does Quill compare technically with DraftJS?

~~~
jhchen
(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](https://github.com/quilljs/parchment)
[2] [http://quilljs.com/docs/api/](http://quilljs.com/docs/api/) [3]
[https://facebook.github.io/draft-
js/docs/overview.html](https://facebook.github.io/draft-js/docs/overview.html)

~~~
benbriggs
(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.

~~~
jhchen
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/](http://quilljs.com/guides/working-with-deltas/)

------
malloryerik
Congratulations! Such a cool and useful project.

Any word on integration with React?

~~~
jhchen
Quill definitely has users that are on React (and Angular, Ember, etc). In
general you will want a React Component that is essentially a wrapper around
Quill so they stay out of each other's way. You should make sure to understand
React's component lifecycle and follow their best practices on working with
third party libraries that modify the DOM.

------
zem
any examples out there integrating quill with an ML-based altjs language?
(elm, purescript, f#, js-of-ocaml)

------
tmat
its a great editor with an API.. used it for the first time recently and am
hooked! my client loves it.

------
kingofhawks
Congratulations!I will give it a try.

------
abritinthebay
This is a pretty amazing project.

That said - as someone unfamiliar with the project it took me FAR too long to
work out (by reading the site) that it's not a text editor in the
Sublime/Atom/etc sense and in fact a different kind of library like the
TinyMCE type things.

Except better.

I think it could be much clearer from the home page what exactly Quill does
(and what it does is fantastic).

~~~
jhchen
Did you try the demo on the homepage? I would have thought a demo of the
actual product would make it clear what the actual product is.

~~~
elliotec
The demo on the homepage looks and seems nothing like a demo. I had no clue I
could edit the content until i read this comment and started clicking around.

Also, the interactive playground DOES make it seem like it is trying to be a
code editor, except it is implemented in codepen which is pretty confusing. I
get that you're showing how to render the JS and all but only because I've
spent time poking around a lot.

That all said, next time I need a WYSIWYG I know exactly where to go! Thanks!

------
finid
How does this compare to Atom?

I'm looking for an editor that does not chew up CPU/RAM like Atom.

~~~
sampl
Quill is a rich-text WYSIWYG editor library for end-users who want to format
text on websites. You would use it to clone Google Docs, for ex. It's not
really an editor you would want to write code in.

~~~
vijayr
How does it compare with TinyMCE and CK Editors?

~~~
lobster_johnson
Those two are implemented with contenteditable, which is a very flawed
mechanism that isn't standard or consistent across browsers. Quill is
implemented entirely in JS.

~~~
Tloewald
Quill seems to be using contenteditable to me. Look in the DOM.

~~~
lobster_johnson
I believe Quill relies on contenteditable in order to support certain
operations, such as pasting. Quill has its own document model, and supports
things like deltas/operational transforms, which are practically impossible if
you use the DOM as the truth like TinyCKE et al do.

~~~
Tloewald
It relies on contenteditable. You can just paste any old thing into it — not
sure whether some stuff gets stripped by the document model, but that's kind
of beside the point. Once you use contenteditable you get a whole bunch of
weirdness for free.

