代码控制
编辑器的源代码是可读的。你可以追踪行为到导致该行为的那一行,修补它,必要时再分叉。
块、画布和样式控件——运行在你的应用内部,在你的基础设施上。
26k+
GitHub 星
BSD-3-Clause
核心许可
1.4M+
每月 npm 下载量
100+
GJS.Market 上的插件
开源不是功能列表——而是对你产品中编辑器的一套权利。这六项是改变你构建方式的。
编辑器的源代码是可读的。你可以追踪行为到导致该行为的那一行,修补它,必要时再分叉。
GrapesJS 是一个客户端库,你可以捆绑起来。没有任何设备调用家,编辑器无论其他人的正常运行时间如何都能持续工作。
项目、页面和资源通过你编写的存储适配器进入数据库。编辑器永远不会看到你无法控制的服务器。
面板、按钮、扇区以及整个周围的界面都可以由你自己安排。你的用户不必面对通用的编辑器界面。
你的API、认证、资产存储、发布流水线。编辑器调用你赋予的功能。
你的核心编辑体验并非托管平台授权,因此别人的定价或路线图无法决定你的产品是否仍然有效。
团队犯的最昂贵错误是把“我们想拥有我们的页面构建器”和“我们必须写一个可视化编辑器”当成同一句话。事实并非如此。
开源
并不意味着开源
手段目标不是重新发明可视化编辑器的每一个部分。而是从开源基础出发,投入工程时间打造使你的应用独一无二的产品。
这是一种重新定义,而非免费午餐的承诺。开源基金会会从你的待办事项中移除画布、组件模型和样式引擎。它不会移除你的后端、发布工作流程或保持依赖系统的更新工作——这些工作在你自我托管时就会自动转移到你手中。
有用的比较需要诚实地区分哪些功能是正常工作的,哪些作为 API 你仍需使用,哪些则是你无论如何都属于你的。这张表格将这三者区分开来。
| 能力 | 从零开始构建 | 开源基金会 |
|---|---|---|
| 视觉画布 | 建造它 | 内置 |
| 组件模型 | 建造它 | 内置 |
| 拖拽 | 建造它 | 内置 |
| 方块 | 建造它 | API内置——内容由你拥有 |
| 造型 | 建造它 | 内置 |
| 响应式剪辑 | 建造它 | 内置——你自己配置 |
| 资产 | 建造它 | 内置——你自己配置 |
| 富文本 | 建造它 | 内置 |
| 撤销/重做 | 建造它 | 内置 |
| 存储 | 建造它 | 连接你的后端 |
| 出版 | 建造它 | 建立你的工作流程 |
| 自定义编辑器界面 | 建造它 | 内置——你自己配置 |
| 插件架构 | 建造它 | 内置 |
| 乘积逻辑 | 建造它 | 你的申请 |
通过在浏览器中运行每个 API,而不是通过阅读功能列表,验证 GrapesJS 0.23.6 在 2026-09-03 上的验证。“内置”表示模块随核心包一起发布;“API 内置”意味着机制已发布但内容未发布。
开源让你领先一步,同时又不会剥夺你的控制权。
GrapesJS 是一个框架无关的可视化编辑器,你可以从 npm 安装并挂载到自己的界面中。这些是你实际会构建的部分——也是它们的终点。
核心
一个用户直接在中构建的画布:选择、移动、嵌套和编辑真实的DOM,而不是预览。
核心
可重复使用带有类型特征的内容结构,比如营销人员在表单字段中编辑标题,而不是在div中。
核心API
可拖动面板是核心;里面的方块不是。你自己注册,或者安装方块插件。
核心
一个带有扇区和选择器的样式管理器,用户可以在不动CSS的情况下更改界面。
核心
设备断点是一个核心模块。你定义产品提供哪些设备以及它们对应的宽度。
核心API
插件是一个接收编辑器的功能。这就是整个合同,也是生态系统存在的原因。
核心
输出是HTML和CSS,你可以阅读、差异化和服务。当你真正为网络开发时,这很有用。
通过插件
电子邮件不在核心包中。MJML 和通讯预设添加了它——这是真实的功能,但需要安装。
“开源”和“你拥有的页面构建器”之间的每一层都属于某个人。明确哪些是你的,是现实计划和惊喜的区别。
开源视觉编辑基础:画布、组件、块、样式、素材以及插件合同。
认证、仪表盘、计费、用户、权限以及编辑器周围的产品体验。
存储、项目、发布、版本以及让你的产品值得付费的业务逻辑。
可选模块、集成和专门功能——在购买胜过构建的地方使用,在不适合的地方被跳过。
你不是在外包你的产品。你是在拒绝重写画布。
所有让你的产品属于你的一切。这些都不是来自编辑。
用你已经构建的软件。GrapesJS 不依赖框架,可以挂载到容器元素中。
开源层。从npm安装,由你配置,运行在你的基础设施上。
你的API、你的数据库、你的规则。GrapesJS 调用你写的加载和存储函数。
GrapesJS 负责编辑体验。你的应用程序负责所有使产品独特的部分。
看看整合是如何运作的实际上有六个产品团队基于这个基础发布。每个产品都是同一个编辑器下不同工作量。
让客户在你的产品内创建和自定义页面,包含你的组件和权限。
构建一个SaaS页面构建器多页面网站,具备视觉编辑功能。页面模块是核心;路由、域名和托管由你自行构建。
搭建一个网站建设器为营销人员提供一种视觉化的方式,无需部署即可发布活动页面——且无需离开设计系统。
构建一个着陆页构建器在CMS或无头CMS中添加可视化编辑,使编辑者看到页面而非字段列表。
构建一个CMS编辑器同一个编辑器,指向邮件。MJML 和通讯预设处理输出;它们是插件,不是核心。
构建一个电子邮件生成器为那些不断要求工程部门修改段落的团队定制视觉编辑。不需要公共产品。
有四种情况下,拥有编辑器值得付出代价。
01
你希望为客户提供视觉编辑器,但又不想外包你的产品被评判的体验。
02
你需要在已有应用内进行视觉编辑,基于它已经使用的框架。
03
你想控制编辑器架构、数据模型和每一个集成点。
04
你需要可重复使用的可视化编辑基础设施,可以在客户项目间迁移,而不是按站点重新授权。
GrapesJS是针对特定需求形态的好答案。如果这份清单大部分是你的清单,那它就很合适。
需要时选择GrapesJS:
你所承担的回报是:你托管它,你升级它,你编写存储和发布层,并且当某件事出问题时,你拥有编辑器的行为权。这是真实的成本,只有当上面的列表真的是你的列表时,才是正确的支付。
从GrapesJS开始有三个条件,其他工具更合适。如果你是其中之一,GrapesJS会反对你。
一个托管平台
你把编辑器、主机、升级和支持都收成一笔,同时放弃了源代码控制、自托管和更改编辑器本身的能力。
一个 React 组件编辑器
如果页面是你自己的React组件树,而不是手工编辑的HTML,那么以React为先的编辑器比以HTML/CSS为导向的编辑器更直接匹配你的数据模型。
一个完整的网站建设器
如果你想要一个完成的网站建设产品,而不是嵌入编辑器,能让你更快完成整个应用的项目。
这些都不是其他工具的弱点。它们是不同的产品,回答不同的问题,选错类别比选错库更贵。
比较开源页面构建器这些项目不能互换。有些是你嵌入的库,有些是你部署的应用,在一个没有差异化的功能列表中比较它们,导致团队最终选择了错误的类别。它们是按具体内容分组的,然后才比较它们的功能。
库你从npm安装,挂载到你已有的应用中。你提供界面、后端和发布流程;库负责编辑。
在本组中
用于在你自己的 React 组件树上构建编辑器的库。页面是描述组件的 JSON,而不是标记——如果你的页面已经是 React,标记是正确的模型。
在本组中
是你部署和使用的应用程序,而不是用来构建的库。对工作现场来说速度快得多,而且不会设计成消失在别人产品里。
在本组中
在内容建模、角色和发布之外,视觉页面构建是其中一项功能的完整内容平台。你采用的是平台,而不仅仅是编辑。
在本组中
| 能力 | GrapesJS | Puck | Craft.js | Silex | Webstudio | Webiny |
|---|---|---|---|---|---|---|
| 许可 | BSD-3-Clause | MIT | MIT | AGPL-3.0 | AGPL-3.0 | MIT* |
| 自托管 | 是的——一个客户端库,你会打包 | 是的 | 是的 | 是的——Docker、npm或源代码 | 发布的网站是的;文档建议不要在生产环境中自托管建设者 | 是的,但只支持AWS——文档明确表示其他系统都不支持 |
| 可以嵌入到你的应用里 | 是的——将库挂载到任何容器元素中 | 是的——“只是React成分”在你的家谱中 | 是的,但它是一个工具包:你自己构建编辑器界面 | 作为一个节点服务器。没有文档中的前端编辑器挂载 | 不——构建者包是私有的,没有发布到 npm | 不——是iframe进入一个完全部署的Webiny栈 |
| 可视化编辑器 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 拖拽 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| 自定义组件 | ✓ | ✓ | ✓ | ✓ | 未验证 | ✓ |
| 响应式剪辑 | ✓ | ✓ | 定制——你自己去建造 | 部分 | ✓ | ✓ |
| 自定义后端/存储 | 存储 API —— 你自己的加载和存储函数 | onPublish / onChange ——你保存数据 | serialize() / deserialize() — 你保存 JSON | 用于存储和托管的连接器 API | 无连接器API;数据通过CLI导出离开 | 存储在项目创建时是固定的,之后无法更改 |
| 插件架构 | ✓ | ✓ | 没有——这是刻意为之 | ✓ | 未验证 | ✓ |
| HTML / CSS 输出 | ✓ | — | — | ✓ | ✓ | — |
| 电子邮件工作流程 | 通过插件 | — | — | — | — | — |
| React | ✓ | ✓ | ✓ | 不是主要焦点 | ✓ | ✓ |
| 框架 | Framework-agnostic | React | React | Framework-agnostic (built on GrapesJS) | React (React Router v7 output) | React (Next.js supported) |
| 经过验证的版本 | grapesjs 0.23.6 | @puckeditor/core 0.23.0 | @craftjs/core 0.2.12 | @silexlabs/silex 3.9.0 | 0.296.0 | 6.4.9 |
| 最新发布 | Released 2026-08-26 | Released 2026-08-07 | No commits on any branch since 2025-02 | Released 2026-07-26 | Released 2026-09-01 | Released 2026-08-27 |
许可从每个仓库的 LICENSE 文件读取,从 npm 注册表读取版本和弃用,能力来自各项目自身文档。已验证的 2026-09-03。“未验证”表示无论如何都找不到主要源代码——但功能缺失并非如此。破折号表示项目不针对该用例。*Webiny 的根许可证划分企业目录,并尊重每个包的许可;在当前默认分支中该目录缺失,每个包的许可证都是 MIT。
三个问题,按实际缩小范围的顺序。第一个问题排除的选项比前两个加起来还多。
产品——编辑器就住在我的申请里
继续你需要一个你能根植和控制的基础。第2题缩小了哪种类型。
一个完成的工具——我想用它来构建网站
网站建设器你需要的是应用程序,而不是库。可部署的开源网站构建工具能比任何框架更快达到目标。
一个适合整个团队的内容平台
CMS平台如果页面建设是出版、职位和内容建模的共同要求之一,那就从内容平台开始吧。
标记我可以服务、导出和差异
GrapesJSHTML和CSS输出,一个与框架无关的编辑器,以及一个存储适配器,可以直接进入你自己的数据库。
我自己的React组件树
React 编辑器如果页面是以 JSON 序列化的组件树,且从未手工编辑标记,那么以 React 为先的编辑器更为贴切。
两者都有,取决于表面
GrapesJS + React官方的 React 包装器将编辑器挂载为 React 组件,而输出仍为 HTML/CSS。这是 SaaS 的常见情况。
是的——我们自己运营基础设施
自主机安装、配置、编写存储适配器,编辑器就真正属于你了。
现在不行
托管编辑器托管平台用控制权换取他人承载基础设施。这是合法的交易,而非失败。
是的,但我们不想做所有功能
Foundation + 插件自己托管编辑器,买那些不是你产品差异化的部分。
正确的选择取决于你是否需要一个完整的网站建设产品,还是需要一个能成为你自己应用一部分的编辑器基础。其他一切——许可、框架、插件API——只有在这个问题得到回答后才重要。
01 — 安装
一个依赖。没有构建插件,也不需要框架要求。
npm install grapesjs02 — 初始化
把它指向一个容器,然后选择你的设备断点。这是一个可用的编辑器。
import grapesjs from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';
const editor = grapesjs.init({
container: '#gjs',
height: '100vh',
width: 'auto',
// Reads the markup already inside #gjs as the starting page.
fromElement: true,
// No storage yet — step 04 connects your backend.
storageManager: false,
deviceManager: {
devices: [
{ id: 'desktop', name: 'Desktop', width: '' },
{ id: 'tablet', name: 'Tablet', width: '768px', widthMedia: '992px' },
{ id: 'mobile', name: 'Mobile', width: '320px', widthMedia: '480px' },
],
},
});03 — 延伸
组件类型定义用户可以编辑的内容;块则使它可拖曳。它们是两个注册,而不是一个。
// A component type owns its markup and the traits your users can edit.
editor.Components.addType('cta', {
model: {
defaults: {
tagName: 'a',
attributes: { class: 'cta', href: '#' },
components: 'Get started',
traits: [
{ name: 'href', type: 'text', label: 'Link' },
{ name: 'title', type: 'text', label: 'Title' },
],
},
},
});
// A block is what makes that type draggable from the panel — a separate,
// explicit registration, not something the type gives you for free.
editor.Blocks.add('cta-block', {
label: 'CTA',
category: 'Basic',
content: { type: 'cta' },
});04 — 连接
存储适配器是编辑器的停顿点,也是你的产品开始的地方。
// Your backend, your schema, your auth. GrapesJS calls load() and store();
// everything inside them is yours.
editor.Storage.add('your-backend', {
async load() {
const res = await fetch(`/api/pages/${pageId}`, { credentials: 'include' });
return res.ok ? res.json() : {};
},
async store(data) {
await fetch(`/api/pages/${pageId}`, {
method: 'PUT',
credentials: 'include',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(data),
});
return data;
},
});
// Publishing is your workflow, not the editor's. getHtml()/getCss() give you
// the output; what happens to it is a decision only your product can make.
editor.Commands.add('publish-page', {
run: (ed) => ({ html: ed.getHtml(), css: ed.getCss() }),
});已在2026-09-03上与grapesjs0.23.6进行验证。
这就是整个表面:安装、挂载、扩展、连接。第四步之后的所有内容——认证、计费、版本、域名——都是你的应用,编辑器没有任何决定。
项目自有演示——核心编辑器、默认面板,什么都没买。
在iframe中加载第三方演示。只有点击后才加载。
从开源编辑器核心开始。只添加产品所需的功能——其余部分自己构建,这才是你的差异化优势。
不是捆绑包——而是三套,分别满足三种常见构建中第一个真正需求的。每件物品都是在线列表,且每一件都是可选的。
你的第一个视觉编辑器
阅读教程面向客户的页面构建器
可视化邮件创建
构建一个电子邮件生成器价格可实时从目录中读取。
大多数“GrapesJS做不了X”的结论其实是“核心包不提供X”。这些是不同的问题,只有其中一个需要不同的编辑器。
需要 React 集成吗?
React 积分
官方的包装器将编辑器挂载为React组件,所以它像其他组件一样存在于你的树中。
需要电子邮件吗?
电子邮件插件
MJML 和通讯预设可以把同一个画布变成一个邮件生成器。
需要模板吗?
模板插件
预设和模板管理器为用户提供了一个可以开始的库,而不是空白画布。
需要Tailwind吗?
Tailwind 模块
Tailwind 类块集,所以编辑器会输出你代码库已经使用的类。
需要自定义方块吗?
块插件
或者自己写——块是一个标签、一个类别和一些内容。
需要储藏?
存储适配器
现成的适配器,或者你自己的加载/存储对,针对你的 API。
不要因为缺少一个功能就替换编辑器。扩展它。
开源改变了页面构建器的经济性。它不会消除工程设计,任何告诉你相反的页面都是在卖东西。以下是你在每条路线上仍拥有的内容。
您拥有:
完全掌控,也是获得第一个工作编辑的最长路径。只有当编辑器本身是你产品的差异化因素时,才值得。
你仍然会建造:
视觉编辑的基础已经存在。以上内容仍由你自行构建——这份列表比路线A短,而非空白。
你仍然会建造:
购买块集或存储适配器只是移除一个任务,而不是依赖。每一个都是你现在依赖并必须继续工作的代码。
我们故意不公布“从零开始构建页面构建器”的具体金额。没有可信的公开基准,诚实的答案完全取决于你的团队和范围,而虚构的数字是本页最不可靠的。不如数上方的表面——它们才是你真正交易的东西。
这是一笔交易,不是排名。开源给你更多控制权;托管则让你操作更少。两栏都包含对你重要的内容。
| 尺寸 | 开源 | 主持人 |
|---|---|---|
| 源控 | 由你阅读、修补和分支 | 限制在平台所揭示的内容 |
| 自托管 | 通常是有可能的 | 通常不会 |
| 数据定位 | 你的基础设施 | 提供者的 |
| 用户界面定制 | 高——壳是你的 | 这取决于平台 |
| 供应商依赖 | 下层 | 高 |
| 维护 | 你的责任 | 提供者的 |
| 基础设施 | 你的责任 | 提供者的 |
| 可扩展性 | 这取决于项目的插件 API | 这取决于站台的延伸点 |
| 成为工作编辑的时间 | 整合工作后,任何东西都无法使用。 | 在你写代码之前就已可用 |
开源给你更多控制权,但你也要负责基础设施和维护。如果团队里没人愿意承担这种责任,托管是坦率的答案。
一个视觉页面编辑器,其源代码以开源许可证发布,你可以阅读它,在自己的基础设施上运行,修改它,并在其上构建产品。它可以是你嵌入应用中的库,也可以是你部署的完整网站构建应用——这两种是完全不同但标签相同的东西。
没有唯一的最佳选择——有最适合你需求的最佳方案。如果你在自己的应用中嵌入编辑器并希望输出HTML/CSS,GrapesJS很合适。如果页面是React组件的树状结构,那么以React为先的编辑器更合适。如果你想要一个完成的网站构建应用而非基础,可部署的网站构建器会更快。先回答“库还是应用程序?”;它排除的选项比任何功能比较都多。
是的。核心Grapesjs包以BSD-3-Clause许可证发布,官方@grapesjs/react包装在MIT许可下发布。两者都是宽松许可证。注意,尽管很多对比文章说GrapesJS核心不是MIT。
是的。GrapesJS 是一个客户端 JavaScript 库,你可以从 npm 安装并捆绑在你的应用中。没有服务可调用,也没有账户可创建,所以它运行在你前端运行的地方。
是的,而且这是最常见的用途之一。BSD-3-Clause 是一种宽松许可,允许商业和专有使用,前提是你在分发中保留版权声明和许可文本。在承诺之前,请逐一检查每个项目的许可——一些开源页面构建器使用 AGPL-3.0,该版本对托管产品有特别重要的义务。
是的。面板、按钮、样式扇区和周围的shell都可以配置,而且有几个发布的编辑器会在运行同一核心的情况下完全替换默认布局。如果你想让编辑器看起来像你的产品而不是GrapesJS那样,那是支持的结果,不是破解。
是的。GrapesJS 有一个存储 API,你可以注册一个带有加载和存储功能的适配器。适配器内部发生的事情——哪个端点、哪个认证、哪个模式——完全由你负责,所以项目数据会进入你自己的数据库,而不是别人的。
是的。官方的@grapesjs/react包装器将编辑器挂载为React组件,因此它存在于组件树中,包含你的状态和路由。编辑器核心本身保持框架无关——包装器是一个集成层,而非重写。
是的,但有个需要明确说明的前提。多页编辑是核心模块,所以编辑部分已经涵盖。所有让它成为网站建设工具而非页面编辑器的部分——路由、域名、托管、部署、用户账户——都是你写的应用代码。GrapesJS 给你的是编辑器,而不是平台。
是的,使用插件。邮件输出不在核心包里:MJML 和通讯预设添加了邮件专用模块和能通过真实邮件客户端保存的输出流水线。这是真实且生产环境中使用的功能,但它是安装的,不是默认获得的。
核心包是BSD-3-Clause,React封装是MIT,两者都允许商业使用,包括闭源产品,只要你保留版权和许可声明。这是许可文本的摘要,不是法律建议——请阅读仓库中的LICENSE文件,并询问你自己的律师,这些答案是否对合同有影响。
它们属于不同的类别。GrapesJS 是一个 BSD-3-Clause 库,你可以安装并嵌入到自己的应用程序中,提供界面、后端和发布。Webstudio 是一个 AGPL-3.0 的可视化网站构建器——一个独立的应用程序,拥有托管服务。许可证的差异也体现在托管产品方面:AGPL-3.0 承担 BSD-3-Clause 没有的源代码可用性义务。
数据模型和框架。Puck 是一个 MIT 许可的 React 编辑器:页面是由 React 渲染的 React 组件的 JSON 树。GrapesJS 不依赖框架,支持 HTML 和 CSS 输出,适合提供或导出标记的产品。如果你的页面是 React 组件,Puck 会更直接地映射到它们;如果是网页,GrapesJS 则映射。
谁来承担工作。开源时,你拥有源代码、自托管、自己的数据位置和深度用户界面控制——你还承担托管、升级和维护。托管构建者承担所有这些,你接受他们的定价、路线图和定制限制。这两者都不是绝对优越;这取决于你是否愿意承担编辑器的运营成本。
不。GrapesJS 完全可以使用而无需购买任何东西,许多生产编辑器完全基于团队编写的核心加代码构建。插件在功能不是产品差异化优势时是值得的——比如电子邮件预设、块集、存储适配器——但当它是优势时就不值得。
是的,这也是使用编辑器的正常方式。你注册一个定义标记和用户可编辑特征的组件类型,然后注册一个块,使其可以从面板中拖拽。它们是两个独立的注册,了解一下很重要,别想为什么新组件不在面板里。
从GrapesJS开始,保持对应用的控制,然后扩展编辑器,满足你的产品需求。
在浏览器里加载一个真实的编辑器,然后安装并挂载到你自己的应用里。
试试GrapesJS模块、存储适配器、React 外壳和邮件预设——只安装在能帮你省下实际工作的地方。
浏览GJS.Market插件在你为其中一个方案下定型之前,先看看这些开源选项的差异。
比较页面构建器拥有编辑器。拥有数据。拥有产品。