This doesn't help. Not everyone has access to the same infrastructure in their home town/country. Let alone the fact that a class at $X AM/PM in the US may be in the late evenings, late nights in their home country.
Would you be open to sharing some details about your experience there? I'm building a competing service and want to learn how I can make it great. If you're not comfortable sharing publically, my email is in my profile.
We also left compose but left to move to mLab. When Compose was still MongoHQ, we were really impressed by their support. In the last few years, we became incredibly unsatisfied. mLab has been awesome and responsive. I hope the move to Atlas doesn't cause their support to change.
What didn't you like about the support you got from compose? I'm working on standing up a competing service and would like to learn from your experiences with them.
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.
I have a use case where I need to copy in large quantities of content and have them display nicely. At the moment we are using Redactor which is broken in many respects.
I have been using your test form and it appears to play much more nicely with the sort of data that we get.
We do have lots of table data.
Would you contact me (in sig) to discuss further?
Trix is better as it works with new web components standard, quill does not support shadowDom in chrome and doesn't follow current web components standard, check https://github.com/quilljs/quill/issues/904 for details. It will create issues when used in web components project.
