Criando um site sem frameworks e várias bibliotecas

• A Koding Kitty aplicou uma stack centrada em HTML estático ao site de uma pequena empresa, operando as páginas necessárias e um blog sem um CMS grande nem frameworks
• Os critérios de escolha foram velocidade, conveniência no desenvolvimento, hospedagem barata e baixa complexidade; WordPress, no-code, frameworks e Jamstack exigiam configuração e aprendizado demais em relação aos requisitos
• O conteúdo é escrito diretamente em HTML, em vez de Markdown ou editor visual, facilitando lidar com posts que misturam texto e widgets em HTML/CSS/JS
• Estruturas repetidas e blocos comuns são tratados com templates Jinja, e um script Python de 45 linhas encadeia a detecção de mudanças, renderização de HTML e chamada da CLI do Tailwind CSS
• Por ser um site estático, hospedagem barata foi suficiente; a hospedagem web da Hetzner começa em 2 EUR e aguentou até um pico de tráfego vindo da primeira página do Hacker News

---

Por que escolher uma stack simples

• A stack tecnológica do site da Koding Kitty foi composta de forma intencionalmente simples, ajustada aos requisitos reais, em vez de seguir a tendência recente de desenvolvimento web leve
• O objetivo era uma configuração com pouco atrito para desenvolvedores, considerando que uma solução simples poderia ser melhor para os clientes do que uma combinação complexa de frameworks e bibliotecas
• Um design distinto, mas sem exageros, poderia ser criado de várias formas, mas a configuração atual foi uma escolha adequada ao escopo necessário

Requisitos e critérios iniciais

• Desde o início, decidiu-se criar um site estático
• As funcionalidades necessárias eram basicamente uma página inicial, uma vitrine e um blog; não havia muito além disso
• Os critérios eram quatro
  • Site rápido
  • Desenvolvimento rápido
  • Hospedagem barata
  • Complexidade mínima

Opções avaliadas, mas descartadas

• WordPress e CMS semelhantes

  • Reconhece-se que o WordPress teve um grande papel na internet
  • Mas era exagerado para requisitos modestos
  • Não havia necessidade de armazenar conteúdo em banco de dados, nem de plugins ou editor visual

• Ferramentas no-code

  • Parecia estranho para alguém que programa para a web usar ferramentas no-code
  • Havia o desejo de possuir o conteúdo diretamente e controlar o site como quisesse
  • A criação por código parecia mais rápida do que com um editor WYSIWYG no-code
  • A necessidade de aprendizado inicial e contínuo também era um peso

• Frameworks

  • Havia experiência com frameworks, mas não se queria trazer toda a configuração junto
  • Componentes como banco de dados, configuração, bibliotecas e recursos administrativos poderiam se multiplicar demais
  • Mesmo sendo possível personalizar tudo, a conclusão foi que o resultado poderia acabar parecido com o WordPress

• Jamstack e geradores de sites estáticos

  • Geradores de sites estáticos pareciam uma opção bem alinhada aos requisitos
  • É possível escolher uma linguagem, programar e criar rapidamente um site estático com um botão ou script
  • Porém, exigiam configuração inicial e aprendizado inicial e contínuo
  • Embora a conveniência de escrever o blog em Markdown tenha sido reconhecida, no geral foi escolhida uma solução mais simples

Composição da KittyStack

• A configuração da Koding Kitty foi organizada em torno dos quatro requisitos

• Site rápido

  • Sites estáticos funcionam rapidamente

• Desenvolvimento rápido

  • O conteúdo é escrito em HTML, não em Markdown nem em um editor avançado
  • Como os posts da Koding Kitty misturam texto e widgets em HTML/CSS/JS, escrever HTML diretamente era adequado

• Hospedagem barata

  • O custo de hospedagem de sites estáticos varia conforme o provedor e os recursos adicionais necessários
  • Como sites estáticos não exigem uma grande configuração de hardware, é possível escolher uma configuração mínima
  • A hospedagem web da Hetzner começa em 2 EUR
  • O site da Koding Kitty aguenta até picos de tráfego do nível de chegar à primeira página do Hacker News

