Interesting question… I wouldn’t try this at home, but it’s curious as a thought experiment. In real life — go with CKEditor 5 which implements a custom data model and a virtual DOM ;)

So, you want to implement a model-based editor. To do that — take CKEditor 4, replace “DOM” with “model” and you’re there. You have a model-based editor :P.

CKEditor 4 treats the DOM as the model. The DOM is used there as a structure that keeps the data and… as a view which is shown to the user. This is easy to start with (because, basically, native contentEditable works exactly in this way). But it’s seriously limiting and tricky to work with because everywhere you look you see contentEditable’s quirks and HTML features which do not describe rich-text in the most optimal way. So, you start implementing tools to tame contentEditable, to analyse it, to change its structure, etc. — all that so you’re able to write your editing features’ code in a human readable way. This works for some time but it has pretty short legs and at some point you need to split this soup into a real model and a real view.

However, at this point, all that you created so far becomes obsolete. Your model’s structure, if it’s good, will not resemble DOM that much, so you need different tools now. And you need an entire model to view conversion mechanism and mechanism for handling user actions (which happen in the view, but need to be translated to changes in the model).

This is a completely different architecture. Most of the developers start with a plain contentEditable, then build all these tools around it and then… Then you need to start from scratch. That’s what we did with CKEditor 5. We wrote it from scratch (using our experience from CKEditor 4).

Fun fact — a couple of months ago I had a presentation about exactly this on WarsawJS (in Polish: https://www.youtube.com/watch?v=9QRGdLuzD9A) and planned to turn it into an article one day.