From Aloha to CKEditor
A lot of these negative comments seem based on the older CKEditor 3.x release. It's definitely worth taking a look at the newer CKEditor 4.x release, which radically cleans up the UI, introduces inline editing, and a host of other features. Similarly, the demo of the CKEditor 8.x code
It's also worth pointing out that this was definitely not a decision that was made lightly, nor was it "politically" motivated, nor any of these other things.
Discussion around this started over a year ago in DrupalCon London (August 2011) with quicksketch's core conversation: http://london2011.drupal.org/coreconversation/wysiwyg-editor-module and ensuing sandbox discussion: https://www.drupal.org/node/1260052
When we kicked off Spark, we did a similar analysis, but based around in-line editing capabilities: https://www.drupal.org/node/1580210 We did this separately, because at that point we weren't actually sure if we could pull off inline editing in Drupal, and didn't want to derail WYSIWYG in core efforts. And at that point (May 2012), Aloha Editor was the clear winner, and only logical choice. And the Aloha Editor team has been fantastic to work with, very responsive to our needs. This change in direction should not be seen as ungratefulness for their work at all.
However, due to the nature of Aloha Editor, whose focus is on making "true" WYSIWYG (in-line editing) as seamless as possible, there was quite a bit of catch-up work to do in terms of having it work well as a "back-end" editor as well (e.g. on node/1/edit and the like). Not every property in Drupal is visual (node published status, URL alias, etc.) and so you still need those back-end forms. Not being able to use the same WYSIWYG editor on both the front-end and the back-end is a critical, release-blocking consideration. And Aloha Editor had some work to do here; for example, in areas such as accessibility, providing mechanisms for deep customization of the UI, UX of insertion of images, etc.
Then around DrupalCon Munich (August 2012), CKEditor came out with the 4.x release which included inline editing and a new UI. CKEditor has approximately a 9 year head-start on making a great WYSIWYG editor to use on the backend, with a lot of these tough problems were already figured out, plus a huge number of community extensions already available, etc. So when we found ourselves more-or-less at feature freeze (November 2012) with many oustanding issues remaining with Aloha Editor's back-end integration, we were forced to take a hard look at what was realistic for Drupal 8.
We embarked on a feature-by-feature comparison between the two editors (https://docs.google.com/a/acquia.com/document/d/164Bm2KPAPelQj2fKauWlaj…), which involved representatives from both projects, as well as major Drupal contributors in the area of WYSIWYG. The results were basically that both editors have strong points and weak points. We still resolved to stick with Aloha Editor at that point, since it wasn't an open-and-shut case for moving from it.
However, the one blocking feature that Aloha had that CKEditor hadn't (a "blocks/widgets" system that allows for editables within editables, such as image captions) was addressed by the CKEditor team shortly after this comparison was put together, as well as a commitment from the project lead to do whatever was necessary to get CKEditor to work well for Drupal. Then the choice became a lot more clear: if we chose an editor for D8 with the back-end stuff already figured out, we could spend more of the remaining timeframe doing really deep, well-done integration in core or doing further UX improvements for Drupal itself, rather than spending that effort instead on improving the WYSIWYG editor in Drupal.
So this is mostly a timing / level of effort decision at this point, as it relates to D8's release timing. I have absolutely no doubt that Aloha Editor will close the gaps here in the coming months, and will be a very compelling alternative. And because of the investment both they and Acquia have put into Aloha Editor to this point, people can freely choose to use it instead of CKEditor in their Drupal sites if they prefer it (this would not have been possible without the license change, since AGPL and GPLv2+ are incompatible). But in the meantime, we the Drupal community can focus on making the out of the box WYSIWYG experience of Drupal as great as it possibly can be by choosing the more mature solution that removes a bunch of work from our plate.
Thanks a lot to the couple of people who've offered to help with this initiative. Here are the main jumping-off points:
- https://www.drupal.org/node/1833716 Blocking issue for CKEditor in core.
- https://www.drupal.org/project/wysiwyg_ckeditor D8 CKEditor code (requires that patch)
- https://www.drupal.org/node/1878344 Core issue for adding CKEditor to core
- http://quicksketch.org/wysiwyg D8 CKEditor demo site to try it out