FastUI: Schnellere und bessere Web-UIs mit Python erstellen

• FastUI ist ein neuer Ansatz, um Benutzeroberflächen für Webanwendungen mit deklarativem Python-Code zu erstellen
• Eine Sammlung von Pydantic-Modellen und TypeScript-Interfaces zur Definition von Benutzeroberflächen
• Python-Entwickler können responsive Web-Apps mit React erstellen, ohne JavaScript oder npm zu verwenden
• Frontend-Entwickler können sich auf den Aufbau wiederverwendbarer Komponenten konzentrieren, ohne jedes Mal Copy-and-paste zu betreiben
• Dadurch wird für alle Beteiligten eine echte Trennung der Zuständigkeiten möglich, bei der das Backend die gesamte Anwendung definiert und das Frontend nur die Benutzeroberfläche implementiert
• Verschiedene Komponenten sind standardmäßig enthalten: tokenbasierte Authentifizierung, GitHub OAuth, Markdown, Text, Paragraph, Heading, Code, Button, Link, Navbar, Modal, ServerLoad, Image, Iframe, Video, Table, Pagination, ModelForm

Praktische Verwendung

• FastUI besteht aus vier Teilen:
  • fastui-PyPI-Paket: Stellt Pydantic-Modelle und Utilities für UI-Komponenten bereit. Funktioniert gut mit FastAPI, ist aber nicht von FastAPI abhängig und kann auch mit anderen Python-Web-Frameworks verwendet werden.
  • @pydantic/fastui-npm-Paket: Ein React-TypeScript-Paket, mit dem sich eigene Komponenten implementieren lassen, während Mechanismen und Typen von FastUI wiederverwendet werden.
  • @pydantic/fastui-bootstrap-npm-Paket: Implementiert bzw. passt alle FastUI-Komponenten mit Bootstrap an.
  • @pydantic/fastui-prebuilt-npm-Paket: Bietet eine vorgefertigte Version der FastUI-React-App, ohne dass npm-Pakete installiert oder eigene Builds erstellt werden müssen. Das Python-Paket liefert eine einfache HTML-Seite zur Auslieferung dieser App.

Prinzipien (lange Version)

• FastUI ist eine Implementierung RESTfuler Prinzipien, jedoch nicht in der heute üblichen Auslegung, sondern gemäß den in Roy Fieldings Dissertation definierten Prinzipien.
• Nach RESTfulen Prinzipien muss das Frontend nichts über die zu erstellende Anwendung wissen, sondern nur alle Komponenten bereitstellen, die zum Aufbau der Benutzeroberfläche erforderlich sind.
• Diese Art, Anwendungen zu entwickeln, bringt mehrere wichtige Vorteile mit sich:
  • Code muss zum Erstellen neuer Funktionen nur an einer Stelle geschrieben werden.
  • Die Auslieferung von Frontend und Backend kann vollständig voneinander getrennt werden.
  • Ein Open-Source-Komponentenset kann wiederverwendet werden, weil die Komponenten den Kontext ihrer Verwendung nicht kennen müssen.
  • Mit Pydantic, TypeScript und JSON-Schema kann sichergestellt werden, dass beide Seiten über ein gemeinsam vereinbartes Schema kommunizieren.

Über Python und React hinaus

• Dieses Prinzip ist nicht auf Python- und React-Anwendungen beschränkt. Es kann in jedem Frontend und Backend eingesetzt werden, das das Schema implementiert und mit demselben vereinbarten Schema und derselben Kodierung kommuniziert.

Meinung von GN⁺

• FastUI hat das Potenzial, den Entwicklungsprozess zu vereinfachen, indem es Backend-Entwicklern eine effiziente Möglichkeit bietet, Anwendungen ohne zusätzliche Frontend-Entwicklung zu erweitern.
• Diese Technologie schafft ein Umfeld, in dem die Rollen zwischen Frontend und Backend klar getrennt sind und die jeweilige Spezialisierung optimal genutzt werden kann.
• Da FastUI derzeit noch ein laufendes Projekt ist, sollten Stabilität und Funktionsumfang vor einem Einsatz in einer echten Produktionsumgebung sorgfältig geprüft werden.
• Bei der Einführung von FastUI sollten die Kompatibilität mit bestehenden Frontend-Workflows, die Wiederverwendbarkeit und Erweiterbarkeit von Komponenten sowie die langfristige Wartbarkeit des Projekts berücksichtigt werden.
• Zu den Vorteilen dieser Technologie gehören kürzere Entwicklungszeiten und ein Backend-zentrierter Entwicklungsablauf; zugleich kann jedoch die Flexibilität im Frontend eingeschränkt sein, und Unterstützung durch die Community sowie verfügbare Materialien könnten noch vergleichsweise begrenzt sein.

