Hyperflask – framework full-stack com Flask e Htmx

 (hyperflask.dev)
11 pontos por GN⁺ 2025-10-17 | 1 comentários | Compartilhar no WhatsApp
  • Framework web orientado ao backend baseado em Flask que oferece gerenciamento de estado rápido e simples sem a complexidade de administrar o frontend
  • Introduz uma arquitetura de componentes combinada com HTMX, permitindo a criação de UIs interativas baseadas no servidor
  • Integra uma stack web moderna, incluindo roteamento baseado em arquivos, pipeline de assets com esbuild + TailwindCSS e ambiente de deploy automatizado
  • Inclui diversos recursos nativos, como envio de e-mails (MJML), tarefas em segundo plano, push baseado em SSE, tradução e autenticação
  • Com padronização do ambiente de desenvolvimento e deploy baseada em contêineres e integração com VS Code, oferece configuração simples e suporte a deploy em nuvem

Visão geral: framework de webapps orientado ao backend baseado em Flask

  • Hyperflask é um framework web em Python que roda sobre o Flask e segue uma abordagem orientada pelo backend
  • Reduz a complexidade do gerenciamento de estado no frontend e oferece uma arquitetura enxuta centrada no servidor
  • Já vem com tecnologias web modernas como HTMX, TailwindCSS, esbuild integradas por padrão
  • Com a integração do HTMX, é possível implementar interações em tempo real sem recarregar a página inteira
  • A arquitetura de componentes permite reutilizar componentes de backend e frontend
    • Introduz uma estrutura centrada em componentes no ambiente Flask, permitindo usar componentes de frontend e backend diretamente em templates Jinja
    • Permite criar componentes de backend no servidor combinados com HTMX, além de se integrar naturalmente com React ou Web Components
    • Aumenta a reutilização de código e a manutenibilidade, oferecendo uma estrutura adequada também para o desenvolvimento de apps de grande porte
  • Suporte a roteamento baseado em arquivos e em apps
    • Usa um novo formato de arquivo .jpy que combina código Python com templates Jinja
    • Inspirado no sistema de páginas do Astro, permite gerenciar definição de rotas e composição de UI em um só lugar
    • Com isso, a configuração de rotas fica mais simples, e adicionar novas páginas se torna intuitivo
  • Ecossistema aberto
    • O Hyperflask tem uma base de código própria pequena e é composto por uma combinação orgânica de várias extensões do Flask
    • Cada extensão é mantida como projeto independente, permitindo escolha e combinação livres
    • Todos os projetos são públicos na organização Hyperflask no GitHub e incentivam a montagem de um framework personalizado pelo usuário
  • “Batteries Included”
    • Envio de e-mails com MJML, tarefas em segundo plano com dramatiq, push em tempo real baseado em SSE, tradução baseada em gettext (i18n)
    • Autenticação e gerenciamento de sessão, otimização e streaming de imagens, geração de conteúdo estático, entre outros
    • Oferece um conjunto de recursos em nível de produção pronto para uso sem configuração adicional
    • ORM centrado em SQL (sqlorm), otimizado para SQLite
  • Configuração de ambiente e deploy
    • Padroniza ambientes de desenvolvimento e operação baseados em contêineres, minimizando problemas de configuração
    • A integração estreita com o VS Code facilita o desenvolvimento local e a depuração
    • Suporta deploy fácil em VPS ou nos principais serviços de nuvem

Resumo

  • Hyperflask expande o ecossistema Flask e oferece uma experiência moderna de desenvolvimento web full-stack em Python
  • Com HTMX, sistema de componentes, roteamento baseado em arquivos e ambiente de desenvolvimento padronizado com contêineres, entrega máxima produtividade com configuração mínima

Leituras relacionadas

