Hyperflask – framework full stack de Flask y Htmx

• Framework web centrado en el backend basado en Flask que ofrece gestión de estado rápida y simple sin la complejidad de administrar el frontend
• Introduce una arquitectura de componentes combinada con HTMX, lo que permite crear una UI interactiva basada en el servidor
• Integra un stack web moderno con enrutamiento basado en archivos, pipeline de assets con esbuild + TailwindCSS y entorno de despliegue automatizado
• Incluye de forma nativa diversas funciones básicas como envío de correo (MJML), tareas en segundo plano, push basado en SSE, traducción y autenticación
• Con la estandarización de entornos de desarrollo y despliegue basados en contenedores y la integración con VS Code, facilita la configuración y el despliegue en la nube

---

Descripción general: framework de aplicaciones web centrado en el backend basado en Flask

• Hyperflask es un framework web de Python que funciona sobre Flask y está orientado a un diseño impulsado por el backend
• Reduce la complejidad de la gestión de estado en el frontend y ofrece una arquitectura concisa centrada en el servidor
• Incluye de base tecnologías web modernas como HTMX, TailwindCSS y esbuild
• Gracias a la integración con HTMX, permite implementar interacciones en tiempo real sin recargar toda la página
• Su arquitectura de componentes permite reutilizar componentes de backend y frontend
  • Introduce una estructura centrada en componentes en el entorno de Flask, permitiendo usar directamente componentes de frontend y backend en plantillas Jinja
  • Es posible crear componentes de backend para servidor combinados con HTMX, y también se integra de forma natural con React o Web Components
  • Mejora la reutilización del código y la mantenibilidad, ofreciendo una estructura adecuada también para desarrollar aplicaciones a gran escala
• Compatibilidad con enrutamiento basado en archivos y basado en aplicaciones
  • Usa un nuevo formato de archivo .jpy que combina código Python y plantillas Jinja
  • Inspirado en el sistema de páginas de Astro, permite gestionar en un solo lugar la definición de rutas y la composición de la UI
  • Esto simplifica la configuración del enrutamiento y hace más intuitiva la incorporación de nuevas páginas
• Ecosistema abierto
  • Hyperflask tiene una base de código propia pequeña y está construido combinando de forma orgánica varias extensiones de Flask
  • Cada extensión se gestiona como proyecto independiente, permitiendo elegirla y combinarla libremente
  • Todos los proyectos están publicados en la organización Hyperflask en GitHub y fomentan una configuración personalizada del framework
• “Batteries Included”
  • Envío de correos con MJML, tareas en segundo plano con dramatiq, push en tiempo real basado en SSE, traducción basada en gettext (i18n)
  • Autenticación y gestión de sesiones, optimización y streaming de imágenes, generación de contenido estático, entre otros
  • Ofrece un conjunto de funciones de nivel producción listo para usar sin configuración adicional
  • ORM centrado en SQL (sqlorm), optimizado para SQLite
• Configuración del entorno y despliegue
  • Estandariza los entornos de desarrollo y operación basados en contenedores, minimizando los problemas de configuración del entorno
  • La integración estrecha con VS Code facilita el desarrollo local y la depuración
  • Permite un despliegue sencillo en VPS o en los principales servicios de nube

Resumen

• Hyperflask es un framework de nueva generación que amplía el ecosistema de Flask para ofrecer una experiencia moderna de desarrollo web full stack en Python
• Con HTMX, un sistema de componentes, enrutamiento basado en archivos y un entorno de desarrollo estandarizado con contenedores, logra máxima productividad con configuración mínima

[GN⁺]

Opiniones en Hacker News