[GN⁺]

Hacker-News-Kommentare

• Meinung zur Kopplung von Präsentationsschicht und Code

  • Kopplung von Präsentationsschicht und Code: Die Präsentationsschicht sollte nicht zu eng mit dem Code verbunden sein. Eine Templatesprache statt Python sei besser geeignet, und es sei noch besser, wenn Templates in verschiedenen Sprachen gerendert werden können.

• Erfahrungen bei der App-Entwicklung mit FastUI und Streamlit

  • Verwendung von FastUI und Streamlit: Für das Prototyping wurde Streamlit verwendet, das sich aber gelegentlich unbequem anfühlte. FastUI hat zwar noch Schwächen, wurde jedoch für leichtgewichtige Apps eingesetzt und reagierte dabei schneller als Streamlit.

• Meinung zu Django und HTMX

  • Django und HTMX: Die Kombination aus Django und HTMX sei elegant und arbeite schnell. Man sende nur den im Frontend gerenderten Code und könne bei wachsendem Umfang die DB verwalten.

• Praxistauglichkeit interner Apps bei serverseitiger Ereignisverarbeitung

  • Serverseitige Ereignisverarbeitung: Das Konzept sei nicht neu; es gebe andere Beispiele wie das React-basierte Solara oder das Vue-basierte NiceGUI. Für interne Apps sei es sehr praktikabel, man müsse aber akzeptieren, dass es eine gewisse Verzögerung gibt, wenn Ereignisse für alle Controls serverseitig verarbeitet werden.

• Zunahme von Frontend-Frameworks, die einen Backend-Server benötigen

  • Komplexität von Frontend-Frameworks: Viele Frontend-Frameworks müssen einen Backend-Server ausführen, um grundlegendes HTML zu rendern. Es werde infrage gestellt, ob die von solchen Frameworks gebotenen Funktionen diese Komplexität rechtfertigen.

• Vergleich der Erfahrungen mit FastUI und NiceGUI

  • FastUI und NiceGUI: NiceGUI biete direkt nach dem Auspacken eine gute Out-of-the-box-Erfahrung. FastUI wirke hauptsächlich wie ein Formular-Adapter für Pydantic-Modelle.

• Einfluss der AI-Entwicklung auf Projekt-Use-Cases

  • AI und Frontend-Entwicklung: Die Idee, dass Backend-Entwickler in ihrer eigenen Sprache schnell UIs erstellen können, sei sinnvoll, aber durch ein paar Stunden Einsatz von AI zur Erzeugung einer Basis-UI könnte der Bedarf an solchen Projekten sinken.

• Erfahrungen mit Side-Project-Entwicklung unter Verwendung von Dart/Flutter

  • Verwendung von Dart/Flutter: Das Schreiben von Side Projects mit Dart/Flutter minimiere Reibungsverluste und sei weniger umständlich. Wenn eine Web-App geschrieben werden müsse und Flutter nicht passe, würde HTMX verwendet.

• Vergleich mit Java Server Faces und Grenzen serverseitiger Abstraktion

  • Erfahrungen mit Java Server Faces: Es wirke ähnlich wie Java Server Faces. Der Versuch, die Feinheiten der Frontend-Entwicklung in eine serverseitige Abstraktion zu verlagern, werde wohl nur für eine begrenzte Menge von Anwendungen wie Verwaltungs-UIs funktionieren.

• Frage, ob Roundtrips zum Server für den Aufbau von Benutzeroberflächen geeignet sind

  • Roundtrips zum Server: Es wird infrage gestellt, ob ein Hin-und-zurück zum Server bei jeder Client-Interaktion wirklich immer eine gute Idee für den Aufbau von Benutzeroberflächen ist.