1 comentários

 
GN⁺ 2025-10-17
Comentários no Hacker News

  • Como criador do hyperflask, estou feliz por finalmente lançar um projeto preparado por tanto tempo
    O anúncio detalhado pode ser visto aqui
    Gostaria muito de receber vários feedbacks

    • Acho que teria sido melhor se isso fosse uma biblioteca, sem ficar atrelada ao backend
      Já tenho um projeto Django com mais de um milhão de linhas e não dá para mudar facilmente, então queria saber se existe alguma forma simples de aplicar isso a um app Django

    • Como desenvolvedor de htmx, esse projeto parece muito legal

    • Um colega criou um app interno com a combinação flask/htmx/sqlalchemy e teve bons resultados, mas não conseguiu aprovação para open source
      Por isso, estou animado com essa nova tentativa do hyperflask

    • Fiquei curioso sobre por que escolheram sqlorm como ORM
      Faz tempo que estou afastado do desenvolvimento em Python, mas achei que todo mundo usava SQLAlchemy, e sqlorm é algo pouco familiar para mim

    • É impressionante ver um novo framework abraçando o HTMX
      O HTMX está estimulando várias novas tendências que tentam substituir JS e React
      Muita gente também vai gostar da combinação Python com Flask, e em HTMX server-side os componentes são essenciais
      E o site também é mais agradável aos olhos do que o FastHTML
      Comparando com harcstack.org

      Language: Python vs. Raku  