• Complexidade mínima

  • Algumas páginas e posts têm padrões repetidos
  • Seria possível copiar e colar, mas com o tempo isso poderia ficar difícil de controlar
  • Eram necessários loops e a capacidade de incluir blocos de código como cabeçalhos e rodapés

Jinja e fluxo de build

• Estruturas repetidas e inclusão de arquivos comuns são tratadas com templates Jinja
• O Jinja oferece loops, inclusão de arquivos como barra de navegação e rodapé, além de outros recursos de template
• A equipe já tinha experiência anterior com frameworks baseados em Jinja, então não precisou aprender um sistema novo

Cadeia de ferramentas simples

• As páginas estáticas finais são geradas com um script Python de 45 linhas
  • A contagem inclui comentários e linhas em branco
• O fluxo de build é o seguinte
  • O desenvolvedor modifica index.src.html
  • Watchdog.py detecta a alteração no arquivo
  • O template Jinja é renderizado como index.html
  • A CLI do Tailwind CSS é chamada para gerar styles.min.css
• Durante o desenvolvimento, o Live Server serve os arquivos e recarrega quando há mudanças
• Na implantação, os arquivos são enviados manualmente por FTP

Vantagens de um desenvolvimento web menos complexo

• O desenvolvimento web pode ser mantido simples sem sacrificar muita coisa
• Limitar as opções a algumas alternativas pode, na verdade, dar uma sensação maior de liberdade
• Para muitos clientes, uma solução mais rápida, mais simples e mais barata pode ser útil
• É preciso observar a web como um todo e avaliar se o mesmo resultado pode ser alcançado com uma stack tecnológica menos complexa

[GN⁺]

Comentários do Hacker News