• Como creador de hyperflask, me da mucha alegría por fin publicar este proyecto en el que he trabajado durante tanto tiempo.
  La publicación de anuncio detallada puede verse aquí.
  Me gustaría escuchar todo tipo de comentarios.

  • Habría sido mejor si este enfoque fuera una librería que no dependiera del backend.
    Ya tengo un proyecto en Django con más de un millón de líneas, así que no puedo cambiarlo fácilmente; me pregunto si hay alguna forma sencilla de aplicarlo a una app de Django.

  • Como desarrollador de htmx, este proyecto se ve realmente genial.

  • Un colega hizo una app interna con la combinación flask/htmx/sqlalchemy y obtuvo buenos resultados, pero no logró conseguir aprobación para open source.
    Por eso tengo expectativas por este nuevo intento de hyperflask.

  • Me da curiosidad por qué eligieron sqlorm como ORM.
    Llevo mucho tiempo alejado del desarrollo en Python, pero pensaba que todos usaban SQLAlchemy y sqlorm me resulta desconocido.

  • Me impresiona ver un framework nuevo adoptando HTMX.
    HTMX está impulsando varias nuevas corrientes que buscan reemplazar JS y React.
    Seguramente habrá mucha gente a la que le guste la combinación de Python y Flask, y en HTMX del lado del servidor los componentes son clave.
    Además, la página principal cansa menos la vista que la de FastHTML.
    Comparándolo con 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  
    

    Gracias a estas opciones, parece que podría atraer a una base de usuarios mucho más amplia.
    El HARC stack, con el que se le compara, probablemente resulte atractivo para una minoría a la que le gusta manejar HTML de forma funcional, como una versión del lado del servidor del lenguaje Elm, o para quienes tienen alergia a la desnormalización de Tailwind.

• Desarrollando una webapp con htmx sentí que llegué a un “callejón sin salida”.
  El principal problema es que el estado de la aplicación frontend tiene que guardarse en la URL.
  En interfaces modernas con múltiples áreas, widgets, popups y demás, donde cada parte necesita su propio estado local y navegación, es muy difícil meter todo el estado en una sola URL global.
  Diseñar para que cierto estado no vaya en la URL cuando hace falta es todavía más complicado.
  Este tipo de problema se resuelve fácilmente en frameworks como React o Vue, que ofrecen su propio almacén de estado.
  Si lo estructuras como un foro tipo phpBB puede funcionar bien, pero hoy los usuarios esperan una experiencia más avanzada.

  • No es necesario guardar el estado solo en la URL.
    Hay varias formas: almacenamiento en servidor, sesión, localstorage, cookies, etc.
    Por ejemplo, una personalización del layout de la app del usuario no necesita URL, pero cuando se requiere compartir algo, como resultados de búsqueda, entonces sí es indispensable que las condiciones de búsqueda estén en la URL.
    Hay que pensar qué es lo que se quiere lograr.
    Y meter muchos widgets y popups en una sola pantalla/una sola URL bajo el nombre de “UI moderna” también puede terminar siendo una complejidad excesiva.
    Muchas veces, el almacenamiento de estado que ofrecen React/Vue no hace más que duplicar algo que ya puede administrar el servidor.

  • El enfoque de hipermedia también puede manejar interfaces suficientemente complejas.
    No hace falta insistir en poner todo en la URL.
    Puedes usar sesión, cookies, IDs de pestaña, etc., para compartir o aislar estado por pestaña, y consultar el estado en la base de datos del backend.
    La hipermedia incluso destaca en entornos en tiempo real o multijugador.
    De hecho, la desventaja de HTMX es más bien que no pone todavía más estado en el backend; hasta me gustaría que fuera más lejos en esa dirección.

  • Creo que simplemente no encaja con mi caso de uso.
    También me parece curioso pensar que React/Vue es “fácil”.

  • No creo que React o Vue resuelvan todos los problemas que esperan los usuarios.

  • Salvo en casos de complejidad muy alta, en la práctica yo resuelvo la mayoría de situaciones sin problema con htmx (combinado con unpoly, alpinejs y localstorage).

• Encontré conceptos interesantes en hyperflask.

  • Implementación de componentes: enlace
  • Forma de juntar vista y controlador en un solo archivo: enlace
    Pero los componentes, en realidad, internamente no son más que macros normales, así que me hace pensar si no sería mejor usar macros directamente.
    También me da curiosidad la elección de Flask.
    Antes intenté un enfoque similar con /dev/push, pero luego me cambié a la combinación FastAPI + Jinja2 + Alpine.js + HTMX.
    Me di cuenta de que FastAPI no es solo para APIs y lo elegí porque necesitaba soporte asíncrono.
    También me gusta Flask, pero alguna vez sentí que tenía limitaciones.

  • Esta forma de juntar vista y controlador en un solo archivo me recuerda al desarrollo en PHP de antes.
    Dependiendo del tamaño del proyecto, sí hacía el desarrollo claramente más simple, así que tenía su ventaja.

  • También creo que la combinación FastAPI + HTMX es muy efectiva.

