CKEditor 已经存在 12 年之久，在这期间，它在很多方面都做了改进，成为一个稳健的 web 应用解决方案，目前下载量已经达到 15 million downloads 。
Web 本身也在改变，新的标准和信息分享的新方法伴随出现，当前利益和世界未来都驱使我们为断考虑 web内容的价值。最终 JavaScript 展现了它的威力，在人们的日常生活中它无处不在，已经成了流行软件的标准选项。
所有上述现象共同形成了当前的解决方案，CKEditor 4，它是一个强大的流行应用，web 编辑器领域无争议的创新领导者。但我们仍然相信，需要更巨烈的变革来满足世界对我们当前和未来的期待。
事实上，这就是 CKEditor 5 要做的。
为什么需要 CKEditor 5?
保持领先的创新都来自反思。
CKEditor 5 在策略和设计上都有大的改变。整个应用将重新考虑每一个方面和每一个建议，以期满足社区当前和未来的需求。
尽管 CKEditor 4 是一个伟大的解决方案，我们仍然觉得他有一些局限导致我们的目标难以实现。同时它在过去还产生了很多问题（当前依然存在），所以我们想改变这个局面，将这些问题放到未来这个背景下来考虑。
CKEditor 4 依然是很棒的代码，有很多创新的功能（像 widgets, content filtering, magicline 和 accessibility checker).。一方面我们要将好的代码引入到 CKEditor 5，但同时我们检查从它而来的每一段代码，清理干净，并根据需要做出修改。
需求
我们已经在CKEditor 4中实现了通常意义的高层分离，例如极其的易用性，全球化，可配置性和可定制性。这里是一些其他更突出的特点。
性能
主要在于UI的渲染，下载和初始化加载
CKEditor 不是一个性能密集型的应用，但是仍然有一点需要注意的地方来提高整体的用户体验：:
UI渲染必须快速响应合理地用户动作。这包括面板，对话框，弹出窗户，信息提示，等等。
初始化加载必须快。编辑器必须在一瞬间准备好。
执行命令的速度必须快。
必须优化下载性能，找一个有效的下载方案来减少整体页面加载的影响。
现代化
基于ECS5和ES6编码，基于AMD和MVC模式，基于NPM分发。
尽管文档写得很好很清晰，但 CKEditor 4 的代码没有引入一些流行的编程实践。
CKEditor 5 会做出以下改进:
将代码按 AMD 模块分割.
清晰的 MVC 模式.
NPM 做为核心分发组件.
完整遵循 ES5 部分遵循 ES6 (Promises, classes, 等).
多终端支持
支持桌面，平板，智能手机上的浏览器和app.
CKEditor 5 支持桌面和笔记本电脑已经不是新闻，它的前任已经支持得很广泛了。 世界上的一些变化也已经不是新闻，现在web是由多终端组成的，从平板到智能手机，到洗衣机，甚至混合方案，如平板加笔记本。
尽管我们不关注洗衣机，但平板和智能手机肯定是我们感兴趣的，包括他们的混合方式。
更多信息参见： Browser Compatibility
质量
(概要) 按照CKEditor满足的严格的质量标准打造
这也一直是 CKEditor 最重要的差异化因素。我们写代码注重质量。这意味着我们一直致力于书写经过广泛测试的代码，依照同行审查来合并代码，利用自动化来确认关键质量方面的问题，只有经过有力的测试过程才发布。所有这些都遵循开放式设计的方法，经过多人协作。
新的数据模型
概要) 针对编辑视图会有一个基于 MVC 模式的自定义 JavaScript 数据模型。它会集中在支持操作转换，该功能带来了激动人心的可能性。
HTML 是 Web 的语言。因此，可以很自然地假设 Web 内容应该用这种格式呈现。CKEditor 4 已经这样做了，它的功能基于 HTML 构建，直接修改呈现内容的 DOM。
但是 HTML 有自己的意图和局限。考虑到更语义化的值、高级编程功能和无需内置视觉兼容措施，我们需要更好的数据格式。CKEditor 5 中，我们最终提出一个自定义 JavaScript 数据模型，并有强大的 API 来操作它。该数据模型加入了一个典型的 MVC 解决方案，该方案中的视图——呈现给用户的可编辑的文档 —— 只是当前用户上下文中数据的简单 HTML 展现。
该数据模型被设计为在 CKEditor 中启用操作转换 (OT)。 这项技术将是一个进步，使得进一步创新成为可能。
新的可能性
(概要) 源自我们的自定义数据模型的一些功能示例：协作编辑、跟踪变化、更好的重做系统、强大的功能 API、RDFa 和注释。
我们的定制数据模型 API 是一个复杂的系统，当我写下这句话的时候，这个系统正在完善代码和文档。为了更好的展示它的好处，让我来指出一些新的即将公开的功能：
协同编辑：这是第一个 OT 带来的明显的好处，也是我们非常期待的功能。
追踪改变：完善的数据注解，与一个独立的视图模块一同，让富 UI 功能类似追踪改变。
更好的撤销/重做：OT 还有一个好处是精确地持有在数据上定义行为的可能性，这让系统拥有较好的性能和强大的撤销系统。
强大的API：从视图中解耦数据将会使得系统变得更简单，这也给 CKEditor 带来的更高级的功能。例如：使用富 UI 工具处理数据部分（类似 CKEditor 4工具，但是更好，更快）。
RDFa，注解：不同于视图的语义，拥有简单的注解介绍的功能，这在上一个版本更复杂。
Markdown, Wiki 标记及其他
(概要) 数据采用非HTML格式即将成为现实，超越以往任何时候。
尽管 CKEditor 4 被设计为能够处理不同于 HTML 的数据格式，在 CKEditor 5 中这一点将更为明显。从一开始它就被设计为能有效支持所有格式，从 Markdown (或 CommonMark), 到 Wiki Markup， 到 RTF, 到许多其他格式。从一开始我们就应该期待针对所有这些不同案例的可用方案。
ContentEditable 和新的数据模型
(概要) 在依然使用 contentEditable 来处理输入和选择的同时，所有功能将会直接在新的数据模型上开发。无需处理 DOM 怪异行为。
ContentEditable 被认为是有害的，但同时也是在 web 上启用富文本编辑的唯一正常的方式 。在开发 CKEditor 4 的过程中我们发现，我们一步步地重写了越来越多的不令我们满意的原生特性。我们控制回车键，给操作加样式，粘贴，剪切，拖放等。这给了我们和开发者对编辑器行为的控制。然而，有些功能比如输入、IME、原生自动完成无法用JavaScript控制。其他的功能（比如插入符号的移动）非常难以实现，因此我们必须使用 contentEditable.
新的数据模型如何适应它？ 除了需要原生处理的操作，所有操作都会直接在新的数据模型上通过 CKEditor 插件实现。对模型的改动会自动传递到 DOM。比如，回车键将会被实现为“在当前插入符号的位置分割当前区块”。一旦插件修改了数据模型，视图（DOM）也会被修改。
一些需要本地处理的功能（类似打字）将会通过在 DOM 上的变化进行观测，将更改传到数据模型上进行操作。模型也能拒绝这样的变化（如果他们违反它的一些规则），并且这些恢复操作将传到 DOM 上来修复它。
这种模型（contentEditable 处理输入和选择相关的功能，其余的则在 JavaScript 中处理）这一直是由 W3C 工作组编辑的。在“Fixing ContentEditable”上，你可以阅读到更多 contentEditable 的未来。
文章转载自 开源中国社区[https://www.oschina.net]