- Primo v3.2 representa un sitio tanto como archivos locales como filas en una base de datos del servidor, lo que permite que los agentes corrijan código y que editores no técnicos modifiquen el mismo sitio desde el navegador
- Los desarrolladores trabajan con páginas, contenido, configuración y rutas mediante componentes Svelte y archivos YAML, y los sincronizan con la base de datos relacional del servidor usando
primo push
- El editor en el navegador ofrece edición de texto sobre la página renderizada, arrastrar y soltar bloques, tipos de página y campos personalizados, reduciendo la dependencia de pantallas de CMS centradas en formularios
- El público principal son desarrolladores, freelancers y agencias que necesitan entregar sitios personalizados a editores no técnicos, y ofrece 12 starters y más de 40 bloques
- El contenido queda en SQLite basado en PocketBase, el código permanece en el repositorio del usuario, y la licencia MIT junto con la exportación estática mediante
primo pull ayudan a reducir la dependencia del servicio
Un modelo de CMS que usa archivos y base de datos a la vez
- Primo v3.2 es un CMS open source que existe desde 2019 y representa todo el sitio simultáneamente como archivos y como filas de una base de datos
- Los archivos locales son modificados directamente por agentes, mientras que la base de datos del servidor se usa como objetivo para que las personas editen visualmente desde el navegador
- El flujo básico consiste en crear el sitio con un agente y luego entregar permisos de edición en el navegador a un cliente o conocido
- En el ejemplo,
claude crea un tipo de página de precios, escribe pages/pricing.yaml y blocks/pricing-tiers/component.svelte, y después despliega 3 archivos con primo push
- Después del despliegue, el usuario puede modificar directamente desde el navegador los textos y precios de los tiers de precios
Estructura de archivos local que manejan los agentes
primo pull descarga todo el sitio como archivos comunes
- Incluye componentes, páginas, contenido, configuración y rutas
- Los bloques son componentes Svelte, y el contenido y la configuración son YAML
- Se puede generar el scaffold de un sitio nuevo o descargar un sitio existente
- Agentes CLI como Claude Code, Cursor y Codex modifican todo el repositorio
- Es un flujo en el que se edita toda la base de código, como al trabajar con una codebase de Next.js o SvelteKit
- El comando de ejemplo es
$ claude "redesign the pricing page"
primo push sincroniza los archivos modificados con la base de datos relacional del servidor
- El cliente edita el mismo sitio desde el navegador sobre la página renderizada
- Los campos declarados por los bloques se exponen como campos editables
CMS que se edita sobre la página renderizada
- El editor funciona sobre la página renderizada y no exige una pestaña de CMS ni una vista de formulario separada como experiencia de edición principal
- Todos los campos declarados por un bloque se muestran como superficies clicables y etiquetas
- Usa el mismo modelo que lee el renderer, sin una capa de transformación separada
- La edición en página consiste en hacer clic en el texto de la página renderizada y escribir directamente
- Un chip de campo indica el elemento que se está editando en ese momento
- Con bloques de arrastrar y soltar, se pueden reordenar, agregar y eliminar bloques en el árbol de la página, y registrar los cambios directamente en la fuente
- Los tipos de página personalizados permiten definir una vez la forma de una página, para que el cliente pueda crear tantas páginas como necesite sin romper el mismo modelo
- Los campos personalizados soportan texto, texto enriquecido, imágenes, enlaces, números, grupos y repetidores
- La UI de edición se genera a partir del schema
- La colaboración en tiempo real permite que varias personas editen la misma página al mismo tiempo, e incluye presencia en vivo y edición sin conflictos
- La vista de formulario estructurada se usa para campos que no se ven en la página, como SEO, metadata, repetidores y configuraciones ocultas
Starters y bloques para creadores de sitios personalizados
- Primo está orientado a desarrolladores, freelancers y agencias que crean sitios personalizados para editores no técnicos
- El marketplace ofrece starters por tipo de cliente y bloques de secciones comunes
- Se mencionan como ejemplos starters para restaurantes, coaches, portafolios y servicios locales
- La oferta es de 12 starters y más de 40 bloques
- Cada starter es un sitio autocontenido
- Incluye componentes Svelte y campos de tipo
- Se genera como scaffold en el repositorio
- No hay lock-in de framework ni runtime oculto
- Los usuarios pueden hacer fork de un starter, modificarlo y desplegarlo, o curar sus propios starters y bloques
Diferencias con WordPress, headless CMS y site builders
- WordPress se compara como una opción que ofrece sitios editables por el cliente, pero con una estructura donde el contenido y los temas PHP quedan entrelazados
- Los headless CMS pueden dar una estructura de código limpia, pero el schema vive en una pantalla de administración separada
- Los site builders ofrecen arrastrar y soltar, pero se contrastan como una forma de alquilar el resultado dentro de una plataforma
- La diferencia que enfatiza Primo es que el equipo y los agentes editan juntos una sola fuente de verdad
- La ubicación del código son archivos Svelte y el repositorio del usuario
- La ubicación de edición del cliente es la página renderizada
- El schema se coloca en
fields.yaml junto al .svelte
- Los agentes pueden editar todo el sitio como archivos
- El hosting y la licencia se presentan como self-host y MIT
Propiedad de los datos y estado operativo
- El contenido se almacena en SQLite mediante PocketBase, y el código queda en el repositorio del usuario
primo pull ofrece en cualquier momento una exportación estática de código y contenido- Primo tiene licencia MIT e indica que, aunque el proyecto desaparezca, el código en ejecución y los sitios construidos seguirán funcionando
- Su estado operativo es v3.2 en su séptimo año, con casos de sitios en producción como trabajos de clientes de agencias, pequeñas tiendas de comercio, sitios de documentación y páginas propias de marketing
- Los agentes no se tratan como un producto nuevo, sino como un nuevo cliente del mismo modelo mantenido desde 2019
Payload, TinaCMS, Sanity Studio y soporte de React
- Payload es un headless CMS cuya estructura tiene el schema en la pantalla de administración y trae el contenido mediante una API
- TinaCMS se compara como una forma de poner un editor basado en Git delante de archivos Markdown
- Sanity Studio es una pantalla de administración basada en React sobre un content lake alojado
- En Primo, el editor y el renderer leen los mismos archivos Svelte y filas de base de datos, sin una capa intermedia de transformación vía API
- React actualmente no es compatible dentro de los bloques de Primo
- Primo fue creado alrededor del enfoque de compile time de Svelte, y esa estructura convierte los bloques en archivos que el editor y el renderer pueden leer directamente
- El soporte de React dentro de bloques de Primo no está en el roadmap
- En el roadmap está
primo integrate <framework>
- Primero aparece la idea de montar Primo sobre una app SvelteKit existente
- Luego se menciona Astro, y Next.js queda como aspiración
- En esta dirección, los componentes de producción permanecen en ese framework y Primo solo se encarga del contenido y del editor
Estructura de bloques y autenticación de CLI
- Un bloque se compone de dos archivos colocados juntos
- El componente se encarga del renderizado
- El schema le indica al editor qué campos existen
- El ejemplo
blocks/hero/fields.yaml declara los campos headline, subheadline y cta
headline y subheadline son textcta es link
- La autenticación de la CLI lee
PRIMO_TOKEN desde las variables de entorno
- El token se genera por sitio desde la pantalla de administración
primo pull <host> clona el proyectoprimo push sube solo los archivos modificados
- La autenticación es la misma que usan los editores y no hace falta aprender una superficie de API separada
- Funciona sobre HTTPS con cualquier instancia de Primo, incluidas las self-hosted
Comando de inicio
- Un workspace nuevo se crea con el siguiente comando
npx primo-cli init my-workspace
- Después de crearlo, se muestran los estados
workspace ready y server.yaml written
- El texto de licencia y precio se presenta como MIT, open source y gratis para siempre
1 comentarios
Comentarios en Hacker News
Los editores CMS de arrastrar y soltar se ven geniales en los demos, pero al operar uno similar dentro de la empresa fue un infierno interminable de actualizaciones
Seguían llegando pedidos como “¿se puede alinear el texto a la derecha y ponerlo azul?”, y al final cada bloque terminaba acumulando más y más propiedades
A quienes realmente escriben el contenido les cuesta usarlo de forma efectiva y el resultado en general tampoco suele ser satisfactorio
Con más capacitación podría mejorar, pero el compromiso entre libertad y mantener la identidad de marca sigue estando ahí
En nuestro caso, un CMS headless parece un mejor enfoque. Que solo entregue el contenido y que unos pocos especialistas lo implementen en código según el diseño funciona mejor, aunque no todo el mundo tiene ese margen, así que claramente también hay espacio para este tipo de CMS
Hace unos meses rediseñamos el sitio de ecommerce de un cliente e hicimos secciones/bloques editables con Maglev, y la experiencia de edición en sí fue buena
Pero después del lanzamiento, el cliente contrató a una persona de marketing con conocimientos muy básicos de HTML/CSS, y costó convencerla de que en vez de escribir HTML/CSS directamente, debía pedir a los desarrolladores que crearan las secciones que necesitaba
Podríamos meter un editor para desarrolladores como Primo, pero por experiencia de muchos años no queremos que los clientes toquen directamente el HTML/CSS del sitio
Tampoco queremos una relación del tipo “si lo rompes, pagas”
Viéndolo más ampliamente, cualquier CMS tiene el mismo problema. Incluso ayudamos a una empresa cuyo sitio en Webflow había quedado roto, en el típico caso donde un diseñador lo hizo y luego alguien de marketing intentó “mejorar” la UI y terminó rompiendo todo
Hay un límite en la cantidad de componentes que se pueden crear
Idealmente, hace falta un CMS que permita a los clientes cambiar HTML fácilmente sin código. Así carga rápido, tiene buena optimización para buscadores y los desarrolladores no tienen que reinventar la rueda
Por eso hice Versoly(https://versoly.com/). Me preguntaba por qué había que contactar a un desarrollador cada vez que uno quería cambiar el color de fondo o agregar una sección nueva
Pero, uses el CMS que uses, me parece que igual sigue existiendo el problema de que los editores de contenido quieren alinear el texto a la derecha y ponerlo azul
Todavía casi no hay documentación oficial, pero si te interesa me gustaría que vieras la primera página y me dijeras si parece algo que valdría la pena usar
También me gustaría escuchar feedback general o aprendizajes de experiencias reales
https://brick-cms.com/
GitHub:
https://github.com/primocms/primo
Discusiones anteriores:
https://news.ycombinator.com/item?id=23820201
https://news.ycombinator.com/item?id=25301040
Un Show HN con texto desde lo que parece ser otra cuenta del autor original:
https://news.ycombinator.com/item?id=36801101
Parece que SSG significa generador de sitios estáticos (Static Site Generator), pero me da la impresión de que, apenas te sales un poco de cierto nicho, hace falta intentar escribirlo de forma que sea fácil de entender para quien lo lea
Incluso trabajando en desarrollo web, tuve que pensarlo un momento para descifrar la sigla
Aun así, para los usuarios que todavía no lo conocen, podría ser más útil escribirlo completo
Estaría bueno tener una herramienta así para manejar contenido dinámico secuencial, como posts de blog o reseñas
Mucha gente sigue pegada a WordPress, pero la personalización y los temas son casi una pesadilla
En su momento era una de las casi únicas formas de crear un blog fácilmente
El problema es que, apenas te sales del caso estándar, de pronto necesitas un conocimiento profundo de la estructura interna de WordPress
Hace unos 3 años, HN puso al CMS open source Primo en la portada(https://news.ycombinator.com/item?id=23820201), y gracias a eso dejé un trabajo remoto cómodo en plena pandemia para dedicarme a esto de tiempo completo
Después me gasté todos los ahorros, perdí el dominio primo.af ante los Taliban, e incluso convencí a mi esposa de volverse desarrolladora/diseñadora para ayudarme
Aun así, me siento orgulloso de lo que hemos hecho, y al ver que ayuda a la gente a aprender desarrollo web, publicar sitios personales y administrar sitios de clientes, me convenzo todavía más del poder y la simplicidad de este enfoque
Hoy lanzamos en beta pública Primo 2, que ofrece edición de contenido sobre la página, construcción de páginas y más
Empecé a crear Primo por el cansancio de hacer sitios web y de la realidad de que a los usuarios no técnicos les cuesta administrarlos
En proyectos freelance sufrí con temas frágiles de WordPress, navegación por dashboards y combinaciones de plugins, y como desarrollador de agencia sentía que los CMS monolíticos y los meta-frameworks/CMS headless eran demasiado para landing pages o sitios de presentación
Como instructor de programación, vi a estudiantes intimidarse al encontrarse con CLI, API, gestores de paquetes, bundlers, frameworks y meta-frameworks al intentar aprovechar la web
No había un camino simple y accesible para crear, administrar, desarrollar y alojar sitios web comunes como blogs, landing pages y sitios de presentación
Primo es, en esencia, un CMS que facilita la gestión de contenido, pero además reúne en una sola interfaz construcción de páginas, edición de código, generación de sitios estáticos y despliegue/hosting en GitHub
Los bloques están escritos en Svelte, es decir, HTML/CSS/JS, por lo que son responsivos y sus estilos están encapsulados
Al ser un sitio estático, también se obtienen las ventajas serverless en costo, seguridad, escalabilidad y velocidad
Primo es una herramienta para quienes quieren tener control total de su sitio con HTML/CSS/JavaScript, pero al mismo tiempo darles a sí mismos y a sus amigos/clientes/colaboradores no técnicos una experiencia de edición de contenido muy simple, más que para quienes prefieren controles de diseño WYSIWYG al estilo SquareWixFlow
Está pensado para quienes se sienten limitados por las herramientas no-code y las plataformas propietarias, pero quieren algo más simple sin perder el poder del código
Más allá de eso, Primo es un intento de mantener la web en manos de las personas
Espero que, al hacer la publicación web más accesible, podamos aumentar la alfabetización tecnológica y dar a la gente una forma de expresión libre para que no termine empujada tan fácilmente hacia cajas negras y jardines amurallados
Pero el sistema de gestión de contenido fue el problema. Esperaba algo como un generador de sitios estáticos normal, donde pones archivos Markdown en carpetas y se generan artículos o posts de blog según una plantilla
En algún momento hice un fork del repositorio de Primo e implementé una solución personalizada para convertir entradas de la base de datos en una estructura de archivos/carpetas, pero la operación inversa parecía complicada, así que tomé otro camino, me inspiré en esta guía y construí mi propio generador de sitios estáticos en Markdown: https://joshcollinsworth.com/blog/build-static-sveltekit-mar...
Puede que mi caso de uso no sea el objetivo principal, pero si el proyecto pudiera guardarse como una estructura dinámica de archivos/carpetas en lugar de escribirse en una base de datos, y editarse/controlarse por versiones como un proyecto normal de SvelteKit, creo que sería un producto excelente
En esencia, sería un framework de generación de sitios estáticos basado en Svelte con una biblioteca de componentes y una UI dedicada
El foro también está bueno, y varias de las preguntas que tenía ya estaban respondidas
He usado WordPress por mucho tiempo y recientemente he estado probando Svelte; esto de verdad se acerca mucho a lo que estaba buscando
Mucho respeto por el esfuerzo que se invirtió en construir esto
Es un buen proyecto, pero sinceramente es un poco decepcionante que para “self-hosting” necesites una cuenta de Supabase
Parece que solo funciona en ciertos servicios de hosting que pueden conectarse a Supabase, y te empuja a traer el contenido de las páginas desde GitHub
Así que parece menos un CMS que realmente puedes self-hostear y más un CMS que corre junto con ciertos proveedores de servicios específicos
El objetivo era hacer que a la gente le resultara lo más fácil posible levantar su propio servidor, y por eso terminó conectado a esos servicios
Aun así, estamos separando el backend para que realmente se pueda hostear por cuenta propia
El único servicio externo realmente necesario es GitHub, y después quizá se puedan agregar otros proveedores como GitLab
Buen proyecto, pero sinceramente siento que ya llegamos a un punto en el que, tanto para desarrolladores como para usuarios, es mejor menos JavaScript, o incluso sin JavaScript
Estoy migrando mi blog viejo a uno nuevo generado con Zola(https://www.getzola.org), y también estoy rehaciendo con Zola un sitio de portafolio nuevo que había hecho con React/Gatsby porque la diferencia de rendimiento es demasiado grande
A veces incluso navego la web con JavaScript desactivado, y si en ese estado un sitio no funciona del todo o ni siquiera carga, eso es un defecto grave
Mi sitio anterior usaba jQuery y ya me molestaba un poco, y probar cosas como React fue una pesadilla
Internamente usa el compilador de Svelte
Cuesta casi creer que ya pasaron más de 10 años desde que hice un generador de sitios llamado Stiqr en 2010
El sitio ya no está en funcionamiento, pero todavía se pueden ver rastros en un video de YouTube
https://www.youtube.com/watch?v=B-ff53t8TuU&t=224s
En ese entonces, en 2010, el diseño responsivo empezó a despegar y por eso terminé abandonando el proyecto, pero sigo creyendo que esta sigue siendo la dirección del futuro cercano para crear sitios web
La combinación de arrastrar y soltar / bloques con Svelte es realmente genial, pero para mí parece una herramienta que está en el extremo equivocado del espectro
Esto es un constructor visual de sitios web donde se personalizan bloques en un editor en línea
Lo que yo quiero es una interfaz en línea donde el cliente pueda agregar o cambiar texto, o hacer pequeños ajustes, sobre un sitio web en Svelte que yo hice offline con mis propias herramientas
Estaría bien que, si hago el sitio siguiendo cierto estándar de interfaz, Primo pudiera leerlo y el cliente pudiera editarlo desde una interfaz visual
Los cambios grandes volverían a mí, y yo podría mantener la velocidad y la libertad de mi flujo de trabajo offline
Se podría decir que necesito un CMS headless, pero todos los que he probado eran excesivamente complejos y solo la configuración y el mantenimiento ya daban un dolor de cabeza enorme
A menos que crees campos específicos, no puede editar aspectos visuales como, por ejemplo, hacer que una imagen sea circular o cuadrada
Si el problema es no poder usar un IDE local, actualmente es posible empaquetar componentes de Svelte como vanilla JavaScript, importarlos a bloques de Primo y pasarles datos mediante campos
Aun así, hasta que se estabilice, sería mejor esperar unas semanas antes de usarlo en producción
De hecho, la forma que describes es prácticamente igual a como yo manejo proyectos de clientes: escribo todo el código, normalmente reutilizo bloques de otros proyectos y luego entrego un sitio que el cliente puede editar desde el primer día con una capacitación mínima
Me pregunto si con “personalización de bloques” quieres decir que no incluye cambiar texto, o si quieres decir que las acciones posibles no están lo suficientemente limitadas como para entregárselo a un cliente
Puedes insertar secciones gestionadas con arrastrar y soltar dentro del marcado normal de la página, y parece que es compatible con la mayoría de los frameworks, incluido Svelte
La configuración se puede hacer por FTP