We have done a lot of work on core stabilisation and API improvement. First version of editor.js is used for a while by local big (well, relatively) media projects — vc.ru, dtf.ru, tjournal.ru with the 200-500k DAU. This projects have UGC communities, so the Editor is using many times in a day. I mean most of our resources on the past stage was directed to the stability purposes.
Fully agree with you about the importance of UI and UX (and mobile adaptation) in our case. This is a next step we have start today. And this is a reason why it is an open source and free. We see many talented developers and the demand, so we will continue to work.
Anyway, we had big plans for mobile support in CKEditor 5. Then we started doing more research [1] and it turned out there are critical issues with how WebKit works. You can guess, you can try, but with a tone of hacks you still won't be able to guarantee a smooth UI and great UX.
Right now, we're in a state where:
* after spending several months on it, text editing is well supported on iOS and Android (including spellcheck and stuff) – we don't get any bug reports recently about that part,
* the default UI is not working great on smaller devices.
The sad part is – we don't have any bigger plans to address the latter. We have some smaller ideas for making the current UI more responsive, but there will still be fundamental issues that you will face when using it:
* The conflict between the native UI (the balloons/panels with paste/copy/cut/bold/italic) and the custom editor UI. I've been bringing that to the W3C's attention since 2015 and nothing happened since then (most recent topics: [2], [3]). Right now, I don't have the funds anymore to lobby for this (neither have anyone else, apparently), so those topics seem to be completely stale.
* Inability to display your UI and implement functions like scrolling to the caret in a reliable way on WebKit due to its broken viewport mechanics [4]. I even talked about this with one of the Apple devs responsible for the current behavior and he agreed that there may be a problem (a good first step :D), but I got literally zero feedback after the last year's TPAC in Lyon when I presented this issue. * And more...
IMO, it's due to those issues that we haven't seen a single editor (implementing more than some really basic functions) with a good and stable UX on both iOS and Android. Every solution I saw was flawed in one way or another. I'm not saying that it's completely impossible to build such a solution, but rather that, taken all the obstacles and moderate demand (desktop is still the main platform for rich-text editing), the ROI seems too low for anyone to invest enough in it.
Anyway, feel free to contact me (e.g. via https://twitter.com/reinmarpl) if you'd like to discuss this more.
[1] https://github.com/ckeditor/ckeditor5-design/issues/149
[2] https://github.com/w3c/editing/issues/176
[3] https://github.com/w3c/editing/issues/182 (my presentation from last year's TPAC)
[4] https://gist.github.com/Reinmar/91c70d2882523f47da7c49805042...
I guess my point of frustration is to watch project after project toss itself at the task of implementing a nice Medium-ish desktop UI, announce a new "standard" for JSON-based rich document serialization, get mobile support about 80% of the way there, and then just... leave it like that.
I don't have enough data to make a firm statement, but I would bet with confidence that that if you include native mobile apps in the calculation (iOS Notes app, Google Keep, Wordpress Mobile), mobile rich text editing is either more prevalent than desktop, or on a strong upward trend that will overtake desktop text editing in the next two years. The popularity of hybrid devices like the iPad pro, where you have a desktop-class processor and screen size but an iOS IME is only going to boost those numbers.
To the best of my knowledge, Prosemirror has been most willing to prioritize mobile support, and currently has the best mobile browser coverage of the three most commonly mentioned modern contentEditable options (prosemirror, draft-js, quill). Unfortunately, building an editor with Prosemirror is a very hands-on process that requires you to make all the UI decisions and most of the UX decisions yourself, which isn't a great fit for most projects that don't need to innovate in the actual content creation side of things.
I would LOVE it if a batteries-included editor like this, which clearly had a lot of thought put into the UX and UI aspects, was built on the very-robust technical foundation of Prosemirror (or similar). There are a few efforts at this on GitHub, but nothing so far with more than one or two contributors that I've found. The backend of editor.js looks solid, but without any discussion of mobile IME support, and without the backing of big players like NYT [5], realistically I can only guess that mobile support for editor.js will end up similar to the well-intentioned but partially complete mobile support found in other smaller projects like quill, slate, etc.
[1] https://news.ycombinator.com/item?id=14417624
[2] https://github.com/codemirror/CodeMirror/issues/3403
[3] http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-...
[4] https://github.com/ianstormtaylor/slate/issues/2062
[5] https://open.nytimes.com/building-a-text-editor-for-a-digita...