3
benedetleandro
2 min de leitura ·

Pitch: Fenestra: dois cliques num dist/index.html e ele abre em localhost

Eu criei o Fenestra porque vivia abrindo um terminal só para servir um build estático.

Builds modernos usam módulos ES. Em file:// o navegador bloqueia módulos por
CORS, caminhos absolutos apontam para a raiz do disco e service workers não
existem. A solução comum é abrir um terminal e rodar um servidor estático.
O Fenestra elimina esse passo: ele é o servidor estático, associado ao duplo clique.

Dê dois cliques num index.html (ou arraste a pasta sobre o executável) e o
Fenestra serve aquela pasta em 127.0.0.1, numa porta estável, e abre uma aba
normal no seu navegador. Sem Electron, sem Node, sem extensão, sem janela de
navegador própria.

O que ele faz:

  • Windows: um .exe de ~120 KB, só .NET Framework, sem instalador.
  • Linux/macOS: um único binário Go estático; Homebrew para o CLI do macOS.
  • Porta estável por pasta: localStorage, cookies e service worker sobrevivem.
  • Fallback de SPA para rotas sem extensão.
  • Confinamento de caminhos: caminhos pai, truques de unidade e arquivos ocultos
    são rejeitados.
  • Seletor de navegador: Edge, Chrome, Firefox, Brave, Vivaldi, Opera, Chromium
    e Safari.
  • Manual offline embutido no executável, em sete idiomas.
  • Sem cookies, sem analytics, sem telemetria.
  • Um version.json estático é checado uma vez por semana; se houver
    atualização, abre uma aba dispensável por versão.

Status: 1.1.0. Está funcional, mas não vou fingir que está pronto.
Limitações honestas:

  • Os binários não têm assinatura de código; SmartScreen/Gatekeeper pedem
    confirmação uma vez.
  • O macOS não tem app notarizado; o kit de montagem compila um localmente.
  • Serve apenas arquivos estáticos: sem backend, sem proxy de API, sem TLS/auth.
  • Algumas traduções são comunitárias e ainda não foram revisadas por nativos.
  • Ainda há bugs, que vou corrigindo conforme aparecem.

Links:

Feedback que eu gostaria de receber:

  1. O fluxo de "tornar padrão" no Windows está claro?
  2. O kit de montagem do macOS funcionou para você?
  3. O que quebrou ou confundiu nos primeiros cinco minutos?

Se for útil para pelo menos uma pessoa, já valeu a pena. Obrigado por ler.

Carregando publicação patrocinada...
1
1

Saída do Agente (Aplicado ao post do Fenestra)

O Veredito em Uma Frase
Um utilitário brilhantemente superengenheirado para desenvolvedores que aparentemente desenvolvem espasmos musculares ao digitar python3 -m http.server no terminal que já está aberto na frente deles.

A Dor (Real ou Psicossomática?)
O pitch parte de uma premissa fascinante: você acabou de rodar npm run build ou vite build para gerar a pasta dist/. Como você fez isso? Provavelmente usando a força do pensamento, já que o seu terminal não estava aberto para você simplesmente rodar npx serve ou vite preview logo em seguida.

Para poupar o esforço hercúleo de digitar 12 caracteres num prompt de comando, a proposta é sequestrar a associação de arquivos .html do sistema operacional inteiro. Porque nada diz "produtividade" como transformar cada duplo clique num arquivo HTML qualquer na inicialização silenciosa de um daemon HTTP local.

O Que Surpreendentemente Funciona

Preciso dar o braço a torcer em alguns pontos, o que me causa certo desconforto físico:

  • Zero Electron / Zero Node: Em pleno 2026, alguém entregar um utilitário de 120 KB no Windows sem embutir um Chromium inteiro de 250 MB para abrir uma janela merece respeito.

  • Porta estável por diretório: Usar um hash ou mapeamento fixo de porta por pasta para não destruir o localStorage e os Service Workers a cada execução é uma sacada genuinamente inteligente. Mostra que o produto foi usado na prática.

  • Honestidade no Pitch: A seção "Limitações honestas" é uma lufada de ar fresco no TabNews. Admitir de cara que o código não é assinado e que ainda tem bugs economiza o tempo de todo mundo.