Web framework: Flask vs. Cro  
ORM: ?? vs. Red  
Components: ambos  
HTML: templates vs. funcional  
CSS: DaisyUI/Tailwind/Bootstrap vs. Pico

      Essas escolhas parecem capazes de atrair uma base de usuários muito maior
      Já a stack HARC, usada como comparação, deve agradar a uma minoria que curte tratar HTML de forma funcional, como uma versão server-side da linguagem Elm, ou que tem alergia à desnormalização do Tailwind

  • Ao desenvolver um webapp com htmx, senti que cheguei a um "beco sem saída"
    O principal problema é que o estado da aplicação no frontend precisa ser armazenado na URL
    Em UIs modernas com várias áreas, widgets, pop-ups etc., cada um precisando de estado local e navegação própria, é muito difícil colocar todo o estado em uma única URL global
    E também é ainda mais difícil projetar algo de forma que o estado não vá para a URL quando necessário
    Frameworks como React ou Vue, que oferecem seu próprio armazenamento de estado, resolvem isso facilmente
    Talvez funcione bem se for algo como um fórum phpBB, mas os usuários de hoje esperam uma experiência mais avançada

    • Não é necessário guardar o estado só na URL
      Há várias opções, como armazenamento no servidor, sessão, localstorage e cookies
      Por exemplo, personalização do layout do app pelo usuário não precisa de URL, mas algo como resultados de busca, que precisam ser compartilháveis, deve obrigatoriamente ter os critérios de busca na URL
      É preciso pensar no que se quer alcançar
      E colocar muitos widgets e pop-ups numa única tela/URL em nome de uma "UI moderna" pode, na verdade, virar complexidade excessiva
      Muitas vezes, o armazenamento de estado oferecido por React/Vue é só uma duplicação do que já pode ser gerenciado no servidor

    • A abordagem de hipermídia também consegue lidar com UIs complexas
      Não é preciso insistir que tudo esteja na URL
      Dá para usar sessões, cookies, IDs de aba etc. para compartilhar/isolar estado por aba e consultar o estado no banco de dados do backend
      Hipermídia também funciona muito bem em ambientes em tempo real/multiplayer
      Na verdade, o ponto fraco do HTMX é não colocar ainda mais estado no backend; eu até gostaria que ele fosse mais ousado nisso

    • Acho apenas que isso não combina com o meu caso de uso
      Também acho curioso considerar React/Vue "fáceis"

    • Também não acho que React ou Vue resolvam todos os problemas que os usuários esperam ver resolvidos

    • A menos que a complexidade seja muito alta, na prática eu consigo cobrir a maior parte dos casos tranquilamente com htmx (junto com unpoly, alpinejs e localstorage)

  • Encontrei alguns conceitos interessantes no hyperflask

    • implementação de componentes: link
    • forma de colocar view e controller no mesmo arquivo: link
      Mas os componentes, no fim das contas, parecem ser apenas macros comuns por baixo dos panos, então fico pensando se não seria melhor usar macros diretamente
      Também fiquei curioso sobre a escolha do Flask
      No passado, tentei uma abordagem parecida em /dev/push e depois migrei para a combinação FastAPI + Jinja2 + Alpine.js + HTMX
      Percebi que FastAPI não é só para APIs e escolhi essa opção porque precisava de suporte assíncrono
      Também gosto de Flask, mas já senti que ele tem limitações

    • Essa forma de colocar view e controller no mesmo arquivo me lembrou o desenvolvimento antigo em PHP
      Dependendo do tamanho do projeto, isso realmente tornava o desenvolvimento mais simples, o que era uma vantagem

    • Também acho a combinação FastAPI + HTMX muito eficaz

  • Pela minha experiência com Django, graças ao recurso de scaffolding do admin, quase nunca precisei criar manualmente uma UI para diagnóstico e suporte ao cliente
    Em projetos baseados em outros frameworks, esse tipo de funcionalidade precisa ser implementado à mão, e o resultado muitas vezes não fica tão satisfatório quanto no Django
    Existem muitos frameworks que parecem atraentes, como o Hyperflask, mas abrir mão do framework admin do Django tem um custo muito alto
    Fico curioso se alguém encontrou alternativas ou padrões substitutos reais para o Django admin

    • Tive a mesma sensação
      Ao migrar para FastAPI, uma das coisas de que mais senti falta no Django foram os vários apps que estruturam o projeto
      Só depois percebi o quanto era confortável ter migrações, arquivos estáticos, templates etc. organizados por funcionalidade

    • Eu uso Supabase na maior parte do tempo
      Às vezes treino admins usando a UI do Supabase para cuidarem de tarefas urgentes
      Ou, quando possível, também uso Airtable como backend
      Mas quase sempre acabo sentindo muita falta do Django admin, e a combinação Django+HTMX sempre parece muito tentadora

    • Existe o Flask-Admin, mas ele é bem mais simples do que o Django Admin
      Quero tentar resolver esse problema no futuro

  • Depois de usar HTMX com vários frameworks, acho que a combinação Go + Templ + HTMX consegue unir bem versatilidade e simplicidade

    • Na minha experiência, Go é verboso demais, então estou até pensando em sair de Go+Templ+HTMX e ir para Flask + Jinja + HTMX
      Acho a forma de definir templates em Go meio trabalhosa

    • Uma combinação que quero muito experimentar depois é FastAPI + Jinja2 + HTMX
      No momento, estou usando essa stack

  • O hyperflask parece destoar da filosofia do Flask e do htmx
    Há camadas de abstração demais e quase não vejo pontos reais de integração com htmx
    Eu esperava algo mais no estilo do FastHTML, com htmx embutido

    • Estou me divertindo bastante com FastHTML

  • Sempre que vejo um demo de starfield em um projeto, acabo esperando controles de velocidade e um efeito que siga o cursor do mouse
    Seria ótimo ver isso adicionado em uma próxima versão do Hyperflask
    O projeto em si é excelente e eu gosto de Htmx, mas recentemente também tenho prestado atenção no Datastar

    • Se você executar o código abaixo no console, dá para aplicar vários efeitos, incluindo controle de velocidade

      new WarpSpeed("warpdrive", {
  "speed": 20,
  "speedAdjFactor": 0.03,
  "density": 2,
  "shape": "circle",
  "warpEffect": true,
  "warpEffectLength": 5,
  "depthFade": true,
  "starSize": 3,
  "backgroundColor": "hsl(224,15%,14%)", 
  "starColor": "#FFFFFF"
});

    • Você está falando talvez de algo assim?

    • nova.app é o melhor que já vi até agora

  • Se você quer uma experiência Fullstack Async completa baseada em HTMX, também vale dar uma olhada no Litestar

  • Quando vi pela primeira vez, tive dificuldade para entender por que seria necessário anexar templates HTML diretamente ao arquivo de controller em Python
    Parece que isso adiciona complexidade só para economizar uma função simples de renderização
    Fiquei curioso sobre o ponto que talvez eu tenha deixado passar

  • Muita gente fala sobre as limitações do Flask e pergunta "por que não FastAPI?", mas pessoalmente acho que o Litestar é a melhor alternativa
    O Litestar oferece suporte a htmx por padrão
    Mais informações podem ser vistas aqui