FastUI: crear interfaces web mejores y más rápido con Python

• FastUI es una nueva forma de construir interfaces de usuario para aplicaciones web con código Python declarativo
• Es un conjunto de modelos de Pydantic e interfaces de TypeScript que definen la interfaz de usuario
• Si eres desarrollador de Python, puedes crear una web app reactiva con React sin usar JavaScript ni npm
• Los desarrolladores frontend pueden concentrarse en construir componentes reutilizables sin tener que copiar y pegar cada vez
• Esto permite una verdadera separación de responsabilidades: el backend define toda la aplicación y el frontend implementa solo la interfaz de usuario para todos los usuarios
• Incluye varios componentes listos para usar: autenticación basada en tokens, GitHub OAuth, Markdown, Text, Paragraph, Heading, Code, Button, Link, Navbar, Modal, ServerLoad, Image, Iframe, Video, Table, Pagination, ModelForm

Uso real

• FastUI se compone de cuatro partes:
  • Paquete PyPI fastui: ofrece modelos de Pydantic y utilidades para componentes de UI. Funciona muy bien con FastAPI, pero no depende de FastAPI, y también puede usarse con otros frameworks web de Python.
  • Paquete npm @pydantic/fastui: es un paquete React TypeScript que permite implementar tus propios componentes reutilizando la maquinaria y los tipos de FastUI.
  • Paquete npm @pydantic/fastui-bootstrap: implementa/personaliza todos los componentes de FastUI usando Bootstrap.
  • Paquete npm @pydantic/fastui-prebuilt: ofrece una versión preconstruida de la app React de FastUI sin necesidad de instalar paquetes npm ni compilar nada por tu cuenta. El paquete de Python proporciona una página HTML simple que sirve esta app.

Principios (versión larga)

• FastUI es una implementación de los principios RESTful, pero no en el sentido en que suelen entenderse, sino siguiendo los principios definidos en la tesis doctoral de Roy Fielding.
• Según los principios RESTful, el frontend no necesita saber nada sobre la aplicación que está construyendo; solo debe proporcionar todos los componentes necesarios para componer la interfaz.
• Construir aplicaciones de esta manera ofrece varias ventajas importantes:
  • Solo necesitas escribir código en un lugar para crear nuevas funciones.
  • Se puede separar por completo el despliegue del frontend y del backend.
  • Se puede reutilizar un conjunto de componentes open source, ya que no necesitan conocer el contexto en el que se usarán.
  • Se puede garantizar que ambos lados se comuniquen con un esquema acordado usando Pydantic, TypeScript y JSON Schema.

Más allá de Python y React

• Este principio no se limita a aplicaciones de Python y React; puede usarse en cualquier frontend y backend que implemente el esquema, siempre que se comuniquen usando el mismo esquema y la misma codificación acordados.

Opinión de GN⁺

• FastUI tiene el potencial de simplificar el proceso de desarrollo al ofrecer una forma eficiente para que los desarrolladores backend amplíen aplicaciones sin depender de desarrollo frontend.
• Esta tecnología aclara la división de roles entre frontend y backend, creando un entorno donde se puede aprovechar al máximo la especialidad de cada lado.
• Por ahora, FastUI sigue siendo un proyecto en desarrollo, por lo que su estabilidad y funcionalidad deben evaluarse cuidadosamente antes de usarlo en un entorno de producción real.
• Al adoptar FastUI, conviene considerar la compatibilidad con los flujos de desarrollo frontend existentes, la reutilización y escalabilidad de los componentes, y el mantenimiento a largo plazo del proyecto.
• Las ventajas de elegir esta tecnología incluyen una reducción en el tiempo de desarrollo y un flujo de trabajo centrado en el backend, pero a cambio la flexibilidad del frontend puede verse limitada, y el soporte de la comunidad y la documentación disponible pueden ser relativamente escasos.

[GN⁺]

Opiniones de Hacker News

• Opinión sobre el acoplamiento entre la capa de presentación y el código

  • Acoplamiento entre la capa de presentación y el código: La capa de presentación no debería estar demasiado estrechamente conectada al código. Un lenguaje de plantillas es más adecuado que Python, y es mejor poder renderizar plantillas en varios lenguajes.

• Experiencia desarrollando apps con FastUI y Streamlit

  • Uso de FastUI y Streamlit: Se hizo prototipado con Streamlit, pero a veces resultaba incómodo. FastUI todavía tiene carencias, pero al usarlo para apps ligeras se percibió una velocidad de respuesta mayor que con Streamlit.

• Opinión sobre Django y HTMX

  • Django y HTMX: La combinación de Django y HTMX es elegante y funciona rápido. Solo envía código renderizado al frontend, y permite gestionar la base de datos cuando la escala crece.

• Utilidad de las apps internas para el manejo de eventos del lado del servidor

  • Manejo de eventos del lado del servidor: Este concepto no es nuevo, y existen otros ejemplos como Solara basado en React o NiceGUI basado en Vue. Es muy práctico para apps internas, pero hay que aceptar algo de latencia al manejar los eventos de todos los controles desde el servidor.

• Aumento de frameworks frontend que requieren un servidor backend

  • Complejidad de los frameworks frontend: Muchos frameworks frontend necesitan ejecutar un servidor backend para renderizar HTML básico. Queda la duda de si las funciones que ofrecen justifican esa complejidad.

• Comparación de la experiencia entre FastUI y NiceGUI

  • FastUI y NiceGUI: NiceGUI ofrece una experiencia lista para usar desde el primer momento. FastUI parece principalmente un adaptador de formularios para modelos de Pydantic.

• Impacto del avance de la IA en los casos de uso de estos proyectos

  • IA y desarrollo frontend: La idea de que los desarrolladores backend puedan generar rápidamente una UI en su propio lenguaje sigue siendo válida, pero como ahora se puede usar IA por unas horas para generar una UI básica, la necesidad de este tipo de proyectos podría debilitarse.

• Experiencia desarrollando side projects con Dart/Flutter

  • Uso de Dart/Flutter: Escribir side projects con Dart/Flutter minimiza la fricción y resulta menos engorroso. Si hubiera que escribir una web app y Flutter no encajara, se usaría HTMX.

• Comparación con Java Server Faces y límites de la abstracción del lado del servidor

  • Experiencia con Java Server Faces: Da la impresión de ser similar a Java Server Faces. Los intentos de trasladar las sutilezas del desarrollo frontend a una abstracción del lado del servidor probablemente solo funcionen en un conjunto limitado de aplicaciones, como las UI de administración.

• Pregunta sobre si los viajes de ida y vuelta al servidor son adecuados para construir interfaces de usuario

  • Viajes de ida y vuelta al servidor: Se plantea la duda de si hacer un round trip al servidor en cada interacción del cliente es realmente una buena idea para construir interfaces de usuario.