• Também acabei chegando à mesma abordagem para meu portfólio de fotografia. Como migrei do desenvolvimento para a fotografia, a vantagem é não depender de Squarespace como outros fotógrafos
  Depois de testar várias opções baseadas em servidor feitas com Ghost, Statamic e Phoenix/Vapor, além de geradores de site estático comuns, no fim passei a escrever tudo em HTML puro, sem templates, e enviar para um servidor da Hetzner com rsync
  É um pouco incômodo não ter templates para UI compartilhada, como a navegação, mas até agora nunca tive uma mudança que levasse mais de alguns minutos com regex, e uma vez o git me salvou quando uma regex gulosa apagou conteúdo no começo
  Gerar variações por tamanho e formato de imagem é trabalhoso, mas isso me força a experimentar novos layouts em vez de depender de layouts engessados como os do Ghost. Além disso, a qualidade parecia ligeiramente melhor ao exportar imagens para a web no editor RAW Capture One do que com as bibliotecas ou ferramentas CLI usadas pela maioria dos geradores de site estático
  É mais lento, mas vejo isso como algo mais próximo de montar um livro de fotografia. No começo dá mais trabalho, mas depois que termina, terminou, e não preciso ficar migrando entre vários CMS e quebrando tudo pelos próximos 20 anos

  • Navegação básica de anterior/próximo e menus, cabeçalhos e rodapés consistentes podem ser resolvidos com server-side includes
  • Meu site pessoal de fotografia usa Svelte + TailwindCSS, a API do Flickr e Netlify
    Na prática, é uma estrutura de alguns arquivos HTML com o poder extra de templates; as fotos vêm de um álbum dedicado a esse site via API do Flickr, e o Netlify faz deploy automático só com git push
    O custo total, incluindo hospedagem, é 0 dólar, e dá para gerenciar as fotos pelo celular com o app do Flickr. Também gosto do fato de que, com o Netlify, não preciso mexer em um servidor de verdade
  • Fiquei curioso sobre como foi a experiência usando Vapor
    O método que usei recentemente também pode ajudar (https://news.ycombinator.com/item?id=36592641). Foi fácil usar Google Sheet como fonte de dados, e provavelmente teria sido igual trocando para um sistema de arquivos com fotos
  • Estou justamente pensando em sair do Smugmug e tentar algo assim; você poderia compartilhar seu portfólio ou o código?

• Isso parece menos “simples (simple)” e mais apenas simplista (simplistic). Dá para fazer um site relativamente simples não fazendo quase nada e cortando os cantos
  Mesmo olhando só para o modo escuro, praticamente a única funcionalidade não trivial visível nesta página, ele é implementado com JS carregado com atraso, então há um inevitável flash branco a cada carregamento de página. Para fazer direito, teria que ser com classe no body via CSS, e uma solução que não funciona não tem valor, seja simples ou complexa
  Além disso, trazer um interpretador customizado inteiro de “hyperscript” como https://hyperscript.org/ para três linhas de JS sobre localStorage e configuração de modo escuro vai contra a ideia de que “simplicidade é a sofisticação máxima”. Carregar uma biblioteca de 96 KB sem cache só para isso é estranho, e fico me perguntando se é por isso que o HTML não valida
  Por fim, um toggle binário é uma implementação ruim de modo escuro porque ignora as configurações do sistema/navegador. Mesmo se o modo escuro estiver ativado no sistema do smartphone, o site continua em modo claro até o usuário ligar manualmente, e também não respeita configurações do sistema que mudam conforme horário ou luz ambiente. O localStorage pode expirar e os dispositivos mudam, então o usuário precisa configurar repetidamente, e é bem possível que ele não concorde com essa implementação “simples” de que o desenvolvedor fala

  • Se o objetivo é ter um site o mais simples possível, então nem deveria existir modo escuro. Já havia sites simples e fáceis de ler nos anos 90, e antes da moda do modo escuro o modo claro sozinho já bastava
    Se você considerar configurações de sistema/navegador, troca por fuso horário, luz ambiente e afins, a complexidade cresce de um jeito que entra em conflito com a filosofia de um site simples. Melhor simplesmente remover o modo escuro; o HN também é sempre claro e isso não impede muito a leitura à noite
  • Concordo que a abordagem com JS carregado tardiamente está errada, mas a abordagem com media query também é complicada
    Em geral, você quer respeitar prefers-color-scheme e ao mesmo tempo oferecer um toggle, e se o usuário já escolheu manualmente antes no site, quer priorizar essa escolha. Aí você ainda precisa de JS e localStorage
    Minha forma preferida é usar estilo inline com body {visibility: hidden; opacity: 0;}. Dá para manter a página anterior visível e, no momento de DOMContentLoaded, verificar prefers-color-scheme e localStorage, definir corretamente a classe do body e só então renderizar a página
  • Enquanto lia, pensei “que análise excelente”, e entendi ao ver quem era o autor. Para falar ao OP, este é o autor de https://gwern.net, e esse site influenciou muito o design de vários blogs técnicos e sites pessoais, com muitas ideias originais e excelentes
    Meu site respeita o tema claro/escuro com CSS e não tem toggle manual. Tenho como meta pessoal um site em HTML/CSS puro, sem JS, e acho que as configurações de claro/escuro devem respeitar a preferência do usuário. Se um toggle for necessário, ele deveria ficar não dentro do site, mas nas configurações da barra de ferramentas do navegador
    Se /u/gwern estiver lendo, meu site https://daveon.design/ foi influenciado pelo design do gwern e pelo Tufte.css. Também há mistura de publicações antigas, manuscritos e gosto pessoal, mas o gwern foi o exemplo central que primeiro me inspirou sobre como um site pessoal moderno e limpo poderia parecer e o que poderia conter
  • No Firefox, Chrome e Safari no Mac, e no Firefox e Chrome no Android, não vejo o flash branco. No carregamento inicial, no recarregamento e na troca entre escuro/claro, tudo parece simplesmente funcionar bem
  • É um ponto correto. Infelizmente, esse tipo de mentalidade que parece simples, mas está quebrada, é tão disseminado quanto as abordagens quebradas e inchadas

• Falando nisso, hoje em dia SvelteKit + Skeleton é realmente impressionante em termos de velocidade para criar um protótipo utilizável
  Mesmo sem conhecer Svelte direito, se você entender o roteamento baseado em arquivos, o resto é praticamente HTML até você precisar de mais; Tailwind já vem por padrão, e os temas em geral ficam bem próximos do vanilla
  Nos últimos meses testei várias coisas, como Astro, Lit, Next.js, templates nativos do Go, pug e Eleventy, e até agora essa combinação é a minha favorita em quase todos os aspectos

  • SvelteKit é excelente, mas é difícil concordar com Skeleton. No começo ele parece produtivo e seguro, mas tem muitas armadilhas, e quando aparece algo de que você não gosta, fica difícil customizar
    Basta olhar o próprio site do Skeleton https://www.skeleton.dev/docs/get-started: mesmo apertando Page Down ele não rola, ao passar o mouse sobre a barra de navegação também não rola, e ao imprimir ele corta tudo e mostra só a parte visível na tela. Eu apontei esse problema, mas ainda não é alta prioridade, e mesmo assim muitos sites usam esse padrão de componentes
    Parece que o Skeleton considera que inverter as cores do tema escuro já produz um tema claro aceitável, mas na prática não é assim. DaisyUI é mais maduro, mais performático, mais usado e trata acessibilidade com seriedade. Também impressiona conseguir isso só com animações em CSS, sem JS, resolvendo as partes difíceis de HTML/CSS e deixando você escrever diretamente a parte fácil de Svelte. A dependência de Svelte também é menor, então é fácil levar o HTML do DaisyUI para outros frameworks
  • Concordo. É um framework, mas gera com facilidade um site estático que continua funcionando bem mesmo com o JS desligado; dá para usar sem conhecer Svelte e, se precisar, também dá para usar Svelte
    Tailwind funciona de imediato, e fazer deploy em lugares como a Netlify também é muito simples. Hoje, eu diria que é o melhor construtor de sites estáticos e muito mais simples do que a abordagem explicada no texto
  • Como alguém que gosta de minimalismo, usei Astro e SvelteKit, e o SvelteKit parece uma camada bem pequena sobre o Svelte, que por si só já é uma biblioteca de componentes muito pequena
    Com +page.ts e a configuração adequada, dá para fazer também um site estático, além de poder evoluir para um app multipágina ou de página única
  • Não vejo muitos exemplos no estilo “se você digitar isto, a página final vai sair assim”. Seria bom ter exemplos que desse para simplesmente conferir antes de instalar e seguir um processo
  • Boa recomendação. Também queria ouvir mais experiências com outros frameworks web e fiquei curioso se você já tentou Flutter

• Meu Deus, fazer um site com HTML e CSS parece uma loucura
  Brincadeiras à parte, fora os templates eu uso praticamente a mesma stack. Se você não é desenvolvedor web, é difícil entender a necessidade de um framework CSS, e fazer você mesmo é muito mais fácil. Também testei geradores de site como Hugo, mas não economizei tempo nenhum
  Alguns meses atrás tentei melhorar minhas habilidades em CSS recriando sites de algumas empresas, e visualmente todos puderam ser reproduzidos só com HTML e CSS. Só que os sites reais dessas empresas nem apareciam quando o JS era desligado
  Estamos empilhando frameworks sobre frameworks, novas linguagens e novas ferramentas, e a maioria só aumenta a complexidade e o trabalho corrido da próxima geração. Os 5% de sites que realmente precisam disso são exceção
  Também achei interessante que era um site vendendo um serviço real e fiquei curioso sobre a faixa de preço

  • Fazer o design e manter isso de forma consistente parece difícil demais. Por isso gosto de ter CSS predefinido; sem isso, o resultado parece bagunçado
  • Concordo em grande parte, mas tive bastante sucesso usando Astro

• Acho que a forma mais minimalista e produtiva é simplesmente usar PHP, porque a linguagem foi criada originalmente para esse tipo de uso
  Para um site simples, não precisa de composer nem de lógica de roteamento; basta separar arquivos de header/footer/navigation e fazer include deles em cada página

  • Mesmo sem biblioteca, em umas 100 linhas dá para fazer um roteador e um layout. O roteador só verifica se o arquivo existe, e o layout faz include de header.php, pagename.php e footer.php. Para sites simples eu faço assim, e é muito fácil e rápido
  • Mesmo que não seja PHP, qualquer linguagem de script server-side serve. O essencial é ter a capacidade de nomear dados e blocos de código, salvá-los e carregá-los, para que o site possa ser refatorado
    Se o HTML pudesse inserir HTML externo como CSS ou JS, até isso seria desnecessário na maior parte dos casos. Seria ótimo se simplesmente deixassem a gente usar isso livremente
  • É difícil superar a simplicidade de PHP + HTML se o objetivo é simplicidade. Para algo maior do que um script de propósito único eu normalmente não iria tão longe e pelo menos usaria uma biblioteca de templates separada, mas é bom ter essa possibilidade
  • Concordo com a ideia, mas com algo entre 5 e 20 horas dá para montar um gerador de sites eficaz e sob medida baseado em Eleventy e publicar de graça na Netlify
    Você muda alguma coisa, faz git commit/push, e em menos de 30 segundos as alterações se refletem no mundo inteiro. É muito bom e não precisa de hospedagem de servidor separada
  • Existem muitos frameworks simples, mas se você for adicionando mais algumas peças, logo volta ao inchaço de sempre

• Isso me faz lembrar da frase “tão simples quanto possível, mas não mais simples”. Provavelmente não é do Albert Einstein
  HTML + CSS puros, com o CSS dentro de cada tag HTML ou da própria página, funciona bem para começar. Quando a página vira duas, você acaba extraindo o CSS para um arquivo separado
  Mas quando você começa a criar um site com várias páginas no mesmo formato, passa a precisar de um sistema de templates com include e de um gerador de páginas estáticas
  Se as páginas forem orientadas por dados, você precisa de um gerador de sites programável que consuma dados e produza páginas; se os dados forem “em tempo real”, então é preciso gerar páginas por visualização, o que já te leva pelo menos ao território do PHP, ou até ao território dos frameworks web modernos com servidor em execução
  Recentemente fiz um site pro bono ligado a um hobby. É um site de divulgação de dança e de eventos, e a proprietária é uma professora de dança sem muito conhecimento técnico. Gereis um site estático no plano gratuito da Netlify com o Eleventy(https://www.11ty.dev/) e adicionei código de build customizado para buscar dados de uma Google Sheet, para que a professora pudesse definir os próximos eventos
  Levei umas boas horas para fazer, mas agora está rodando bem sem custo de operação/manutenção. Descobri que existe um ponto ideal poderoso entre uma configuração totalmente mínima e algo no nível de Rails/Phoenix/Django

  • No fim, o OP também usa duas bibliotecas: templates Jinja e estilização com Tailwind. É um meio-termo razoável entre HTML/CSS puro e Django/Phoenix/Rails + Angular/React/Vue
  • Normalmente eu refatoro quando algo aparece duas vezes, mas também já ouvi dizer que, com DRY, adiar até a terceira vez costuma ter mais chance de compensar em relação ao esforço
    Dito isso, um site quase certamente terá mais de 3 páginas, então isso pode ser um pouco diferente da probabilidade de um bloco de código genérico ser usado 3 vezes ou mais
  • Fiquei curioso para saber se isso foi publicado como open source ou se você encontrou algum projeto parecido
    Também queria saber se a estrutura chama a Google Sheets API no lado do cliente para preencher os dados e, nesse caso, se existe uma camada de cache ou se cada cliente recebe uma cópia nova toda vez

• Essa discussão sobre frameworks e complexidade já cansou de verdade
  Se o cliente exige um CMS customizado com fluxo de publicação em várias etapas, internacionalização e acessibilidade para compliance, você precisa de ferramentas poderosas para entregar isso no tempo que o cliente espera. No mundo enterprise há muitos clientes assim, por isso existe tanta demanda por esse tipo de ferramenta. Quem só trabalhou com B2C pode se surpreender, mas essa é a parte submersa do iceberg da indústria de tecnologia
  É verdade que um blog estático não precisa de uma configuração complexa de Next.js nem de uma toolchain Vite. Mas quem discute essas ferramentas a sério não está falando de fazer um site de blog simples. O exemplo reduzido do tutorial pode até ser um blog, mas o problema real é outro
  Então eu queria que esse ódio a frameworks diminuísse um pouco. Se alguém tem uma boa ideia para fazer sites de forma simples, pode publicar um tutorial, e, se for atraente, as pessoas vão usar essa abordagem nos contextos apropriados. Só queria evitar esse hábito de argumentar contra um inimigo vago tipo “toolchains apimentadas e frameworks da moda”

  • Muita gente que participa dessa conversa nunca trabalhou diretamente com problemas em que esse tipo de ferramenta é útil. Pode até ser engenheiro, mas sem mexer com frontend não passa do básico; ou pode ser estudante de CS e achar que entende tudo de desenvolvimento frontend porque fez um blog pessoal com Jekyll
    Ou então pode achar que sabe tudo porque passou anos fazendo app interno de trabalho com duas dezenas de usuários e sem exigências de UX. Esse tipo de julgamento com pouca informação acaba empobrecendo a discussão
  • Se você faz algo complexo sem usar framework, no fim acaba criando outro framework por conta própria
    Só que, dessa vez, quem herdar esse código não vai receber atualizações e nem vai conseguir ajuda no Stack Overflow com facilidade
  • Concordo. Digo isso até sendo alguém que não gosta da complexidade que os frameworks introduzem
    Não entendo por que as pessoas acham que não se pode usar ferramentas diferentes para trabalhos diferentes. Há momentos em que framework não é necessário, mas, pela minha experiência, isso é raro a menos que você esteja fazendo algo extremamente simples e que quase não vai mudar
    Num cenário com equipe e cliente, é difícil imaginar como um site de “ferramentas simples” funcionaria na prática; não estou criticando, realmente só não consigo visualizar bem

• Para mim, isso aí já soa complexo demais
  Eu escrevo os textos em Gemtext, ou seja, markdown para Gemini, e fiz um script em Python que converte isso para HTML e gera páginas de índice
  O CSS tem só 42 linhas, então coloquei em cada página, e até calculei que o custo de adicionar 42 linhas por arquivo nunca seria maior que o de uma segunda requisição HTTP
  Foi muito mais simples do que eu esperava, sem bibliotecas Python nem templates. A parte mais difícil foi gerar os emails para enviar à mailing list. Passei meses analisando vários frameworks e geradores de site estático, e semanas procurando um CSS decente
  Pelo histórico do git, levei 2 semanas hackeando tudo até concluir, incluindo importar 18 anos de histórico do WordPress. Como é Python puro, não precisei aprender nada novo, e, se houver bug, posso corrigir ou mudar facilmente. Afinal, o código é meu
  Os cientistas da computação esqueceram completamente que dá para simplesmente codificar uma solução ad hoc em vez de tentar reutilizar tudo. O tempo gasto para aprender e adaptar é maior do que o tempo de fazer você mesmo
  Código: https://git.sr.ht/~lioploum/ploum.net
  Site: https://ploum.net

  • Email? Script em Python? Git? Uma bela máquina de Rube Goldberg
    Meu site é servido por um processador 6502 esculpido em madeira balsa em 2003 e colado com epóxi num cabo Ethernet. Quando quero mudar algo, aqueço a EPROM com um secador de cabelo para inverter os bits desejados. Sem templates, sem código, sem bloat
  • Excelente blog. Abri só para ver o design e acabei lendo 4 textos seguidos
    A sensação de revisitar a história da tecnologia enquanto descia a página trouxe uma nostalgia enorme

• A menos que eu tenha entendido errado, isso não parece muito diferente de um gerador de site estático comum. Parece a diferença entre gerar arquivos HTML com templates Jinja baseados em Python e o Jekyll, que gera arquivos HTML/Markdown com templates Liquid baseados em Ruby

  • Em vez de usar um framework pronto, ele fez o próprio. E tudo bem, porque criar coisas é divertido
  • Eu pensei a mesma coisa. Se o objetivo era simplicidade, parece uma escolha estranha criar um gerador personalizado em vez de usar um gerador de site estático já existente
    Um site em PHP com include ou um gerador de site estático pronto faria muito mais sentido

• Não entendo. No fim, ele não queria um gerador de site estático, então escreveu um gerador de site estático por conta própria