La Pesadilla del WYSIWYG
Ha pasado algo raro en los últimos años.
Los desarrolladores construimos sistemas cada vez más sofisticados, usamos herramientas de IA avanzadas, desplegamos en minutos... pero cuando llega el momento de gestionar contenido, volvemos a 2005.
WYSIWYG editors. HTML sucio. Editores de texto que prometen "facilidad" pero entregan caos.
La realidad es brutal: estos editores crean deuda técnica masiva. El contenido queda atrapado en HTML malformado, imposible de reutilizar, difícil de versionar, y un pesadilla para sincronizar entre plataformas.
Eso es lo que yo llamo perder la cordura en el desarrollo.
Portable Text: La Alternativa que Necesitabas
Portable Text es JSON puro. Punto.
No es HTML. No es Markdown. Es una estructura de datos clara, versionable y agnóstica de plataforma que describe contenido de forma que tu código puede entender y manipular realmente.
La idea es simple pero poderosa: en lugar de almacenar `<p>Hola <strong>mundo</strong></p>`, almacenas:
```json { "_type": "block", "style": "normal", "children": [ { "_type": "span", "text": "Hola ", "marks": [] }, { "_type": "span", "text": "mundo", "marks": ["strong"] } ] } ```
Parecer más verboso, ¿verdad? Incorrecto.
Esta estructura es versionable, queryable, transformable. Puedes renderizarla como HTML, como Markdown, como componentes React, como lo que necesites. El contenido es agnóstico.
Por Qué los Builders lo Usan (y Tú Deberías También)
1. Bloques Personalizados
Con WYSIWYG estás limitado a lo que el editor permite. Con Portable Text, defines tus propios bloques.
Necesitas un bloque de código con syntax highlighting? Créalo. ¿Un componente interactivo? Defínelo en tu esquema. ¿Una galería con metadatos? Hazlo.
```json { "_type": "codeBlock", "language": "javascript", "code": "const builder = (idea) => ship(idea);", "filename": "philosophy.js" } ```
Tu contenido crece con tu producto. No al revés.
2. Marks Personalizados
Los marks en Portable Text son como estilos inline, pero sin las limitaciones de HTML.
Puedes crear marks para:
- Enlaces internos (con validación de rutas)
- Menciones de usuarios
- Resaltados con contexto
- Referencias a entidades en tu base de datos
```json { "_type": "span", "text": "Este proyecto", "marks": [{ "_type": "internalLink", "reference": { "_type": "reference", "_ref": "project-123" } }] } ```
El contenido se convierte en datos estructurados. Eso es poder real.
3. Versionado y Diffs Legibles
Con HTML, un cambio pequeño puede romper todo el árbol. Con JSON, los diffs son claros y humanos.
Git entiende Portable Text. Los desarrolladores entienden Portable Text. Tu equipo puede colaborar sin miedo a corromper contenido.
4. Reutilización Entre Plataformas
Escribiste contenido para tu web. Ahora necesitas mostrarlo en tu app móvil, en tu newsletter, en tu CMS alternativo.
Con HTML, copias y rezas. Con Portable Text, renderizas según tu plataforma.
Un contenido. Infinitas presentaciones.
Implementación Práctica
La forma más accesible de empezar es con Sanity.io, que es el creador de Portable Text y lo mantiene como estándar abierto.
Pero también puedes implementarlo desde cero. La estructura es simple:
```javascript // Definir tu esquema const articleSchema = { name: 'article', fields: [ { name: 'title', type: 'string' }, { name: 'content', type: 'array', of: [ { type: 'block' }, { type: 'object', name: 'codeBlock', fields: [ { name: 'code', type: 'text' }, { name: 'language', type: 'string' } ] } ] } ] };
// Renderizar const renderPortableText = (blocks) => { return blocks.map(block => { if (block._type === 'block') { return renderParagraph(block); } if (block._type === 'codeBlock') { return renderCode(block); } return null; }); }; ```
Eso es. Desde ahí, construyes tu lógica de renderizado según tus necesidades.
La Cordura en el Contexto Real
Cuando digo "mantener la cordura", no es poético.
Es literal.
He visto proyectos donde el contenido estaba tan enredado en HTML que los cambios tomaban horas. Developers asustados de tocar el contenido. Editores frustrados porque no podían hacer lo que necesitaban.
Con Portable Text:
- Tu editor trabaja en una interfaz amigable (Sanity, Keystatic, lo que uses)
- Tu developer recibe JSON limpio y estructurado
- Tu producto crece sin deuda técnica
- Tu contenido es un asset, no un pasivo
La Realidad de la Adopción
Muchos desarrolladores siguen usando WYSIWYG porque es lo que conocen. Es la inercia.
Pero cada vez más builders modernos están migrando. ¿Por qué? Porque cuando trabajas con IA, con sistemas dinámicos, con múltiples plataformas, necesitas que tu contenido sea datos.
Portable Text es eso.
No es perfecto para todo. Si tu caso de uso es "blog simple con párrafos", Markdown es más rápido. Pero si necesitas flexibilidad, reutilización y cordura a largo plazo, Portable Text es tu respuesta.
Takeaway
La pregunta no es si deberías usar Portable Text.
La pregunta es cuánto tiempo más vas a invertir en soluciones que no escalan con tu producto.
Empieza pequeño. Define un bloque personalizado. Implementa un mark. Renderiza en tu frontend. Verás la diferencia inmediatamente.
Tu contenido merece ser datos. Tu cordura merece algo mejor que WYSIWYG.
Hazlo.