Onde o Castelo de Cartas Desmorona (O Que Não Funciona)

  • O Cemitério de Daemons (Ciclo de Vida do Processo): Eu dou dois cliques no index.html. O Fenestra sobe um servidor em 127.0.0.1 e abre uma aba no meu navegador. Cinco minutos depois, eu fecho a aba. Quem mata o servidor do Fenestra? Como um servidor HTTP estático sem injeção de script ou WebSocket sabe que a aba do navegador foi fechada? Ele fica rodando em background eternamente colecionando portas abertas até o próximo reboot, ou existe um timeout arbitrário que vai derrubar o servidor exatamente quando eu der F5 depois de ir buscar um café?

  • Esquizofrenia de Stack (.NET + Go): Se você já escreveu um binário estático em Go para Linux e macOS — uma linguagem cuja principal virtude na Terra é fazer cross-compilation trivial para Windows gerando um único .exe sem dependências —, por que cargas d'água manter uma base de código separada em .NET Framework para Windows? Você duplicou sua superfície de bugs e manutenção para economizar 2 megabytes de espaço em disco num SSD de 1 Terabyte.

  • A Contradição da "Privacidade": O pitch bate no peito com orgulho: "Sem cookies, sem analytics, sem telemetria". Literalmente na linha seguinte: "Um version.json estático é checado uma vez por semana; se houver atualização, abre uma aba". Meu caro, um binário local fazendo requisições HTTP automáticas em background para um servidor externo sem eu pedir é a definição de dicionário de phone home. E pior: abrir uma aba no meu navegador do nada para avisar de update é o comportamento clássico de adware dos anos 2000.

  • Fricção de OS (SmartScreen e Gatekeeper): O público-alvo que tem preguiça de abrir o terminal é exatamente o público que vai entrar em pânico quando o Windows SmartScreen exibir uma tela vermelha gritando que o seu .exe não assinado vai roubar a escritura da casa deles. E no macOS, pedir para o usuário usar um "kit de montagem" para compilar localmente um app que serve para evitar o uso do terminal é uma obra-prima da ironia.

Respostas às Perguntas do Autor

  1. O fluxo de "tornar padrão" no Windows está claro? Claro até o momento em que o usuário baixar um boleto em HTML ou um relatório salvo do banco, der dois cliques e, em vez de apenas abrir no navegador, subir uma instância de servidor web local servindo a pasta Downloads inteira dele na porta local.

  2. O kit de montagem do macOS funcionou para você? Se o usuário de macOS sabe rodar um script de build para montar e assinar localmente o seu pacote, ele já sabe criar um alias de uma linha no .zshrc que faz o que o seu produto faz em 4 segundos.

  3. O que quebrou ou confundiu nos primeiros cinco minutos? A dissonância cognitiva de instalar via Homebrew (no terminal) uma ferramenta cujo único propósito existencial é não abrir o terminal.

Nota na Escala "Reinventando a Roda": 8.5/10
Uma execução técnica surpreendentemente limpa e enxuta para resolver um problema que só existe se o seu teclado estiver com as teclas Alt e Tab quebradas.

1

Obrigado pelo review. Vou separar o que aceito, o que preciso explicar melhor e o que vou mudar.

O que aceito sem discussão

  • Ciclo de vida: fechar a aba realmente não mata o servidor quando o navegador já estava aberto. Hoje ele encerra quando o processo de navegador iniciado pelo Fenestra termina, ou após 4 horas ociosas. Isso é frágil e mal explicado. Vou adicionar um comando explícito de parada e reduzir/documentar o timeout.
  • Update check: você tem razão. Checagem automática sem consentimento e aba abrindo sozinha é comportamento invasivo, mesmo sem telemetria. Vou tornar isso opt-in, desligado por padrão; --check-update continua manual.
  • Associação .html: é opcional, mas o risco que você descreveu existe. Um HTML baixado que precise de origem pode expor a pasta local. Vou deixar isso explícito e estudar uma confirmação/limite para pastas que não parecem build.
  • Duplicação .NET + Go: é dívida real. O motivo histórico foi tamanho (120 KB vs ~7 MB) e não exigir SDK no Windows, mas manter duas bases custa mais do que economiza. Vou avaliar unificar no Go.
  • SmartScreen/Gatekeeper e o “kit de montagem” no macOS: são atritos reais. Assinatura/notarização não são gratuitas; a documentação precisa ser mais honesta sobre isso.

O que preciso corrigir na crítica

  • HTML comum não sobe servidor: o Fenestra abre file:// quando a página não precisa de origem. O servidor só entra para módulos ES, caminhos absolutos, fetch ou service worker.
  • Para quem já está no terminal, python3 -m http.server resolve. O público que justifica a ferramenta é outro: abrir um build pelo gerenciador de arquivos, um artefato de CI, um projeto recebido por ZIP — e ter porta estável, fallback de SPA e confinamento de caminhos, que o http.server não tem.
  • Chamar de “phone home” é justo no consentimento; nos dados, não: a requisição é um GET estático, sem identificador, sem projeto, sem uso.

O que vou fazer

  1. Update check opt-in e aba só depois do consentimento.
  2. --stop e timeout menor, com documentação clara.
  3. Aviso e limite no handler .html.
  4. Avaliar um único código Go para os três sistemas.
  5. Deixar as limitações ainda mais visíveis, incluindo o público-alvo real.

Se você testar a próxima versão, quero saber se esses pontos ficaram menos defensáveis. Obrigado por perder tempo com o projeto.

O review acerta em três pontos que eu mudaria de verdade: update check opt-in, ciclo de vida explícito e unificação da stack. O resto é debate legítimo de escopo: para quem já vive no terminal, a ferramenta é redundante; para quem não vive, ela resolve um atrito real.