DAdavidpolberger·Oct 19, 2017
We have selected CKEditor 5 for our SaaS application for the following reasons:
* We need to implement a custom user interface and CKEditor 5 makes this easy. Its modular nature enables us to build a custom "headless" bundle using Webpack. Keystroke handling is currently tied to the CKEditor 5 user interface, though, which is problematic as you don't want to reimplement what the Enter key does when editing, say, lists or block quotes. The team is actively looking into this issue, though, and it is possible to use a custom user interface while still benefiting from CKEditor's keystroke handling using a hack I documented here[1].
* The output format is (very clean) HTML. If we ever change our implementation to use another rich text editor, we don't want to write a server-side migrator moving user content from one editor format to another. A
Read the rest
lso, HTML is the output format we're looking to consume.
* Unlike most other rich text editors, CKEditor 5 will likely support pasting from Word (and possibly Excel) in the future[2]. Our end users are likely to copy content from Word and Excel (after all, we're creating "Excel for apps"). Handling this well is notoriously difficult -- here's the CKEditor 4 implementation[3]. Where TinyMCE makes this a proprietary add-on[4], CKSource will likely make this part of the open source version of CKEditor 5[5].
* When CKEditor 5 matures, CKSource will offer commercial support.
* We're interested in adding collaborative editing to our SaaS solution in the future, and CKSource's Letters project[6] demonstrates that CKEditor 5's architecture is up to the task.
* What should the HTML output of a rich text editor look like? CKSource's "Editor Recommendations" project (licensed under a Creative Commons license) spells out this in detail[7].
* CKEditor 5 is licensed under permissive open source licenses (MPL and LGPL in addition to GPL).
* CKEditor 5 has a responsive community and an active chat channel where the core developers hang out[8].
The downside to adopting CKEditor 5 at this early stage is that the project isn't fully mature yet. There's no out-of-the-box support for things like colored text and tables (though adding support for colored text through a plug-in is trivial, thanks to how the architecture works).
Also, browser support is spotty. Internet Explorer is not supported in any capacity (Internet Explorer 11 may be supported in the future[9]). While Edge is formally supported[10], we found problems that were serious enough for us to disable the editor when that browser is run. (Our SaaS application falls back to plain text editing when rich text editing is not available on account of the user's browser.) Also, only Safari 11 (released on September 19, 2017) works with the default build of CKEditor 5 due to a WebKit bug[11]. Finally, only recent versions of Firefox can be used that support the "selectionchange" event (which means Firefox 52 and later versions; Firefox 52 was released on March 7, 2017).
All in all, we're happy with our choice, but you may want to wait for the project to mature given the issues cited above.
[1] https://github.com/ckeditor/ckeditor5/issues/488
[2] https://github.com/ckeditor/ckeditor5-design/issues/172
[3] https://github.com/ckeditor/ckeditor-dev/blob/major/plugins/...
[4] https://go.tinymce.com/powerpaste/
[5] https://gitter.im/ckeditor/ckeditor5?at=59af4683c101bc4e3a94...
[6] https://ckeditor.com/letters/
[7] http://ckeditor.github.io/editor-recommendations/
[8] https://gitter.im/ckeditor/ckeditor5
[9] https://github.com/ckeditor/ckeditor5/issues/330
[10] https://github.com/ckeditor/ckeditor5/issues/423
[11] https://bugs.webkit.org/show_bug.cgi?id=171041