Kage - ferramenta para remover JavaScript de sites e arquivá-los offline

 (github.com/tamnd)
2 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Renderiza páginas com Chrome headless, captura um snapshot do DOM final que uma pessoa veria, depois remove todo o JavaScript e baixa CSS, imagens e fontes para caminhos locais, criando uma cópia estática que funciona sem código
  • Resolve o problema de páginas salvas com "Save As" que, com o tempo, quebram e viram tela em branco, spinner travado ou tentativas de conexão com servidores de analytics que já sumiram
    • Fornece arquivos .html que abrem direto do disco, sem rastreamento, chamadas de rede ou comportamentos inesperados
  • Usa rastreamento em largura (breadth-first crawling), lê robots.txt, define pontos de partida a partir de sitemap.xml e permanece no host seed
    • A propriedade idempotent garante que a mesma página seja obtida apenas uma vez, independentemente de http/https ou da presença de trailing slash
    • Ao pressionar Ctrl-C, salva a posição e continua na próxima execução; com --refresh, renderiza novamente, e com --force, recomeça do zero
  • Oferece flags de controle do escopo e comportamento do crawler como --max-pages, --max-depth, --scope-prefix, --subdomains, --scroll e --workers
  • Com kage pack, compacta a cópia em um único arquivo, com opção entre um arquivo ZIM ou um executável autônomo que funciona como o próprio site
    • O ZIM é compatível com o ecossistema Kiwix e pode ser aberto no kiwix-serve ou nos apps Kiwix para desktop e mobile
    • O binário autônomo não exige que o destinatário instale nada, e --base permite gerar viewers para outros sistemas operacionais (cerca de 13 MiB + tamanho do site)
  • Com empacotamento determinístico, a mesma cópia sempre gera arquivos byte-identical, e o UUID do arquivo é derivado do conteúdo, sendo seguro para checksum e cache
  • Quando compilado com a tag webview, usa o WebView do sistema operacional (WKWebView, WebView2, WebKitGTK) para abrir em uma janela própria, e não em uma aba do navegador
  • Pipeline de processamento: URL seed → renderização com Chrome headless → snapshot do DOM final → remoção de JS → localização dos ativos → gravação em disco
  • Licença MIT

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • Fiquei curioso para ver como o GIF de demonstração do README foi gerado: https://github.com/tamnd/kage/blob/01e75b87ecc893bbba7943c63...
    Acabou que ele usa https://github.com/tamnd/ascii-gif, outro projeto do mesmo autor
    O script usado na demo está em https://github.com/tamnd/kage/blob/01e75b87ecc893bbba7943c63... e até inclui, em comentários, como executá-lo: ascii-gif render docs/demo/kage.tape -o docs/static/demo.gif
    Parece um wrapper bem opinativo em torno do https://github.com/charmbracelet/vhs

    • Já ouviu a palavra de asciinema, salvadora do terminal: https://asciinema.org/
    • Eu também tenho vários binários pessoais assim no meu $HOME/bin/. Coisas como delete-all-npm, clean-rust-cache, download-youtube-playlist e get-markdown, e é bom não precisar decorar comandos
      Às vezes, agentes de código também conseguem descobrir sozinhos como chamar essas ferramentas
    • Também dá para fazer isso com SVG animado, e como são só keyframes de texto, fica muito menor que GIF: https://github.com/vytskalt/pseudoc/blob/main/assets/factori...
    • Só como referência, em outras plataformas como Windows/macOS, o LiceCAP é uma ótima ferramenta para gravar a tela em pequenos GIFs. Foi criado pelo autor do Winamp e do Reaper DAW: https://www.cockos.com/licecap/
    • VHS é excelente quando você quer transformar a geração de vídeos de linha de comando em script

  • Eu conseguiria me ver usando isso para deixar uma wiki da empresa facilmente acessível offline. Por exemplo, pode haver documentação útil na wiki para usar em campo, onde o sinal do celular não pega
    Poder empacotar o site inteiro em um único binário é legal, mas eu gostaria especialmente de uma versão que não exigisse um processo de servidor separado
    Parece que também daria para fazer algo como um shim de entrada em HTML único com um pouco de JavaScript para navegar por um arquivo do conteúdo do site, de preferência embutido

    • Postar isso no Hacker News foi exatamente o lugar certo. Vou considerar implementar essa ideia
      Já tenho na cabeça um script/programa que converte HTML em Markdown, então talvez na prática eu pudesse salvar tudo como uma pasta de arquivos Markdown em disco e depois commitar em um repositório Git

  • Isso é excelente. Eu queria pegar o protótipo de alguém feito em algo como Lovable e baixá-lo como uma cópia offline, para fazer controle de versão e compartilhamento em um formato mais fácil
    Anotamos a abordagem que usamos aqui: https://productnow.ai/blogs/extracting-html-from-ai-prototyp...
    Agora vou olhar isso e ver se consigo trocar algumas partes. Gosto da ideia de um espelho offline, e ela simplifica bastante os casos de uso relacionados à colaboração

  • Está escrito kage serve $HOME/data/kage/paulgraham.com, mas se o resultado é estático, não entendo por que um servidor é necessário. Não daria para gerar algo que simplesmente abra no navegador?
    Se fosse possível algo como $ firefox $HOME/data/kage/paulgraham.com, o resultado poderia ser usado até em uma máquina sem o kage instalado

    • Talvez dê para usar python -m http.server no lugar. Ainda não testei, mas parece que funcionaria
      Na prática, o Kage tem duas partes. Uma é o crawler que, depois da renderização no Chrome/Chromium, captura o DOM, rastreia as páginas e as converte em HTML limpo; a outra é o componente de pack/serve que empacota o resultado em um arquivo ZIM para o Kiwix ou em um executável
    • Normalmente, carregar páginas desse jeito faz com que o JavaScript seja bloqueado
    • Fazendo assim, você provavelmente vai esbarrar em muitos problemas de CORS

  • Acho que o SingleFile [0] é uma versão muito mais robusta disso
    Ele também remove todo o JavaScript, mas empacota tudo em um único arquivo HTML fácil de compartilhar. Recursos binários como fontes web ou imagens entram como strings em base64
    Também oferece uma CLI baseada em Puppeteer [1]
    [0]: https://github.com/gildas-lormeau/singlefile
    [1]: https://github.com/gildas-lormeau/single-file-cli

    • Este repositório parece salvar apenas uma única página web
      O que está sendo implementado aqui é o espelhamento de um site inteiro, incluindo subpáginas, então dá para navegar por tudo offline. Por exemplo, todos os ensaios do paulgraham.com
    • Gosto muito do SingleFile. A extensão do Firefox funciona muito bem para salvar páginas de forma limpa
      Ainda assim, se o Kage conseguir combinar a qualidade de reprodução do SingleFile com uma abordagem de rastreamento no estilo do HTTrack, parece promissor. Aplicações de página única são meio complicadas de arquivar, então fico curioso para saber o quão bem o Kage vai lidar com isso
    • Obrigado pelo link. Vou tentar implementar essa funcionalidade de HTML único. Parece algo bom de ter
    • Qual é a diferença entre isso e fazer File -> Save as em qualquer navegador no computador?
    • Também pensei nisso no começo e acho uma solução muito elegante. Não é desnecessariamente complicada

  • Tentei clonar um site HTTP, ou seja, não HTTPS, mas recebi navigation failed: net::ERR_NAME_NOT_RESOLVED. Aconteceu a mesma coisa mesmo especificando o protocolo com http://

  • Tenho usado httrack(https://www.httrack.com) para baixar wikis para ler no avião. Não é perfeito, mas foi melhor do que outras coisas que encontrei antes
    Vou experimentar isso também, e ficaria muito feliz se o resultado fosse bom

    • Que nostalgia. Uns 20 anos atrás, quando a internet ainda era discada e cara, eu ia a lan houses, baixava sites e mangás com HTTrack, copiava tudo para um pendrive de 128 MB, que na época parecia enorme, e levava para casa para ler offline
    • No caso de wikis especificamente, existe algum motivo para não usar Kiwix? Fica mais complicado quando não é um lançamento “oficial”, mas existem serviços que geram arquivos ZIM. O aplicativo leitor para desktop foi bem bom na minha experiência
      https://wiki.openzim.org/wiki/Build_your_ZIM_file
      EDIT: https://get.kiwix.org/en/solutions/applications/kiwix-reader...
    • https://github.com/archiveteam/grab-site ou o browsertrix podem ser mais fáceis de usar para algumas pessoas. É uma ferramenta que foi usada para salvar bastante material do data.gov antes de sair do ar

  • Ao longo dos anos, juntei um bom número de arquivos de sites antigos. O interessante é que despejos de HTML feios acabaram sendo mais úteis do que arquivos “perfeitos”
    Esse é um dos motivos pelos quais fui passando a gostar mais de RSS com o tempo. Muitas vezes, um feed de uns 10 anos atrás é hoje mais fácil de usar do que um site em formato de aplicação cuidadosamente preservado

    • Estou trabalhando em um projeto para gerar e arquivar feeds RSS. Ele preserva o histórico completo desde o momento em que o crawler começou
      Pretendo abrir o código em breve, depois de organizar um pouco as coisas

  • Isso parece ter potencial para gerar uma carga bem grande no site. Existe alguma configuração para controlar a velocidade da cópia ou evitar imagens/vídeos?
    Também queria saber se há alguma forma de baixar apenas parte do site

    • Você pode abrir uma nova issue para isso? Vou cuidar disso depois. Aqui já é 1 da manhã no meu horário, mas fico feliz que alguém tenha se interessado
    • É só fingir que é um crawler de IA e o problema está resolvido

  • Projeto bem bacana, gostei da ideia
    Numa leitura rápida, vi que ele executa o Chrome com --no-sandbox; existe algum motivo para isso? Em termos de segurança, provavelmente não é uma boa ideia. Se não houver motivo, eu recomendaria deixar a sandbox ativada
    De qualquer forma, belo trabalho

    • --no-sandbox é necessário no Docker. Talvez a suposição tenha sido que a maioria vai executar no Docker?