TinyMCE:主要对象是内容
TinyMCE 以富文本和内容创作为核心。用户打开字段,写入、格式化、插入图片或表格,然后保存。文档是内容的流,编辑的工作是让内容的编写和格式化变得轻松自然。
PageKit — 可自托管的 GrapesJS 建站工具,附完整源码。 获取抢先体验
从富文本编辑、可视化页面搭建、HTML/CSS 控制、可扩展性、CMS 集成到 SaaS 应用,全面对比 GrapesJS 与 TinyMCE。TinyMCE 专注于富文本内容编辑。GrapesJS 专注于可视化页面与布局编辑。
负责一个文本块内部发生的一切:格式、结构、媒体,以及围绕它们的写作体验。
负责页面本身:组件树、布局、样式、断点,以及可复用的部件。
两者都是成熟且维护良好的JavaScript编辑器,且在生产环境中被广泛使用。它们不是同一种工具,所以有用的问题不是哪个更好,而是你的产品哪一层需要编辑器。
需要两者吗?使用GrapesJS进行视觉页面构图,TinyMCE进行高级富文本编辑——TinyMCE可以集成到GrapesJS中,作为富文本编辑层。
区分它们最清晰的方法是询问用户在开始编辑时选择了哪个对象。
TinyMCE 以富文本和内容创作为核心。用户打开字段,写入、格式化、插入图片或表格,然后保存。文档是内容的流,编辑的工作是让内容的编写和格式化变得轻松自然。
GrapesJS 以可视化页面构图为核心。用户可以将一个部分拖到画布上,在其中嵌套组件,重新样式,检查移动端断点并保存项目。文档是一个组件树,编辑的工作是让构建和样式化该树时感觉直接。
内容的流动。顺序很重要;筑巢大多不重要。
一个构图。嵌套是结构,它能深入到设计需要的程度。
TinyMCE 编辑内容。GrapesJS 编辑页面。
诚实回答这个问题,接下来的页面大多是确认。
“撰写并格式化这些内容。”
你的用户打开字段、帖子或文档并生成文本。布局由模板决定;不同的是文字表达的内容和格式。
伸手
TinyMCE
“构建并定制此页面。”
你的用户组装页面本身——分节、列、间距、颜色、断点——并期待在工作过程中看到结果。
伸手
GrapesJS
“搭建这个页面并编辑其中的内容。”
用户先搭建布局,然后在其中撰写内容,两者都不能沦为附带品。这正是这种组合存在的意义。
伸手
GrapesJS + TinyMCE
两者都是你集成到已有应用中的库。它们都不决定你的后端、授权、权限或托管——区别在于它们占据的堆栈频段。
TinyMCE 拥有编辑界面。你存储什么、存储在哪里以及如何渲染,都是你应用在这边的决定。
核心模块
GrapesJS 拥有编辑界面以及其背后的画布模块。存储、发布和托管在这一侧同样由你的应用决定。
两者都可以集成到现有应用中,但它们的主要职责不同。这两者都不会决定你在切换线以下的架构。
没有得分,也没有获胜者列。每个单元格都标注了机制,所以你可以不同意某行,但仍然使用表格。
| 能力 | TinyMCE | GrapesJS | 注释 |
|---|---|---|---|
| 内容层 | |||
| 富文本编辑 | 主要关注点 | 内置 | GrapesJS 自带了一个富文本编辑器,可以替换它;TinyMCE 是人们用来替代它的东西之一。 |
| 文本格式化 | 内置 | 内置 | 加粗、斜体、下划线和划线显示在默认的GrapesJS工具栏中。 |
| 标题 | 内置 | 内置 | 在GrapesJS中,标题是一个带有标签的组件,而不是工具栏下拉菜单。 |
| 列表 | 内置 | 扩展 | 不在默认的GrapesJS工具栏里;RTE扩展插件会添加它们。 |
| 表格 | 内置 | 扩展 | TinyMCE 自带一个表格插件;而 GrapesJS 的侧表则来自组件插件。 |
| 链接 | 内置 | 内置 | 两者都直接处理链接 —— GrapesJS 还提供链接组件类型。 |
| 图像与媒体 | 内置 | 内置 | TinyMCE 将媒体插入内容;GrapesJS 管理整个页面的资源。 |
| 内容创作 | 主要关注点 | 不是重点 | GrapesJS 可以保存长文稿,但它的优化并不是写作工作流程。 |
| 高级富文本工作流程 | 扩展 | 自行开发 | TinyMCE的高级插件系列涵盖了大部分这些;在GrapesJS上,你可以集成一个支持的编辑器。 |
| 评论 | 扩展 | 自行开发 | 一个TinyMCE高级插件。在GrapesJS中,这是应用级工作。 |
| 提及 | 扩展 | 自行开发 | 一个TinyMCE高级插件。在GrapesJS中,这是应用级工作。 |
| 实时协作 | 扩展 | 自行开发 | TinyMCE 提供实时协作作为高级功能;GrapesJS 的核心没有相应功能。 |
| 页面层 | |||
| 视觉画布 | 不是重点 | 主要关注点 | TinyMCE 在字段或内联元素内编辑,而不是在页面画布上编辑。 |
| 拖放布局 | 不是重点 | 内置 | TinyMCE 可以在文档中拖拽内容;排版则是另一项工作。 |
| 页面组成 | 自行开发 | 主要关注点 | 把页面分成各个部分组装出来,正是GrapesJS的用处。 |
| HTML/CSS 视觉编辑 | 自行开发 | 内置 | GrapesJS 通过 Style Manager 进行可视化编辑 CSS 规则;TinyMCE 有源视图,而非样式编辑器。 |
| 响应式视觉编辑 | 自行开发 | 内置 | GrapesJS 的 Device Manager 可以切换画布宽度并编写媒体查询。 |
| 可重复使用的部件 | 扩展 | 内置 | TinyMCE 有内容模板;GrapesJS 有可重复使用的块和符号,跨页面。 |
| Component 嵌套 | 不是重点 | 内置 | GrapesJS 组件可以任意层级嵌套,每一层都可以单独选中。 |
| Style Manager | 自行开发 | 内置 | 一个核心的 GrapesJS 模块,包含扇区、属性和每个选择器规则。 |
| 资产管理 | 集成 | 内置 | TinyMCE 将上传交给你提供的处理器;GrapesJS 有一个 Asset Manager 模块。 |
| 多页项目 | 自行开发 | 内置 | GrapesJS 的 Pages API 可在一个项目中管理多个页面。 |
| 产品形态 | |||
| 项目存储 | 你的应用 | 内置 | GrapesJS 有一个带有本地和远程适配器的 Storage Manager;TinyMCE 则完全由你自己负责持久化。 |
| 出版工作流程 | 你的应用 | 集成 | 这两种都不会为你发布。GrapesJS 导出 HTML 和 CSS 交给你的流水线。 |
| SaaS 页面构建器 | 自行开发 | 非常契合 | 在 TinyMCE 上做页面构建器产品,意味着页面层要自己实现。 |
| 可嵌入编辑器 | 非常契合 | 非常契合 | 两者都嵌入到主机应用中;区别在于嵌入的内容。 |
| 白标可视化编辑器 | 自行开发 | 非常契合 | GrapesJS 的面板、样式和命令都是可替换的,这正是白标所需要的。 |
| 纲领 | |||
| CMS 集成 | 集成 | 集成 | 两者都能与CMS集成——在同一CMS的不同层级。 |
| TypeScript 类型 | 内置 | 内置 | 两者都发布了各自的类型定义。 |
| 可扩展性 | 内置 | 内置 | 两者都有文档化的插件APIs和庞大的插件生态系统。 |
| 自托管 | 内置 | 内置 | 两者都可以自托管;TinyMCE 还提供云端交付选项。 |
如何读取细胞
如果大多数工具都描述你的产品,那么TinyMCE是合适的工具,添加页面构建器并不会让它更好。
一个把错误工具卖给你的落地页,价值不如一个告诉你何时该停止阅读的页面。如果上面这份清单就是你的产品,那么 TinyMCE 是一个可靠且支持完善的答案。
TinyMCE 文档如果这些大多描述的是你的产品,那么布局问题就是你真正遇到的问题。
GrapesJS 和 TinyMCE 可以互补,而不是争夺同一角色。GrapesJS 拥有页面;TinyMCE 从用户开始编辑其组件内部文本的那一刻起接手。
可视化页面编辑
画布、组件、块、样式、断点、资产和项目数据。
富文本编辑
格式、列表、表格、链接以及组件内的写作体验。
页面用GrapesJS。文本用TinyMCE。
这是一个真实的配置,不是图表:GrapesJS 将其富文本层作为可替换模块暴露,集成则替换 TinyMCE 嵌入其后。这也比运行一个编辑器更复杂的部分——两个库、两条升级路径,以及 TinyMCE 自己的许可选择。当用户真正同时做这两项工作时,这值得;但当他们只做其中一项时,就不值得。
专业的富文本编辑,直接在GrapesJS画布内进行。
TinyMCE 8 × GrapesJS
不要从零开始构建TinyMCE集成。这个插件用TinyMCE 8取代了内置的GrapesJS富文本编辑器,为块和内联元素分别设置了独立工具栏,并且在画布iframe中能正常使用工具栏。
核心功能
你实际会用到的选项
作者 DevFuture Development
包含内容
TinyMCE 本身由 Tiny 根据 GNU GPL 或其商业条款单独授权——该插件是 GrapesJS 集成,而非 TinyMCE 许可证。
这是本页面上运行的真实GrapesJS实例。拖入一个块,点击元素进行样式,然后双击任意文本编辑——画布下方的面板会准确告诉你用的是哪个富文本层。
大多数CMS最终都需要两个层。你先建哪一层取决于你的编辑们抱怨什么。
内容优先的CMS
视觉 CMS
你的客户到底在编辑什么?
对于SaaS产品来说,问题不是你的团队偏好什么,而是客户打开编辑器时会看到什么。
TinyMCE 可以高度定制,但它并非主要设计为完整的视觉页面构建框架。
并不是说TinyMCE不能扩展——它的插件API非常完善,人们在上面做出了非常出色的东西。问题是页面构建器所需的功能并不是富文本编辑器能提供的,所以你得自己去构建它们。
用户正在编辑的内容
页面构建器需要什么
如果你只需要其中一两个,扩展TinyMCE可能是较小的工作。如果你需要大部分,那你写的是一个页面构建器——而这正是GrapesJS本身的功能。
有时候。
GrapesJS 自带富文本编辑器。其默认工具栏有六个操作,这在 0.23.6 版本中是 2026-09-03 的,对于标题、按钮、说明文字和简短的营销文案来说,这也足够——这也是为什么大多数 GrapesJS 页面构建器从不添加任何内容。
GrapesJS 默认的 RTE 操作
对于需要更高级或专业富文本体验的应用——长文内容、表格、列表、结构化格式、审阅工作流程——TinyMCE可以作为富文本层集成,同时不放弃视觉画布。
将TinyMCE添加到GrapesJS这是决定迁移难度的部分,所以值得两分钟。
editor.getContent()其中包含什么
<h2>Build faster</h2>
<p>Editable <strong>copy</strong> with a <a href="/pricing">link</a>.</p>
<ul><li>One</li><li>Two</li></ul>一个标记字符串。你的应用程序决定它存在的位置以及如何渲染——TinyMCE 返回内容并停止于此。
editor.getProjectData()其中包含什么
{
"pages": [
{
"id": "SjtXdsYjpE8EJUpL",
"frames": [
{
"component": {
"type": "wrapper",
"components": [
{ "tagName": "section", "classes": ["hero"], "components": [
{ "tagName": "h2", "type": "text", "components": [
{ "type": "textnode", "content": "Build faster" }
]},
{ "type": "link", "classes": ["btn"],
"attributes": { "href": "#" } }
]}
]
}
}
]
}
],
"styles": [
{ "selectors": ["hero"], "style": { "padding-top": "40px", "…": "…" } }
],
"assets": [],
"symbols": [],
"dataSources": []
}一个结构化的项目:页面、组件树、以选择器为键的样式规则、资产和配置。HTML 和 CSS 是由它生成的,而不是以它的形式存储的。
这两种模型有不同的用途,不应被视为可互换的格式。没有转换器能将内容字符串转换为组件树,因为该树承载字符串从未记录过的决策。
这难度几乎完全取决于TinyMCE目前在你产品中的作用。先弄清楚。
审计TinyMCE今天的实际功能
列出编辑器出现的每一个位置、启用的插件,以及你内容依赖的每个自定义 HTML 组件。
将内容与布局分离
你的用户输入的内容中,有些是内容。有些是他们被迫以内容形式表达的布局。只有第二种类型需要新的归宿。
确定你要迁移哪些层
将页面层迁移到 GrapesJS 不需要将内容层从 TinyMCE 移开。在写代码之前先确定这一点。
将内容类型建模为组件
现有内容中每一种重复出现的结构,都会变成一个带有自身 traits 的 GrapesJS 组件类型。
搭建区块面板
GrapesJS 核心不带任何模块。用户应该能拖入的内容,你自己定义——或者安装。
绘制你的造型地图
确定Style Manager暴露什么,哪些保持在设计系统中,然后把CSS框架接线进去。
选择富文本层
如果你的版本不够,保留内置的GrapesJS RTE。如果用户需要他们已经熟悉的编辑器,就集成TinyMCE。
移动内容
现有的标记可以导入到 GrapesJS 画布中,但将其映射到组件类型上是刻意的,不是脚本。
验证输出
在切换任何人之前,先在断点上对比已发布页面和原始页面。
如果你的TinyMCE使用量接近原厂,大部分工作是建模而非转换。
这些行为都存在于内容字符串之外,需要重建或保留。
TinyMCE → GrapesJS 迁移可能是从内容编辑向可视化页面编辑的架构迁移,而非简单的编辑器替换。将它规划为前者,后半部分不会让你感到意外。
三种结果,其中只有一种涉及移除任何东西。
内容
当富文本编辑是主要需求,且你的模板已经处理了布局时。本页没有任何内容支持更改合适的设置。
布局
当用户开始要求页面构图时,模板无法表达。GrapesJS 与 TinyMCE 并列,但存在不同的界面。
可视化内容构建器
当用户需要可视化页面构建和高级富文本编辑在同一地方时,TinyMCE 成为 GrapesJS 画布内的富文本层。
找离你正在建造的那一排最近的那一行。
| 使用场景 | 推荐的起点 |
|---|---|
| 博客编辑器 | TinyMCE |
| 文章编辑 | TinyMCE |
| 文档编辑器 | TinyMCE |
| CMS 富文本字段 | TinyMCE |
| 内容创作 | TinyMCE |
| 着陆页构建器 | GrapesJS — 阅读更多 |
| 网站建设器 | GrapesJS — 阅读更多 |
| SaaS 页面构建器 | GrapesJS — 阅读更多 |
| HTML/CSS 可视化编辑器 | GrapesJS — 阅读更多 |
| 可嵌入页面构建器 | GrapesJS — 阅读更多 |
| 白标可视化编辑器 | GrapesJS — 阅读更多 |
| 视觉 CMS | GrapesJS — 阅读更多 |
| 页面构建器中的富文本 | GrapesJS + TinyMCE — 阅读更多 |
这些建议描述的是主要的使用场景,而非硬性技术限制。许多产品背离本表的风格,原因充分。
正文
内容就是产品,布局由你的模板决定。
TinyMCE 文档页面
布局就是产品。用户负责撰写、样式和预览。
试试编辑器两者兼具
用户在页面中撰写和写作,双方都不会觉得自己是次要的。
查看这套集成GrapesJS 渲染成 DOM 元素并编辑 iframe 画布,因此它会直接插入由这些元素构建的应用程序中。它不会共享它们的组件模型——GrapesJS 组件是编辑器自己的模型对象,而不是 React 或 Vue 组件——下面的指南涵盖了这种差异所带来的连接。
两个编辑器都可扩展,也都有真实的生态。区别在于它们向不同的方向扩展 —— 从开发者的视角看,这仍然是同一个层次差异。
满足常见GrapesJS需求的即用插件。这里的每一个商品都是市场上的真实产品。
更多富文本集成
按类别浏览
目录查过2026-09-03。
构建生产编辑器往往不仅仅是安装一个软件包那么简单。请获得关于GrapesJS架构、自定义插件、迁移、集成和编辑器自定义的帮助。
每个项目的范围、时间表和价格都是在我们看到你已有的方案后达成的——这里没有固定的套餐,也没有在讨论前给出估价。
当你的产品围绕富文本和内容创作展开时,TinyMCE 是一个强有力的选择。当用户需要视觉化地构建页面、布局和组件时,GrapesJS 是一个强有力的选择。当你的产品需要两者同时使用时,结合 GrapesJS 和 TinyMCE,打造一个拥有强大富文本体验的可视化编辑器。
无论这页指引你走向哪一边,有用的结果都是一样的:你现在知道编辑器属于产品的哪个层级,可以停止比较那些从未解决过同样问题的工具。
负责一个文本块内部发生的一切:格式、结构、媒体,以及围绕它们的写作体验。
负责页面本身:组件树、布局、样式、断点,以及可复用的部件。
GrapesJS 负责页面组成;TinyMCE 从用户开始编辑其组件内部文本的那一刻接手。