- Primo v3.2 representa um site ao mesmo tempo como arquivos locais e linhas em um banco de dados no servidor, permitindo que agentes corrijam o código e que editores não técnicos alterem o mesmo site no navegador
- Desenvolvedores lidam com páginas, conteúdo, configurações e rotas por meio de componentes Svelte e arquivos YAML, sincronizando tudo com o banco de dados relacional do servidor via
primo push
- O editor no navegador oferece edição de texto sobre a página renderizada, arrastar e soltar blocos, tipos de página e campos personalizados, reduzindo a dependência de telas de CMS centradas em formulários
- O público principal são desenvolvedores, freelancers e agências que precisam entregar sites personalizados a editores não técnicos, com 12 starters e mais de 40 blocos disponíveis
- O conteúdo fica em SQLite baseado em PocketBase, o código permanece no repositório do usuário, e a licença MIT junto com a exportação estática via
primo pull reduzem a dependência do serviço
Modelo de CMS que usa arquivos e banco de dados em conjunto
- Primo v3.2 é um CMS open source mantido desde 2019, que representa o site inteiro simultaneamente como arquivos e linhas de banco de dados
- Os arquivos locais são editados diretamente por agentes, enquanto o banco de dados do servidor é usado como alvo para edição visual por pessoas no navegador
- O fluxo básico é criar o site com um agente e, depois, repassar permissões de edição no navegador para o cliente ou para conhecidos
- No exemplo,
claude cria um tipo de página de preços, escreve pages/pricing.yaml e blocks/pricing-tiers/component.svelte, e então publica 3 arquivos com primo push
- Após a publicação, o usuário pode editar diretamente no navegador o texto dos planos de preço e os valores
Estrutura de arquivos local manipulada por agentes
primo pull baixa o site inteiro como arquivos comuns
- Inclui componentes, páginas, conteúdo, configurações e rotas
- Blocos são componentes Svelte, enquanto conteúdo e configurações ficam em YAML
- É possível criar um novo site por scaffold ou baixar um site existente
- Agentes de CLI como Claude Code, Cursor e Codex modificam o repositório inteiro
- É um fluxo de edição do codebase completo, como ao lidar com uma base em Next.js ou SvelteKit
- O comando de exemplo é
$ claude "redesign the pricing page"
primo push sincroniza os arquivos alterados com o banco de dados relacional do servidor
- O cliente edita o mesmo site no navegador, sobre a página renderizada
- Os campos declarados pelos blocos são expostos como campos editáveis
CMS editado sobre a página renderizada
- O editor funciona sobre a página renderizada e não exige, como experiência padrão de edição, uma aba separada de CMS nem uma visualização de formulário
- Todos os campos declarados pelo bloco aparecem como superfícies clicáveis e rótulos
- Usa o mesmo modelo lido pelo renderer, sem uma camada separada de transformação
- A edição on-page permite clicar no texto da página renderizada e digitar diretamente
- Um chip de campo indica o item que está sendo editado no momento
- Com blocos de arrastar e soltar, é possível reordenar, adicionar e remover blocos na árvore da página, gravando as alterações diretamente na origem
- Tipos de página personalizados permitem definir uma vez o formato da página, para que o cliente crie quantas páginas forem necessárias sem quebrar o mesmo modelo
- Campos personalizados oferecem suporte a texto, rich text, imagem, link, número, grupo e repeater
- A UI de edição é gerada a partir do schema
- A colaboração em tempo real permite que várias pessoas editem a mesma página simultaneamente, incluindo indicação de presença ao vivo e edição sem conflitos
- A visualização estruturada em formulários é usada para campos que não aparecem na página, como SEO, metadados, repeaters e configurações ocultas
Starters e blocos para criadores de sites personalizados
- O Primo é voltado a desenvolvedores, freelancers e agências que criam sites personalizados para editores não técnicos
- O marketplace oferece starters por tipo de cliente e blocos de seções comuns
- Starters para restaurantes, coaches, portfólios e serviços locais aparecem como exemplos
- A oferta inclui 12 starters e mais de 40 blocos
- Cada starter é um site autocontido
- Inclui componentes Svelte e campos tipados
- É gerado por scaffold em um repositório
- Não há lock-in de framework nem runtime oculto
- Usuários podem fazer fork de starters, modificá-los e publicar, ou curar seus próprios starters e blocos
Diferenças em relação a WordPress, Headless CMS e site builders
- O WordPress oferece sites editáveis por clientes, mas é comparado por sua estrutura em que conteúdo e temas PHP ficam entrelaçados
- Headless CMSs podem deixar a estrutura de código limpa, mas o schema fica em uma tela administrativa separada
- Site builders oferecem drag-and-drop, mas são contrapostos como um modelo em que o resultado é alugado da plataforma
- A diferença enfatizada pelo Primo é que uma única fonte é editada em conjunto pela equipe e por agentes
- O local do código são arquivos Svelte e o repositório do usuário
- O local de edição do cliente é a página renderizada
- O schema fica em
fields.yaml ao lado do .svelte
- Agentes podem editar o site inteiro como arquivos
- Hospedagem e licença são apresentadas como self-host e MIT
Propriedade dos dados e estado operacional
- O conteúdo é armazenado em SQLite via PocketBase, e o código permanece no repositório do usuário
primo pull oferece, a qualquer momento, uma exportação estática de código e conteúdo- O Primo tem licença MIT e afirma que, mesmo se o projeto desaparecer, o código em execução e os sites construídos continuarão funcionando
- O estado operacional é v3.2 no 7º ano, com exemplos de sites em produção como trabalhos de clientes de agências, pequenas lojas de e-commerce, sites de documentação e páginas próprias de marketing
- Agentes são tratados não como um produto novo, mas como um novo cliente do mesmo modelo mantido desde 2019
Payload, TinaCMS, Sanity Studio e suporte a React
- Payload é um headless CMS em que o schema fica na tela administrativa e o conteúdo é obtido via API
- TinaCMS é comparado como uma abordagem que coloca um editor baseado em Git na frente de arquivos Markdown
- Sanity Studio é uma tela administrativa baseada em React sobre um content lake hospedado
- No Primo, o editor e o renderer leem os mesmos arquivos Svelte e linhas de banco de dados, sem uma camada de transformação por API entre eles
- React não é suportado atualmente em blocos do Primo
- O Primo foi construído em torno da abordagem de compile time do Svelte, e essa estrutura torna os blocos arquivos que podem ser lidos diretamente pelo editor e pelo renderer
- Suporte a React dentro de blocos do Primo não está no roadmap
- O roadmap inclui
primo integrate <framework>
- A primeira abordagem será colocar o Primo sobre um app SvelteKit existente
- Depois, Astro é mencionado, e Next.js permanece como um desejo
- Nessa direção, os componentes de produção permanecem no respectivo framework, enquanto o Primo cuida apenas do conteúdo e do editor
Estrutura de blocos e autenticação da CLI
- Um bloco é composto por dois arquivos colocados juntos
- O componente é responsável pela renderização
- O schema informa ao editor quais campos existem
- O exemplo
blocks/hero/fields.yaml declara os campos headline, subheadline e cta
headline e subheadline são textcta é link
- A autenticação da CLI lê o
PRIMO_TOKEN das variáveis de ambiente
- O token é gerado na tela administrativa para cada site
primo pull <host> clona o projetoprimo push envia apenas os arquivos alterados
- A autenticação é a mesma usada pelo editor, sem necessidade de aprender uma superfície de API separada
- Funciona em todas as instâncias Primo via HTTPS, incluindo instâncias self-hosted
Comando inicial
- Um novo workspace é criado com o seguinte comando
npx primo-cli init my-workspace
- Após a criação, os estados
workspace ready e server.yaml written são exibidos
- O texto de licença e preço é apresentado como MIT, open source e gratuito para sempre
1 comentários
Opiniões no Hacker News
Um editor de CMS com blocos de arrastar e soltar parece ótimo em demos, mas, depois de operar internamente um editor parecido, isso virou um inferno interminável de atualizações
Pedidos como “dá para alinhar o texto à direita e deixá-lo azul?” continuam aparecendo, e no fim cada bloco passa a acumular cada vez mais propriedades
Para quem realmente escreve o conteúdo, é difícil usar de forma eficaz, e o resultado em geral não fica satisfatório
Com mais treinamento, pode até melhorar, mas o compromisso entre liberdade e manutenção da identidade da marca continua existindo
No nosso caso, um CMS headless parece ser uma abordagem melhor. É melhor fornecer apenas o conteúdo e deixar alguns especialistas implementarem em código de acordo com o design, mas nem todo mundo tem essa folga, então esse tipo de CMS certamente também tem seu lugar
Há alguns meses, ao reformular o site de e-commerce de um cliente, criamos seções/blocos editáveis com o Maglev, e a experiência de edição em si foi boa
Mas, depois do lançamento, o cliente contratou uma pessoa de marketing com conhecimentos bem básicos de HTML/CSS, e foi difícil convencê-la de que, em vez de escrever HTML/CSS diretamente, ela deveria pedir a um desenvolvedor para criar as seções necessárias
Poderíamos incluir um editor para desenvolvedores, como no Primo, mas, pela minha longa experiência, não quero que clientes mexam diretamente no HTML/CSS do site
Também não quero uma relação do tipo “se quebrar, você paga”
De forma mais ampla, qualquer CMS tem o mesmo problema. Já ajudei uma empresa cujo site em Webflow foi quebrado: foi o caso típico em que, depois de um designer criar tudo, uma pessoa de marketing tentou “melhorar” a UI e quebrou tudo
Há um limite para o número de componentes que dá para criar
O ideal seria um CMS em que o cliente pudesse alterar o HTML facilmente sem código. Assim o site carrega rápido, tem boa otimização para busca e o desenvolvedor não precisa reinventar a roda
Foi por isso que criei o Versoly(https://versoly.com/). Eu me perguntava por que seria preciso chamar um desenvolvedor toda vez que alguém quisesse mudar a cor de fundo ou adicionar uma nova seção
Ainda assim, independentemente do CMS usado, o problema de editores de conteúdo quererem alinhar texto à direita e deixá-lo azul não continua existindo?
Ainda quase não há documentação oficial, mas, se houver interesse, seria bom se você desse uma olhada na primeira página e visse se vale a pena experimentar
Também gostaria de ouvir feedback geral ou aprendizados de experiências diretas
https://brick-cms.com/
GitHub:
https://github.com/primocms/primo
Discussões anteriores:
https://news.ycombinator.com/item?id=23820201
https://news.ycombinator.com/item?id=25301040
Show HN com texto, em uma conta que parece ser outra do autor original:
https://news.ycombinator.com/item?id=36801101
SSG parece significar gerador de site estático (Static Site Generator), mas acho que, ao sair um pouco de uma área específica, seria necessário tentar escrever de um jeito que o leitor consiga entender com facilidade
Mesmo trabalhando com desenvolvimento web, precisei pensar um pouco para decifrar essa sigla
Ainda assim, para usuários que ainda não sabem, escrever por extenso pode ser mais útil
Seria bom ter uma ferramenta assim para lidar com conteúdo dinâmico contínuo, como posts de blog ou reviews
As pessoas continuam muito presas ao WordPress, mas customização e temas são quase um pesadelo
Na época, era uma das quase únicas maneiras de criar um blog facilmente
O problema é que, no momento em que você sai do escopo padrão, de repente passa a precisar de conhecimento profundo da estrutura interna do WordPress
Há cerca de 3 anos, o HN colocou o CMS open source Primo na front page (https://news.ycombinator.com/item?id=23820201), e graças a isso acabei largando um emprego remoto confortável no meio da pandemia para me dedicar a ele em tempo integral
Depois disso, gastei todas as minhas economias, perdi o domínio primo.af para o Taliban e convenci minha esposa a virar desenvolvedora/designer para me ajudar
Mesmo assim, tenho orgulho do que construímos nesse período e, ao ver isso ajudar pessoas a aprender desenvolvimento web, publicar sites pessoais e gerenciar sites de clientes, fiquei ainda mais convencido da força e da simplicidade dessa abordagem
O Primo 2, que estou lançando hoje em beta público, oferece edição de conteúdo diretamente na página, page building e outros recursos
Comecei a criar o Primo porque estava cansado do trabalho de criar sites e da realidade de que usuários não técnicos têm dificuldade para gerenciá-los
Em projetos freelance, eu sofria com temas WordPress frágeis, navegação por dashboards e combinações de plugins; como desenvolvedor de agência, achava que CMSs monolíticos e metaframeworks/CMSs headless eram exagero para landing pages ou sites institucionais
Como instrutor de programação, vi alunos ficarem intimidados ao tentar usar a web e se deparar com CLI, APIs, gerenciadores de pacotes, bundlers, frameworks e metaframeworks
Não havia um caminho enxuto e acessível para criar, gerenciar, desenvolver e hospedar sites comuns, como blogs, landing pages e sites institucionais
O Primo é, por padrão, um CMS que facilita o gerenciamento de conteúdo, mas reúne page building, edição de código, geração de site estático e deploy/hospedagem no GitHub em uma única interface
Os blocos são escritos em Svelte, ou seja, HTML/CSS/JS, então são responsivos e têm estilos encapsulados
Por ser um site estático, também se obtêm as vantagens de custo, segurança, escalabilidade e velocidade do serverless
O Primo não é tanto para quem prefere controles de design WYSIWYG no estilo SquareWixFlow, mas para quem quer controle total do site com HTML/CSS/JavaScript e, ao mesmo tempo, oferecer a si mesmo e a amigos/clientes/colaboradores não técnicos uma experiência de edição de conteúdo muito simples
Ele mira pessoas frustradas com ferramentas no-code e plataformas proprietárias, mas que querem algo mais simples sem abrir mão do poder do código
Indo além, o Primo é uma tentativa de manter a web nas mãos das pessoas
Ao tornar a publicação na web mais acessível, espero aumentar a literacia tecnológica e dar às pessoas meios de expressão livre, para que não sejam empurradas com facilidade para caixas-pretas e jardins murados
Mas o sistema de gerenciamento de conteúdo era o problema. Eu esperava algo como um gerador de sites estáticos comum, em que você coloca arquivos Markdown em pastas e ele gera artigos ou posts de blog conforme os templates
Em certo momento, fiz um fork do repositório do Primo e implementei uma forma customizada de converter entradas do banco de dados em uma estrutura de arquivos/pastas, mas o caminho inverso parecia complicado, então segui outra direção e criei meu próprio gerador de site estático em Markdown inspirado neste guia: https://joshcollinsworth.com/blog/build-static-sveltekit-mar...
Meu caso de uso talvez não seja o público-alvo, mas acho que seria um produto excelente se o projeto fosse armazenado como uma estrutura dinâmica de arquivos/pastas, em vez de ser escrito em um banco de dados, e pudesse ser editado e versionado como um projeto SvelteKit comum
Em essência, ele se tornaria um framework de geração de sites estáticos baseado em Svelte com uma biblioteca de componentes e uma UI dedicada
O fórum também é bom, e algumas perguntas que eu tinha já estavam respondidas
Uso WordPress há muito tempo e recentemente tenho mexido com Svelte; isto chega bem perto do que eu estava procurando
Tenho muito respeito pelo esforço investido para construir algo assim
É um bom projeto, mas é um pouco decepcionante que, para fazer “self-hosting”, seja necessária uma conta no Supabase
Parece funcionar apenas em determinados serviços de hospedagem que conseguem se conectar ao Supabase, e incentiva a puxar o conteúdo das páginas do GitHub
Por isso, parece mais um CMS operado junto com provedores de serviço específicos do que um CMS que você possa realmente hospedar por conta própria
O objetivo era tornar o mais fácil possível para as pessoas colocarem seu próprio servidor no ar, e por isso acabou conectado a esses serviços
Ainda assim, estou trabalhando para separar o backend e permitir hospedagem realmente própria
O único serviço externo realmente necessário é o GitHub, e no futuro talvez sejam adicionados outros provedores, como o GitLab
É um bom projeto, mas, sinceramente, cheguei ao ponto de achar que menos JavaScript, ou uma abordagem sem JavaScript, é melhor tanto para desenvolvedores quanto para usuários
Estou migrando meu blog antigo para um novo blog gerado com Zola (https://www.getzola.org), e também estou refazendo em Zola meu site de portfólio recém-criado em React/Gatsby, porque a diferença de desempenho é enorme
Às vezes navego na web com JavaScript desativado, e se um site não funciona completamente nesse estado, ou nem sequer carrega, isso é uma grande desvantagem
O site antigo usava jQuery, o que já era um tanto irritante, e experimentar coisas como React foi um pesadelo
Internamente, ele usa o compilador do Svelte
É quase inacreditável que já faz mais de 10 anos desde que criei, em 2010, um gerador de sites chamado Stiqr
O site não está mais no ar, mas dá para ver vestígios dele em um vídeo do YouTube
https://www.youtube.com/watch?v=B-ff53t8TuU&t=224s
Na época, em 2010, o design responsivo começou a ganhar força e acabei encerrando o projeto, mas ainda acredito que a forma de criar sites no futuro próximo segue nessa direção
A combinação de arrastar e soltar/blocos com Svelte é muito bacana, mas para mim parece uma ferramenta no extremo errado do espectro
Isto é um construtor visual de sites com editor online para customizar blocos
O que eu quero é uma interface online que permita ao cliente adicionar ou alterar textos, ou fazer pequenos ajustes, em um site Svelte que eu criei offline com minhas próprias ferramentas
Seria bom se, ao criar o site seguindo um determinado padrão de interface, o Primo conseguisse lê-lo e o cliente pudesse modificá-lo por meio de uma interface visual
Alterações grandes voltariam para mim, e eu poderia manter a velocidade e a liberdade do meu fluxo de trabalho offline
Dá para dizer que eu preciso de um CMS headless, mas todos os que experimentei eram excessivamente complexos, e só a configuração e a manutenção já davam uma enorme dor de cabeça
A menos que você crie campos específicos, aspectos visuais como, por exemplo, deixar uma imagem redonda ou quadrada não podem ser editados
Se o problema é não poder usar um IDE local, hoje é possível empacotar componentes Svelte como JavaScript vanilla, importá-los para blocos do Primo e passar dados por meio de campos
Porém, até estabilizar, seria melhor esperar algumas semanas antes de usar em produção
O fluxo que você descreveu é, na prática, o mesmo que uso em projetos para clientes. Escrevo todo o código, normalmente reutilizo blocos de outros projetos e entrego um site que o cliente consegue editar desde o primeiro dia com treinamento mínimo
Fico curioso se você quer dizer que “customizar blocos” não inclui alterar textos, ou se quer dizer que as ações possíveis não são suficientemente restritas para entregar ao cliente
Parece permitir inserir seções gerenciadas por arrastar e soltar dentro do markup normal da página e dá suporte à maioria dos frameworks, incluindo Svelte
A configuração pode ser feita por FTP