• Por experiencia con Django, gracias a la funcionalidad de admin scaffolding casi nunca necesité construir una UI propia para diagnóstico o soporte al cliente.
  En proyectos basados en otros frameworks uno termina implementando esas funciones a mano, y muchas veces el resultado no queda tan satisfactorio como en Django.
  Hay varios frameworks que se ven atractivos, como Hyperflask, pero renunciar al framework admin de Django tiene un costo muy alto.
  Me pregunto si alguien encontró alguna alternativa o patrón de reemplazo real para Django admin.

  • Sentí exactamente lo mismo.
    Cuando me pasé a FastAPI, lo que más extrañé de Django fueron las distintas apps que estructuran el proyecto.
    Después me di cuenta de lo cómodo que era tener migraciones, archivos estáticos, templates, etc., organizados por funcionalidad.

  • Yo uso Supabase la mayor parte del tiempo.
    A veces entreno a los administradores con la UI de Supabase para que se encarguen de la gestión urgente.
    O, si es posible, también uso Airtable como backend.
    Pero casi siempre termino extrañando muchísimo Django admin, y la combinación Django+HTMX siempre me ha resultado tentadora.

  • También existe Flask-Admin, pero es mucho más simple que Django Admin.
    Me gustaría resolver ese problema en el futuro.

• Tras usar HTMX con varios frameworks, me parece que la combinación Go + Templ + HTMX logra unir bastante bien versatilidad y simplicidad.

  • En mi experiencia, Go es demasiado verboso, así que de hecho he estado pensando en pasarme de Go+Templ+HTMX a Flask + Jinja + HTMX.
    La forma de definir templates en Go me resulta engorrosa.

  • Una combinación que definitivamente quiero probar después es FastAPI + Jinja2 + HTMX.
    Ahora mismo estoy usando ese stack.

• hyperflask me da la impresión de ir en contra de la filosofía de Flask y htmx.
  Tiene demasiadas capas de abstracción y casi no se ven puntos de integración con htmx.
  Esperaba algo como FastHTML, donde htmx viene integrado.

  • La verdad, estoy disfrutando muchísimo usar FastHTML.

• Cada vez que un proyecto trae una demo tipo starfield, siempre termino esperando una opción para ajustar la velocidad y un efecto que siga el cursor del mouse.
  Ojalá eso se agregue en la próxima versión de Hyperflask.
  El proyecto en sí es excelente, me gusta Htmx, pero últimamente también he estado mirando Datastar.

  • Si ejecutas el siguiente código en la consola, puedes aplicar varios efectos como ajuste de velocidad.

    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"
    });
    

  • Me pregunto si te refieres a algo así.

  • nova.app es lo mejor que he visto hasta ahora.

• Si quieres una experiencia Fullstack Async completa basada en HTMX, también vale la pena mirar Litestar.

• Cuando lo vi por primera vez, me costó entender por qué hacía falta una estructura donde se pega directamente el template HTML dentro del archivo del controlador en Python.
  Se siente como si agregara complejidad solo para ahorrarse una simple función de render.
  Me pregunto qué punto me estoy perdiendo.

  • Este enfoque va en la misma línea que el principio de Locality of Behavior, que htmx considera importante.
    Está inspirado en Astro Pages del ecosistema JavaScript.
    En la práctica, la experiencia de desarrollo también fue buena.
    • Explicación sobre Locality of Behaviour
    • Guía de Astro Pages

• Mucha gente habla de las limitaciones de Flask y pregunta “¿por qué no FastAPI?”, pero personalmente creo que Litestar es la mejor alternativa.
  Litestar ofrece soporte para htmx de forma nativa.
  Puedes ver más información aquí.