PageKit: el creador de sitios GrapesJS autoalojado, con el código fuente incluido. Obtener acceso anticipado
Construye una experiencia de edición visual más completa con GrapesJS. Puck es un editor React primero para componer tus propios componentes. Si tu producto está creciendo hasta convertirse en un creador de páginas completas, editor web, editor de correo electrónico o editor visual orientado al cliente, GrapesJS te ofrece una base de editores más amplia para integrar y ampliar.
Componentes React entrando, React saliendo.
Un documento visual, luego lo que publiques a partir de él.
26k+
GrapesJS GitHub estrellas
100+
plugins en GJS.Market
1.4M+
GrapesJS Descargas npm / mes
BSD-3-Clause
Licencia del núcleo de GrapesJS
Cifras de GrapesJS y GJS.Market, verificadas 2026-09-03. Describen el proyecto que recomienda esta página, no una puntuación contra Puck — un recuento de estrellas no es prueba de que un editor encaje mejor con tu producto que otro.
Ambos son editores de código abierto que puedes alojar por tu cuenta y poner delante de tus usuarios. Parten de diferentes direcciones arquitectónicas, así que la verdadera pregunta no es cuál es mejor, sino si estás construyendo un editor de componentes React o una experiencia completa de edición visual.
Tu editor es un editor de componentes React, y eso es lo que debería mantener.
Esto describe tu producto
Nada en esta página es motivo para migrar. Puck está bien documentado, desarrollado activamente y con licencia MIT.
Lee la documentación de PuckTu editor se está convirtiendo en una superficie de producto propia, con subsistemas a la altura.
Esto describe tu hoja de ruta
Una base de editores más amplia significa menos infraestructura editorial para que tu equipo diseñe, construya y mantenga.
Abre un editor en vivoEstas son señales concretas de producto, no una afirmación sobre lo que hacen la mayoría de los equipos. Si varias de ellas describen tu hoja de ruta, tu editor ha superado un configurador de componentes.
Los usuarios han empezado a pedir composición visual de páginas, bloques reutilizables, controles responsivos, flujos de trabajo de recursos, plantillas, controles de estilo, capas y varias páginas — características del editor en lugar de más componentes.
En lugar de un componente React con props serializados en JSON, necesitas una página compuesta por secciones, componentes, estilos, recursos y maquetación — un documento que tus usuarios editan en lugar de una configuración que ellos mismos rellenan.
Si el mismo editor tiene que reutilizarse en diferentes entornos de aplicación, o incrustado en un lugar donde React no es el anfitrión, la independencia del framework deja de ser teórica.
Una capa de estilo visual es un subsistema grande. Cuando "dejar que los usuarios elijan el espacio" se convierte en un elemento de hoja de ruta, un editor que ya tiene un Style Manager guarda un proyecto.
Las exportaciones, la publicación estática, los embedos de terceros y el correo electrónico requieren marcado portátil. Renderizar exclusivamente a través de componentes React hace que eso sea más difícil de lo necesario.
El correo electrónico es un objetivo de renderizado diferente con sus propias limitaciones. No es para lo que Puck está documentado, y es un flujo de trabajo que el ecosistema GrapesJS ya cubre.
Una vez que el editor forma parte de lo que pagan los clientes, el coste de construir y mantener la infraestructura del editor por ti mismo se convierte en una decisión del producto más que en un detalle de implementación.
No necesitas migrar simplemente porque GrapesJS exista. Puck es un editor bien documentado, licenciado por MIT y desarrollado activamente, y para toda una clase de productos es el que mejor se adapta.
Puck se ejecuta dentro de tu árbol React, así que tus componentes, contexto, ganchos y sistema de diseño están disponibles en el editor sin una capa de integración.
Si lo que los usuarios editan es un árbol de componentes con props tipados, Puck lo expresa directamente. Un modelo visual de documento sería un paso extra de traducción.
Un configurador con un conjunto de componentes fijo no necesita un Style Manager, un Asset Manager ni un Layer Manager. Los subsistemas no utilizados siguen siendo área superficial para ocultar.
Puck documenta trece espacios de anulación más la redacción, por lo que los equipos que quieren diseñar toda la experiencia de edición tienen un camino claro.
El soporte React con opción voluntaria Server Component, props dinámicos, resolvers y fuentes de datos externas están documentados, preocupaciones nativas de React.
Si nada en tu hoja de ruta requiere editar el marcado o los estilos visualmente, la base más amplia de editor es una capacidad que tendrías sin usar.
Si esos descritos describen tu producto, quedarse en Puck es la decisión correcta — y esta página ha cumplido su función.
¿Sigues comparando? Consulta la matriz completa de característicasPuck está diseñado para editar y componer componentes React. GrapesJS está diseñado para la edición visual de documentos y proporciona un conjunto más amplio de subsistemas de editor para hacerlo.
Los componentes y sus accesorios son el modelo de contenido.
Un documento visual es el modelo de contenido.
Ninguno de los dos modelos puede describirse como falta de capacidades que el otro tiene: cualquier cosa que GrapesJS venga como módulo puede implementarse encima de Puck, y cualquier cosa que Puck haga de forma nativa con React puede integrarse en GrapesJS. La diferencia es el punto de partida.
El punto de partida cambia es cuánta infraestructura de editores tiene que montar tu equipo antes de que el producto parezca terminado — que es la pregunta que las dos siguientes secciones responden concretamente.
Ninguna de las dos arquitecturas es universalmente superior. Optimizan para cosas diferentes, y la adecuada es la que se ajusta a lo que tus usuarios están editando realmente.
La decisión real rara vez es "Puck o GrapesJS". Es cuánta infraestructura de editor debe poseer e implementar tu equipo. Esta tabla lee cada capacidad de la propia documentación de cada proyecto: "núcleo" significa un módulo documentado, "configurable" significa que el proyecto la soporta mediante configuración o sobreescrituras, y "implementación personalizada" significa que tu equipo la escribe. Ninguna de estas celdas significa "imposible".
| Capacidad | Puck | GrapesJS |
|---|---|---|
| Edición de componentes React | Fuerza del core | Integración — tipos de componentes personalizados o el envoltorio React |
| Lienzo visual | Disponible — Vista previa de iframe | Núcleo |
| Bloques | Componentes y configuración | Core — Block Manager |
| Sistema de estilos | Personalizados y configurables | Core — Style Manager |
| Capas y contorno | Disponible y personalizable | Core — Layer Manager |
| Activos | Implementación o integración personalizada | Core — Asset Manager |
| Edición responsiva | Viewports y configuración | Core — Device Manager |
| Commands | Personalizado, en tu aplicación | Core — Commands |
| Almacenamiento | Responsabilidad de la aplicación | Núcleo — Storage Manager, además de tu integración |
| Datos del proyecto | JSON de hélices componentes | Datos del proyecto: estructura, estilo, recursos y páginas |
| Salida HTML y CSS | No el modelo principal | Caso de uso principal |
| Editor personalizado UI | Altamente personalizable | Altamente personalizable |
| Plugins | Plugin API | Plugin API y ecosistema de mercado |
| Flujos de trabajo de correo electrónico | No es un enfoque documentado | Disponible a través del ecosistema |
Verificado 2026-09-03 contra puckeditor.com/docs y grapesjs.com/docs. Una capacidad marcada como "implementación personalizada" para un proyecto no es un fallo, sino una decisión de diseño sobre qué pertenece a la biblioteca y qué pertenece a tu aplicación.
Estos son módulos documentados del núcleo GrapesJS, y son lo que "una base de editor más amplia" significa concretamente para un creador visual de páginas web, creador de páginas SaaS, editor CMS, creador de correo electrónico o editor de marca blanca.
Un entorno completo de edición visual que renderiza un documento en vivo, no una vista previa de un árbol de componentes.
Define tipos de componentes editables con su propio modelo, traits y comportamiento en el lienzo.
Registra bloques reutilizables de arrastrar y soltar que los usuarios componen páginas.
Controles visuales para tipografía, espaciado, color, dimensiones y más, limitados por selector.
Navega, sube y reutiliza imágenes y otros medios desde dentro del editor.
Define los viewports y permite que los usuarios editen entre puntos de interrupción responsivos.
Conecta los datos del editor a tu propio backend, con almacenamiento local o remoto y autosave.
Extiende el comportamiento del editor de scripts y asigna el comportamiento a tu propio UI.
Añadir funcionalidad sin modificar el editor central — el punto de extensión sobre el que se construye el ecosistema.
Exporta marcado portátil y estilos que puedas renderizar donde quieras.
Extiende el mismo editor para el correo HTML y los flujos de trabajo MJML mediante plugins del ecosistema.
Capacidad por capacidad, en el propio vocabulario de cada proyecto. Ambos proyectos se mueven, así que esto refleja lo que cubre su documentación a fecha de verificación a continuación. Las celdas evitan un simple sí/no donde la respuesta honesta sea "soportado, pero lo configuras o implementas".
| Capacidad | GrapesJS | Puck |
|---|---|---|
| Arquitectura | Editor visual de documentos con su propio árbol de componentes | Árbol de componentes React, editado como props tipados |
| Licencia | BSD-3-Clause core, MIT React wrapper | MIT — @puckeditor/core 0.23.0 |
| Código abierto | Sí | Sí |
| Dependencia de React | Ninguno en el núcleo; el envoltorio oficial de React disponible | Obligatorio — React es el runtime |
| Flexibilidad del marco | Núcleo independiente del framework | Enfoque en React por diseño |
| Lienzo visual | Core — un documento en vivo en un iframe | Integrado — vista previa del mismo origen del iframe |
| Componentes | Tipos de componentes con modelo, vista y traits | Fuerza del core — tus propios componentes React |
| Bloques | Core — Block Manager | Cajón de componentes; campos slot para anidamiento |
| Capas / esquema | Core — Layer Manager | Integrado — región de contorno, reemplazable mediante anulaciones |
| Gestión de estilos | Core — Style Manager con controles visuales CSS | Tu propio CSS y sistema de diseño; el Theming API inspira el editor UI |
| Activos y medios | Núcleo — Asset Manager con fuentes enchufables | Implementación personalizada — suministrar un campo UI o una fuente externa |
| Vista previa del dispositivo | Core — Device Manager | Incorporado — Viewports |
| Edición responsiva | Edición de puntos de interrupción visual mediante el Style Manager | Cambio de viewport; las reglas responsivas están en tu propio CSS |
| Commands | Core — Commands | Responsabilidad de la aplicación — despacho y acciones |
| Deshacer y volver a hacer | Core — UndoManager | Incorporado — historia documentada API |
| Edición de texto enriquecido | RTE integrado, extensible | Incorporado — Componentes de campo richtext y menú de texto enriquecido |
| Componentes personalizados | Componente API — addType() | Core — cualquier componente React más un ComponentConfig |
| Editor personalizado UI | Altamente personalizable — paneles, vistas personalizadas, reemplazo completo de UI | Altamente personalizable — trece ranuras de anulación más composición |
| Plantillas | Plugin — plantillas listados del gestor | Responsabilidad de la aplicación — almacenar y recargar los datos guardados |
| Almacenamiento | Core — Storage Manager, local o en tu backend | Responsabilidad de la aplicación — persistes los datos |
| Datos del proyecto | Componentes, estilos, recursos, páginas y estado del editor | JSON de props de componentes, bajo contenido y raíz |
| Salida HTML y CSS | Caso de uso principal — exporta HTML y CSS portátiles | No el modelo principal — la salida se renderiza React |
| Renderizado React | Integración — montar React o renderizar marcado exportado | Core — un componente de Render reproduce los datos guardados |
| React Server Components | Editor del lado del cliente — revisa tus requisitos de integración | Soporte voluntario, documentado |
| Flujos de trabajo de correo electrónico | Disponible a través del ecosistema de plugins | No es un caso de uso documentado |
| MJML | Plugin — presets y exportación de MJML | No aplicable |
| Plugins | Plugin API y un mercado público | Anulaciones Plugin API y UI |
| Asistencia de IA | No en el núcleo — integración personalizada | Plugin de IA documentada y cliente en la nube |
| Autoalojamiento | Sí — tú diriges el editor | Sí — tú diriges el editor |
| Marca blanca | UI reemplazable, paneles y marca | Anulaciones Theming API y UI |
| Incrustación SaaS | Integra el editor dentro de tu producto | Integra el editor dentro de tu producto React |
| Backend y base de datos personalizados | Storage Manager habla con tu propio API | Responsabilidad de la aplicación — tú eres el propietario del transporte |
| Permisos | Responsabilidad de la aplicación — bloquea los comandos que expones | Incorporado — permisos API y activación de funciones |
| Publicación | Responsabilidad de la aplicación | Responsabilidad de la aplicación |
| Mercado de plugins | GJS.Market — 100+ plugins | Lista de plugins de la comunidad |
Verificado 2026-09-03 con la documentación oficial de cada proyecto. "Core" significa un módulo documentado de la biblioteca; "mediante configuración" e "implementación personalizada" significan que la capacidad es alcanzable pero tu equipo la ensambla. No tener celda aquí significa que un proyecto no puede hacer algo.
npm install grapesjs @grapesjs/reactimport { useRef } from 'react';
import grapesjs from 'grapesjs';
import GjsEditor from '@grapesjs/react';
import 'grapesjs/dist/css/grapes.min.css';
// GrapesJS runs on the client: it owns an iframe canvas and a live document.
// In Next.js, mount it from a client component.
export default function Editor() {
return (
<GjsEditor
grapesjs={grapesjs}
options={{
height: '100vh',
storageManager: { type: 'remote', autosave: true },
}}
onEditor={(editor) => {
// Register the component types you mapped from your Puck config here.
}}
/>
);
}Tus componentes siguen siendo tuyos. El editor se sitúa entre ellos y el documento que tus usuarios están construyendo, y guarda en tu propio backend.
Una forma de producto por fila, un veredicto. Tres de estos van directamente a Puck, y uno es realmente un empate — si cada fila apuntara igual, la tabla no merecería la pena leerla.
| Lo que estás construyendo | Mejor punto de partida |
|---|---|
| Un configurador de componentes React | Puck |
| Un editor para tu sistema de diseño React | Puck |
| Una experiencia de edición altamente personalizada y nativa de React | Puck |
| Un creador de páginas de marketing | GrapesJS |
| Un creador de páginas dentro de tu producto SaaS | GrapesJS |
| Un creador de páginas web orientado al cliente | GrapesJS |
| Un generador de correo electrónico | GrapesJS |
| Un editor visual independiente del framework | GrapesJS |
| Una superficie de edición visual para un CMS sin cabeza | Cualquiera |
Si aún no puedes decir qué fila describe tu producto, elegir un editor es prematuro. Anota las tres cosas que tus usuarios deben poder cambiar, y la respuesta normalmente se resuelve sola.
Esta es la sección que impide que el resto de la página prometa demasiado. GrapesJS proporciona la capa de edición. Tu SaaS sigue siendo dueño de autenticación, autorización, persistencia, facturación, publicación y lógica de negocio — y esa es la mayor parte del proyecto.
Responsabilidades 8
Todo lo que lo convierte en un producto y no en un editor.
Responsabilidades 5
La capa de edición, como módulos documentados que configuras.
Responsabilidades 6
La integración entre ambos — el proyecto real.
Esta es la parte que Puck acierta por defecto, y la parte sobre la que una integración de GrapesJS debe ser deliberada. Tus usuarios deberían trabajar con los componentes y bloques que tengan sentido para tu producto, no con primitivas genéricas de creadores de páginas.
Las secciones de las que está hecha una página de destino.
Bloques en el panel
Piezas reutilizables de cromo e interactivas.
Bloques en el panel
Componentes específicos de la tienda con sus propios datos.
Bloques en el panel
En GrapesJS son tipos de componentes registrados con addType() y expuestos a través del Block Manager, con traits para los accesorios que el usuario puede cambiar. Restringir la paleta a tu propio sistema es lo que mantiene la salida en la marca sin controlarla después.
Explorar bloques y preajustesCuatro editores publicados, todos con el mismo núcleo. Nada carga hasta que haces clic, así que la página se mantiene rápida.
Abrir pantalla completaLa demo propia del proyecto GrapesJS — la línea base libre, con el panel completo por defecto.
Carga una demo externa en un iframe
Agrupado según lo que estás construyendo. Cada tarjeta de abajo es un anuncio real — nombre, precio y miniatura vienen directamente del catálogo, así que nada aquí puede anunciar un plugin que no exista.
React Capas UI y shells de editor para equipos que ponen un constructor dentro de un producto.
Navegar categoríaUna interfaz de editor basada en shadcn/ui, para productos ya construidos sobre esa pila.
React Componentes UI para construir tu propio editor en Chrome.
Un preset orientado a React para empezar en lugar de configurar el editor desde cero.
Una carcasa de editor minimalista que oculta los paneles hasta que se necesitan.
Bloques, páginas, plantillas y auditorías para superficies con mucho contenido.
Navegar categoríaEl conjunto de bloques base que los usuarios arrastran desde el primer día.
Proyectos de varias páginas dentro de una única instancia editora.
Guarda y reutiliza los diseños terminados como plantillas.
Accesibilidad y auditoría SEO dentro del editor.
MJML y herramientas para boletines — el flujo de trabajo que Puck no dirige.
Navegar categoríaAuthoring MJML, para correo electrónico que se renderiza entre clientes.
Un preset de edición orientado a boletines.
Bloqueos seguros para el correo electrónico desde los que escribir mensajes.
Una trampilla de escape HTML/CSS para las piezas que deben ser manuscritas.
Bloques Tailwind, texto enriquecido y controles responsivos para incorporar un sistema existente al lienzo.
Navegar categoríaBloques basados en Tailwind para equipos que ya están en Tailwind.
Una barra de herramientas ampliada de texto enriquecido para edición en línea.
Gestión de puntos de interrupción para edición responsiva.
Cloudinary como fuente de recursos del editor.
Cuatro puntos de partida por tipo de producto. Cada anuncio es real y tiene precios en directo desde el catálogo.
Para un constructor dentro de tu producto
Para sitios con mucho contenido
Para plantillas y campañas
Para una biblioteca de componentes existente
Los precios que se muestran son los precios actuales del catálogo.
Puck y GrapesJS usan modelos de contenido y editor diferentes, por lo que una migración es una transformación del modelo de datos en lugar de un reemplazo de paquete. Todo lo que sigue describe esa transformación.
Tu configuración, más los props de cada componente colocado.
Un documento de proyecto que cubre estructura, estilo, medios y estado editor.
Los modelos de contenido existentes y la configuración del editor deben ser mapeados, no portados. Las dos siguientes secciones muestran el mapeo y la hoja de ruta.
Cada lado tiene su propio vocabulario para la misma idea: algo que los usuarios pueden colocar y las partes que pueden editar. Una migración es la transformación entre ambos.
Una transformación que escribes una vez por tipo de componente. No hay un convertidor automático — este es el trabajo.
Componentes
Cada tipo de componente Puck se convierte en un tipo de componente GrapesJS.
Campos editables
Los campos Puck se convierten en traits, atributos o componentes hijos editables.
Accesorios y valores predeterminados
defaultProps se asignan a los valores predeterminados del modelo de componentes.
Validación
Las restricciones de campo pasan a definir rasgos o a tus propias comprobaciones.
Renderizado
Una función de renderizado React se convierte en marcado que el lienzo puede alojar.
Bloques
Lo que estaba implícito en la configuración se convierte en un registro explícito de bloques.
Contenido almacenado
El Puck JSON existente debe transformarse en datos de proyecto.
Editor UI
Los paneles, campos y anulaciones se reconfiguran, no se portan.
El esfuerzo de migración depende del número de componentes, tu esquema de contenido existente, cualquier comportamiento personalizado de los editores y tus integraciones. Un puñado de componentes simples es una tarea muy diferente a una gran biblioteca con interfaces de campo a medida.
Un antes y después conceptual, simplificado para mostrar la forma de la aplicación. Trata la correspondencia exacta campo-rasgo como ilustrativa en lugar de como una conversión automática universal.
-thumbnail.jpg&w=3840&q=70)
-thumbnail.jpg&w=3840&q=70)
// Puck: a component is configuration + a React render function.
// Field types are documented at puckeditor.com/docs/api-reference/fields
const config = {
components: {
Hero: {
fields: {
title: { type: 'text' },
description: { type: 'textarea' },
image: { type: 'text' },
},
defaultProps: {
title: 'Ship faster',
description: 'The visual editor your team already knows.',
image: '/hero.png',
},
render: ({ title, description, image }) => (
<section className="hero">
<img src={image} alt="" />
<h1>{title}</h1>
<p>{description}</p>
</section>
),
},
},
};// GrapesJS: a component type owns its markup, its editable traits and how it
// is exposed to the canvas. Traits are the closest analogue to Puck fields.
editor.Components.addType('hero', {
model: {
defaults: {
tagName: 'section',
attributes: { class: 'hero' },
traits: [
{ name: 'title', type: 'text', changeProp: true },
{ name: 'description', type: 'text', changeProp: true },
{ name: 'image', type: 'text', changeProp: true },
],
components: [
{ type: 'image' },
{ tagName: 'h1', type: 'text', content: 'Ship faster' },
{ tagName: 'p', type: 'text', content: 'The visual editor…' },
],
},
},
});
// A block is what makes the type draggable from the panel. Puck derives this
// from the config; in GrapesJS it is a separate, explicit registration.
editor.Blocks.add('hero-block', {
label: 'Hero',
category: 'Sections',
content: { type: 'hero' },
});La configuración es solo la mitad. Todo lo que tus usuarios ya guardan es Puck JSON, y tiene que ser recorrido y transformado en componentes que tus nuevos tipos entiendan.
// Existing Puck content is a JSON tree of { type, props } nodes. Migrating it
// means walking that tree and emitting the GrapesJS component definitions your
// new types understand — a transform you write once, per component type.
function puckNodeToGjs(node) {
const map = {
Hero: ({ title, description, image }) => ({
type: 'hero',
title,
description,
image,
}),
// …one entry per component type in your Puck config
};
const toGjs = map[node.type];
if (!toGjs) throw new Error(`Unmapped Puck component: ${node.type}`);
return toGjs(node.props);
}
// Puck stores content under `data.content`; `data.root` holds page-level props.
const components = puckData.content.map(puckNodeToGjs);
editor.setComponents(components);Ejemplo conceptual. Los tipos de campo, las definiciones de rasgos y el modelo exacto de componentes dependerán de tus propios componentes.
Inventario
Haz una lista de lo que existe: los componentes Puck, sus campos, tus tipos de contenido, el JSON guardado, el renderizador y el flujo de publicación. La mayoría de las sorpresas en una migración están en esta lista.
Componentes de la aplicación
Decide la correspondencia antes de escribir código: Puck componente a GrapesJS tipo de componente, Puck campo a rasgo, atributo o UI personalizado, Puck layout a estructura de componentes, Puck datos a datos de proyecto.
Reconstruir el editor UI
Recrea solo la interfaz que realmente usan tus usuarios. Una migración es el momento más barato para dejar los paneles que nadie abrió.
Migrar contenido existente
Recorre el árbol Puck almacenado y emite las definiciones de componentes que tus nuevos tipos entienden. Mantén la transformación en control de versiones: la ejecutarás más de una vez.
Ejecuta ambos en paralelo
Cuando el riesgo es alto, mantén el editor antiguo renderizando contenido antiguo mientras el nuevo toma contenido nuevo. El renderizado dual te da la capacidad de parar.
Validar
Compara la salida visual, el comportamiento responsivo, la publicación, los datos guardados y los flujos de trabajo que realmente realizan tus usuarios — no solo eso que carga el editor.
Corta
Mueve los usuarios una vez que la comparación esté limpia, dejando el camino antiguo accesible hasta que el nuevo haya pasado por un ciclo completo de uso.
Todo lo anterior es la guía: no se requiere correo electrónico, nada bloqueado, ni plazo prometido. El esfuerzo de migración depende de cuántos componentes tengas, cuánta personalización de editores hayas creado y cuánto contenido ya existe, así que no vamos a citar una duración que no podamos respaldar.
Configuración, campos, props y renderizado de Puck, coinciden con los tipos de componentes GrapesJS, traits, bloques y almacenamiento.
Las ocho cosas que hay que mapear por tipo de componente, enumeradas arriba.
Qué Puck persiste frente a lo que contiene un proyecto GrapesJS, y dónde cae cada pieza.
Cómo se monta el editor dentro de una app de React, y qué significa eso en Next.js.
¿Qué subsistemas configurar primero para que el editor parezca terminado en vez de en bruto?
Migrar una superficie a la vez, conservar los originales y la salida renderizada por diferencias contra la fuente.
Podemos ayudarte a mapear tus componentes y modelos de contenido Puck existentes a una implementación GrapesJS lista para producción. El alcance y el calendario se acuerdan tras la revisión de la arquitectura — no citamos plazos antes de ver la base de código.
Revisión de arquitectura
Leemos tu configuración Puck, las personalizaciones del modelo de contenido y del editor, y anotamos lo que realmente tiene que moverse.
Mapeo de componentes
Cada componente Puck se convierte en un tipo específico de componente GrapesJS con su traits, bloque y restricciones.
Migración de datos
Una transformación para tu contenido almacenado, ejecutada contra tus datos reales en lugar de una muestra.
Editor personalizado UI
Los paneles, Chrome e interacciones que tus usuarios necesitan — diseñados para adaptarse a tu producto, no a la demo predeterminada.
Plugins y extensiones
Plugins del marketplace donde encajan, plugins personalizados donde no.
Integración en el backend
Almacenamiento, recursos, permisos y publicación conectados a tu propio API y base de datos.
Pruebas y despliegue
Comparación de salida, revisiones rápidas y un plan de cambio con una forma de regresar.
No hay una única mejor alternativa — depende de para qué esté tu editor. GrapesJS es la opción más sólida cuando necesitas una base más amplia de editor visual con un lienzo, bloques, estilos, capas, recursos y edición responsiva integrada. Craft.js está más cerca de Puck en espíritu como un framework React primero. Si tu editor realmente es un configurador de componentes React, la mejor alternativa puede ser quedarse con Puck.
Sí, para un tipo específico de producto. Ambos permiten crear un editor visual dentro de la app y ambos son de código abierto y autoalojados. Difieren en el punto de partida: Puck edita un árbol de componentes React, GrapesJS edita un documento visual. GrapesJS es una alternativa genuina cuando necesitas el modelo visual del documento; es peor cuando los componentes React son el modelo de contenido.
Puck es un editor React primero construido para componer y configurar tus propios componentes React: sus datos son JSON que describen tipos de componentes y props, y el renderizado se realiza a través de React. GrapesJS es una base más amplia de editor visual construida alrededor de un documento visual, con módulos documentados para componentes, bloques, estilos, capas, recursos, dispositivos, comandos y almacenamiento, y HTML y CSS como salida de primera clase.
Puck se ejecuta dentro de React — React es el tiempo de ejecución tanto del editor como de la salida renderizada. Sus datos son JSON simples, así que otro sistema podría leerlos, pero la experiencia de edición y renderizado es nativa de React por diseño. Eso es una fortaleza para los productos React y una limitación si el mismo editor tiene que ejecutarse en un lugar donde React no es el anfitrión.
Sí. GrapesJS incluye un envoltorio oficial React, @grapesjs/react, y el editor central es independiente del framework, así que se monta dentro de una aplicación React o Next.js como cualquier otro componente del lado del cliente. Consulta la guía de integración GrapesJS React para los patrones de montaje.
Puedes integrar componentes React en un editor GrapesJS, pero no de la manera que Puck. Los tipos de componentes GrapesJS poseen su marcado en el documento canvas, por lo que un componente React normalmente se refleja como un tipo GrapesJS con traits correspondiente, o se renderiza en el lienzo a través de una vista personalizada. Es una capa de integración en lugar del modelo nativo.
Sí. GrapesJS es un editor del lado del cliente que posee un lienzo iframe, así que tiene que montarse desde un componente cliente. En Pages Router eso suele significar una importación dinámica con SSR desactivado; en App Router un componente cliente es suficiente.
No como modelo principal. Puck edita props de componentes, y el marcado y el estilo provienen de los componentes React que has escrito. Por supuesto, puedes construir un componente que acepte marcado en bruto o nombres de clase, pero no hay una superficie visual documentada de edición HTML o CSS como GrapesJS proporciona un Style Manager y un documento editable.
Sí — está diseñado para ser incrustado y se utiliza como capa de edición dentro de los productos SaaS. Proporciona el editor, no el producto: autenticación, organizaciones, permisos, facturación, persistencia y publicación siguen siendo tuyos para construir.
Sí. Ese es el caso de uso principal: un lienzo, una paleta de bloques, controles de estilo, capas, recursos, dispositivos responsivos y salida HTML y CSS. Lo que añades es tu propia biblioteca de bloques, editor UI y almacenamiento.
Sí. El editor UI es reemplazable: paneles, botones y vistas pueden intercambiarse o reconstruirse, y no hay una marca de fabricante que tengas que mostrar. La marca multi-inquilino, los conjuntos de bloques por inquilino y los permisos son cosas que tu aplicación implementa encima.
Sí, usando plugins del ecosistema para bloques de correo electrónico y autoría y exportación de MJML. El renderizado de correo es una disciplina aparte: ningún editor puede garantizar compatibilidad universal entre correo y cliente, así que las plantillas aún necesitan pruebas en los clientes que tus destinatarios realmente usan.
Sí, transformándolo. Puck almacena un árbol JSON de tipos de componentes y props; GrapesJS almacena datos de proyectos que describen componentes, estilos, recursos y páginas. La migración significa recorrer el árbol Puck y emitir las definiciones de componentes GrapesJS que tus nuevos tipos entienden — una transformación que escribes una vez por tipo de componente.
No. No hay un convertidor automático, y cualquier página que lo afirme lo está exagerando. Los dos editores persisten cosas diferentes, así que el mapeo depende de tus componentes y de tu esquema de contenido. Lo que se puede reutilizar es la forma de la transformación, que muestra esta página.
Depende del número de tipos de componentes, de cuánto comportamiento personalizado de editor hayas construido, de cuánto contenido ya existe y de lo acoplado que está tu renderizador con React. No publicamos una duración, porque una migración de seis componentes con datos limpios y una de sesenta con JSON editado a mano no son el mismo proyecto.
Sí, pero lo conectas deliberadamente. Normalmente registras un tipo de componente GrapesJS por cada componente del sistema de diseño, expones los props que los usuarios pueden cambiar como traits y añades cada uno al Block Manager. Esa restricción es lo que mantiene la salida en marca.
Sí. El Storage Manager se puede configurar para leer y escribir a través de tu propio API, así que los datos del proyecto permanecen en tu base de datos en la forma que elijas. Nada tiene que pasar por un servicio de terceros.
Sí. Es un paquete npm que incluyes en tu propia aplicación — no hay servicio alojado, ni cuenta ni licencia por asiento. El núcleo está licenciado por BSD-3-Clause y el envoltorio de React es MIT.
No. GrapesJS es totalmente utilizable sin ningún plugin del marketplace, y los módulos principales son gratuitos y de código abierto. Los plugins existen para que puedas comprar una capacidad en lugar de construirla — un editor UI shell, herramientas de correo electrónico, una biblioteca de bloques — cuando ese intercambio merece la pena para tu equipo.
Solo si tu editor ya ha superado el modelo de configurador de componentes. Si los usuarios piden estilo visual, bloques, capas, recursos, plantillas, controles responsivos o salida no React, una base más amplia ahorrará trabajo. Si tu editor compone tus componentes React y eso es lo que debe seguir haciendo, quedarse en Puck es la decisión correcta.
Si Puck ya encaja en tu modelo de componente React, puede que no haya razón para cambiar. Pero si tu editor se está convirtiendo en un producto visual completo, GrapesJS te da una base más amplia sobre la que construir, personalizar y ampliar.
Abre un editor en vivo, luego lee la documentación y construye. No hay nada que instalar para empezar a buscar.
Abre una demo en directoExtiende el editor con lo que construirías de otro modo: shells UI, bloques, correo electrónico, recursos y almacenamiento.
Explorar pluginsAuditamos tu implementación de Puck, diseñamos la arquitectura objetivo y hacemos la migración contigo.
Habla con un experto