XMLUI

 (blog.jonudell.net)
2 Punkte von GN⁺ 2025-07-21 | 1 Kommentare | Auf WhatsApp teilen
  • XMLUI wendet das Komponentenentwicklungsmodell von Visual Basic auf das moderne Web an und ermöglicht die einfache Entwicklung von Web-Apps auch ohne Kenntnisse in React und CSS
  • XMLUI erlaubt es, verschiedene Komponenten bequem per XML-Markup zu kombinieren und unterstützt reaktive Datenbindung, Theme-Verwaltung, Schema-Erweiterung und mehr
  • Über das Model Context Protocol (MCP) kann man mit KI zusammenarbeiten, um die Entwicklungseffizienz zu steigern und die Wartbarkeit des Codes zu verbessern
  • Durch die Vereinfachung des komplexen React-Ökosystems schafft XMLUI eine Umgebung, in der auch Nicht-Spezialisten problemlos UI und Apps entwickeln können
  • Bereitstellung und Erweiterung sind einfach, und auch Entwickler ohne tiefes Wissen zu React oder CSS können verschiedene Webprojekte und CMS-Implementierungen umsetzen

Einführung und Überblick

Das XMLUI-Projekt ist der Versuch, die intuitive Art der Komponentenkombination aus dem Visual Basic der 1990er Jahre in die Web-Umgebung zu übertragen. Damals konnten mit Visual Basic auch Menschen ohne professionelle Programmiererfahrung nützliche Software einfach erstellen, indem sie verschiedene Komponenten miteinander verbanden. Im Web wurde ein vergleichbares Maß an Benutzerfreundlichkeit oder ein entsprechendes Ökosystem jedoch nicht erreicht. XMLUI kapselt React-Komponenten und CSS und ermöglicht die Entwicklung von Web-Apps allein mit XML-basiertem Markup.

Hier ist ein Beispiel für einige Zeilen XMLUI-Code:

<App>
  <Select id="lines" initialValue="bakerloo">
    <Items data="https://api.tfl.gov.uk/line/mode/tube/status">;
    </Items>
  </Select>
  <DataSource
    id="tubeStations"
    url="https://api.tfl.gov.uk/Line/{lines.value}/Route/Sequence/inbound";
    resultSelector="stations"/>
  <Table data="{tubeStations}" height="280px">
    <Column bindTo="name" />
    <Column bindTo="modes" />
  </Table>
</App>

Schon mit rund 12 Zeilen XML lassen sich damit folgende Aufgaben ausdrücken:

  • Select-Optionen werden per API-Aufruf automatisch befüllt
  • Mithilfe des Select-Werts werden Daten aus einer anderen API abgerufen
  • Bestimmte Felder aus dem API-Ergebnis werden extrahiert und in Tabellenform gebunden

XMLUI ist modern, komponentenbasiert und reaktiv, erlaubt es Anwendern aber zugleich, Entwicklung und Wartung ohne internes Wissen über React oder CSS durchzuführen. Genau das ist ein wichtiger Unterschied, der die Hürden des bestehenden JavaScript-Ökosystems senkt.

Komponenten-Ökosystem

Früher und heute

In der Zeit von Visual Basic ließen sich viele verschiedene Bausteine (Komponenten) wie Diagramme, Netzwerkfunktionen, Datenzugriff oder Medienwiedergabe leicht in Apps integrieren. Dieses produktive Komponenten-Ökosystem wurde jedoch nicht vollständig ins Web übertragen. Zwar werden heute im Web hauptsächlich React-basierte Komponenten verwendet, doch dafür sind weiterhin die Fähigkeiten professioneller Entwickler erforderlich. XMLUI kapselt diese React-Komponenten so, dass sie von jedem leicht genutzt werden können.

Benutzerdefinierte Komponenten

XMLUI bietet nicht nur eine Vielzahl integrierter Komponenten, sondern erlaubt auch, eigene Komponenten zu definieren und sie nach Bedarf miteinander zu kombinieren und wiederzuverwenden. So lässt sich beispielsweise eine TubeStops-Komponente, die Informationen zu Londoner U-Bahn-Stationen anzeigt, wie folgt definieren:

<Component name="TubeStops">
  <DataSource ... />
  <Text variant="strong">{...}</Text>
  <Table ... >
    <Column ... />
  </Table>
</Component>

TubeStops ruft je nach Linienname Daten per API ab und stellt sie tabellarisch dar. Das eigentliche Markup ist gut lesbar, und wenn es auf über 100 Zeilen anwächst, lässt es sich zur leichteren Wartung in Komponenten refaktorieren. In letzter Zeit ist durch die Unterstützung von LLMs (Large Language Models) auch die Komponenten-Refaktorierung und Code-Wartung deutlich flexibler geworden.

Reaktive Bindung und deklarative Entwicklung

In XMLUI werden Änderungen an Daten und UI-Werten automatisch miteinander verknüpft (Reactive Data Binding). Wenn sich zum Beispiel die Auswahl in einer Select-Komponente ändert, wird auch die darauf verweisende API-Adresse (url der DataSource) automatisch aktualisiert und neue Daten werden erneut abgerufen. Das ähnelt Zellbezügen in Excel.

Man muss sich zwar an das deklarative Entwicklungsparadigma statt an die klassische imperative Entwicklung gewöhnen, erhält dann aber eine schnelle und intuitive Entwicklungserfahrung. So lässt sich etwa eine Suchfunktion leicht so umsetzen, dass Änderungen im Eingabefeld ohne Button in Echtzeit mit Daten verknüpft und in einer Tabelle dargestellt werden.

Theme-System

Anfangs war das Interesse am Theme-System nicht besonders groß, doch die Theme-Verwaltung von XMLUI ist sehr leistungsfähig. Ohne CSS zu schreiben lassen sich Farben, Hintergründe, Abstände, Schriftarten und mehr für einzelne Komponenten konsistent auf Variablenbasis verwalten. So kann etwa die Farbe eines Buttons je nach Kontext und Zustand (hover usw.) unterschiedlich festgelegt werden.

Themes lassen sich in Formen wie color-primary oder backgroundColor-Button fein granular steuern, sodass sich die gesamte UI-Farbpalette einfach definieren und global oder gezielt anwenden lässt.

Einsatz von Skripten

XMLUI ist nicht vollständig deklarativ. Wie bei Visual Basic ist die partielle Einbindung einfacher Skripte (meist JavaScript) möglich, etwa zur Verarbeitung von API-Antworten (transformResult) oder für bedingtes Rendering. Das ist selbst ohne Expertenniveau für normale Entwickler gut nutzbar.

Model Context Protocol (MCP) und Zusammenarbeit mit KI

Auf die Frage „Wenn LLMs inzwischen direkt React-Apps erzeugen können, welchen Sinn hat XMLUI dann noch?“ betont der Autor den Wert von XMLUI im Hinblick auf Zugänglichkeit, Wartbarkeit und Zusammenarbeit des Codes.

MCP (Model Context Protocol) stellt einen Server bereit, über den Agenten wie LLMs XMLUI-Code, Dokumentation und Beispiele durchsuchen, verstehen und zitieren können. Dadurch können KI und Entwickler im selben Bedeutungsraum kommunizieren und die schrittweise automatische Generierung und Anpassung von Code abstimmen.

  • Beispiel: Während der Entwicklung kann man LLMs sofort zu konkreten Funktionen, Beispielen, Dokumentation oder Einsatzorten befragen

Es werden auch Richtlinien für die effektive Zusammenarbeit mit LLMs bereitgestellt. Dazu gehören zum Beispiel vorherige Abstimmung vor Code-Vorschlägen, die Nutzung nur dokumentierter Beispiele und Einschränkungen unnötiger Stilgestaltung. Außerdem bietet die Dokumentationsseite einen Abschnitt „How To“ sowie eine durch MCP unterstützte Struktur, die auch für KI leicht zugänglich ist.

Content-Management und CMS-Einsatz

Mit XMLUI lassen sich auch Websites und CMS leicht aufbauen, und ohne Kenntnisse in React oder Next.js sind alltägliche Seitenänderungen und Wartungsarbeiten einfach möglich. Tatsächlich werden die offizielle XMLUI-Website, Demos und Dokumentation vollständig mit XMLUI erstellt und gepflegt.

Code, Erklärung und Live-Demo lassen sich in einem Dokument gemeinsam bereitstellen, was sehr praktisch ist.

Erweiterbarkeit

Grundsätzlich kapselt XMLUI verschiedene React-Komponenten, doch auch das Kapseln neuer externer Komponenten ist einfach. Als Beispiel wird der fortgeschrittene Dokumenteneditor Tiptap unkompliziert als XMLUI TableEditor gekapselt. Gerade bei schwierigen Aufgaben in der Markdown-Bearbeitung, etwa beim Erstellen von Tabellen, lässt sich so mit einem visuellen Editor leicht Abhilfe schaffen.

So waren bisher die Rollen von Komponenten- und Lösungsentwicklern klar getrennt, doch mit XMLUI können nun auch allgemeine Entwickler nützliche UI-Komponenten selbst erweitern und kombinieren.

Bereitstellung

Die Bereitstellung von XMLUI-Apps ist sehr einfach.

  • Minimale Konfiguration: Es werden nur Main.xmlui, index.html und die XMLUI-JS-Datei benötigt
  • Jeder statische Webserver kann verwendet werden, und die App kann direkt in einem AWS-S3-Bucket laufen
  • Eine komplexe Serverumgebung ist nicht zwingend erforderlich; bei Bedarf lassen sich zusätzliche lokale Server, CORS-Proxys usw. einrichten

Webentwicklung für alle

Der Schöpfer von XMLUI, Gent Hito, hat sich bei /n software, CData und anderen Unternehmen darauf konzentriert, die Einstiegshürden in Entwicklungsumgebungen zu senken.

  • /n software: einfache Nutzung von Netzwerkkomponenten
  • CData: vereinfachter Datenzugriff
  • XMLUI: Vereinfachung der UI-Entwicklung

In den vergangenen rund 20 Jahren ist die UI-Entwicklung im Web immer spezialisierter und komplexer geworden, doch XMLUI ist so konzipiert, dass auch Lösungsentwickler ohne Expertenstatus ihre eigene UI und eigene Apps leicht erstellen können. Tatsächlich lässt es sich direkt auf verschiedene Beispiele anwenden, etwa auf Dashboard-UIs rund um CoreSSH.

Es wird allen Entwicklern empfohlen, die sich eine einfachere Umgebung zur Erstellung von Web-Apps wünschen, insbesondere nicht spezialisierten Solution Buildern, Junior-Entwicklern und backendorientierten Entwicklern.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-21
Hacker-News-Kommentare

  • Jon ist schon sehr lange in der Branche, und ich bin ein Fan von ihm. Er ist jemand mit viel Erfahrung und Reife, und es lohnt sich, ihm zuzuhören. Ich bin ein Fan von Web Components, aber ich denke, React so dominant geworden ist, liegt auch daran, dass die Umgebung für Entwickler, die früher gut mit Visual-Basic-Komponenten arbeiten konnten, schwer zugänglich ist. Das ist der wichtigste Punkt in diesem Artikel. Die technische Erklärung ist auch wichtig, aber er trifft den Kern, warum solche Versuche nötig sind. Ob XMLUI diesen Entwicklern die passende Abstraktion bieten kann, muss sich noch zeigen. Trotzdem macht es schon Freude, allein so einen Versuch zu sehen

    • Der aktuelle Code läuft nur in JS-Evergreen-Browsern. Das fühlt sich ein bisschen so an wie früher bei VB, das auch nur unter Windows und mit bestimmten installierten DLLs richtig funktionierte

  • Um 2014 herum gab es bei Polymer einen ähnlichen Versuch. Netzwerkanfragen wurden zum Beispiel mit Komponenten wie <iron-ajax> umgesetzt iron-ajax-Link. Außerdem gab es eine Zeit, in der Adobe Flex sehr populär war; heute lebt es als Apache Royale weiter Apache-Royale-Link. Bei Microsoft gab es XAML, NetUI und FlexUI, und auch die Office-2007-UI wurde so gebaut. Theoretisch war das alles großartig, aber praktisch hatte ich das Gefühl, dass solche markup-basierten Abstraktionen selbst für Einsteiger weniger effektiv waren als ein code-first-Ansatz wie JSX

    • Es gab auch Coldfusion (beim Gedanken daran läuft es mir kalt den Rücken herunter)

  • Ich habe gleichzeitig den Gedanken „Wir erfinden HTML schon wieder neu“ und das Gefühl „Das könnte für mich sofort nützlich sein“. Der Mensch ist eben ein vielschichtiges Wesen

    • Danke für den Hinweis auf den Dichter Walt Whitman und sein Werk. „Widerspreche ich mir selbst? Nun gut, dann widerspreche ich mir eben selbst“
    • Das ist wirklich eine Formulierung, mit der ich mich sehr identifizieren kann. Am Ende zählt, ob das für die Menschen, bei denen man sich vorstellt, dass sie es brauchen, sofort nützlich ist

  • Ich habe sieben Jahre lang mit Qt C++ zu KDE als Open Source beigetragen. Dieser Ansatz erinnert mich an die .ui-Dateien von QtWidgets, also benutzerdefinierte UI-Dateien nach einem bestimmten XML-Schema. Später kam QML, aber das war für mich nicht intuitiv, also verlor ich das Interesse. Trotzdem halte ich XML für UI-Definitionen weiterhin für sinnvoll, und ich verstehe, warum es in großen Umgebungen immer noch verwendet wird

    • Es gibt immer noch Leute, die Qt nur mit C++ und .ui-Dateien verwenden. Sie sahen nie einen ausreichenden Grund, zu QML zu wechseln
    • Ich habe gehört, dass auch der Blizzard-Game-Launcher Qt nutzt, und ich fand die UI-Qualität von Blizzard-Software immer hervorragend. Mich würde interessieren, ob jemand noch andere empfehlenswerte Qt-Projekte kennt
    • wxWidgets oder glade-Dateien gehören in denselben Kontext

  • Meiner Meinung nach ist JUCE der beste GUI-Ansatz. Jedes UI-Element ist eine C++-Klasse, mit einer separaten Zeichenfunktion. Neue UI-Elemente lassen sich durch Komposition anderer Elemente zu weiteren Klassen aufbauen, und der Editor erzeugt den Quellcode automatisch. Für Buttons und Ähnliches gibt es große if…else-Bereiche für das Zeichnen je nach Zustand (hover, pressed, active, disabled usw.). Intern werden dünne Drawing-Libraries wie Metal/OpenGL/DirectX verwendet. So ein vollständig imperativer Ansatz fühlt sich erfrischend an. Man kann überall Breakpoints setzen und sofort sehen, mit welchen Parametern wie etwas aufgerufen wird. Es ist auch leicht, Zwischenergebnisse des Renderings nach imdraw auszugeben. Abgesehen vom Font-Antialiasing ist das Rendering auf fast allen Plattformen pixelgenau. Der hier vorgestellte XML-Ansatz ist dagegen genau diese Framework-abhängige Magie, die ich immer vermeiden will. Ich bin sicher, dass schon nach drei Updates das Layout Stück für Stück verrutscht. Der Nutzer kontrolliert das Layout nicht selbst, sondern ist der Gnade des Frameworks ausgeliefert. Electron hat diese Probleme etwas weniger, weil es auf älterer Technik wie CSS aufbaut, aber sonst gerät man bei der Layout-Kontrolle ständig in Schwierigkeiten

    • Ich habe JUCE nicht benutzt, aber manchmal vermisse ich die alte Qt-Zeit, als alles aus C++-Klassen bestand. Template-Sprachen sind zwar der Mainstream, aber eine Kombination aus Klassen und Objekten ist meiner Meinung nach viel leichter zu lesen. Der größte Vorteil von Templates scheint nur zu sein: „Ist dieses Modul korrekt unter seinem Parent gelandet?“
    • Es wäre schön, wenn jemand Erfahrungen mit JUCE und Accessibility teilen könnte
    • Ich kenne JUCE nicht gut, aber JUCE::Component wirkt vergleichbar mit DOM-/Canvas-Elementen und lässt sich daher dem Web-Plattform-Ansatz gegenüberstellen. XMLUI sollte eher mit deklarativen UI-Systemen auf JUCE verglichen werden (GUI Magic, JIVE, VITRO). Deklarative und imperative UI schließen sich nicht gegenseitig aus. Umgebungen, in denen beides verwendet wird, wie SwiftUI und UIKit, sind sehr verbreitet
    • Ich habe JUCE nicht benutzt, aber bei imperativen Ansätzen weiß man auch bei größerer Implementierung klar, was alles passiert, und behält dadurch leichter die Kontrolle. Deklarative Ansätze brauchen immer einen Escape Hatch, und dieser Escape Hatch ist entweder schwer direkt selbst zu bauen oder schwer zu durchdringen
    • Ich habe es sieben Jahre lang in der Audioentwicklung verwendet und nutze JUCE inzwischen einfach für alle plattformübergreifenden High-Performance-GUIs und allgemeinen Apps. Wenn man einmal eine halbwegs brauchbare JUCE->CI-Pipeline aufgebaut hat, eröffnen sich wirklich unbegrenzte Möglichkeiten. Aber manchmal stelle ich mir zum Spaß auch vor, den gesamten GUI-Code von JUCE in einem Lazarus-ähnlichen Frontend, etwa mit LUA, zu schreiben und daraus eine seltsame Lua-C++-Mischung zu machen

  • Schade, dass XSLT nicht erwähnt wurde. Ich finde, das ist ein wichtiger Punkt, um Menschen, die früher über das Stylen oder Transformieren von XML nachgedacht haben, klarzumachen, wie groß der heutige Fortschritt ist. Jon Udell hat auch über XSLT geschrieben Referenzlink, daher wirkt es fast so, als hätte er es diesmal absichtlich ausgelassen, aber ich verstehe nicht genau, warum

    • In den meisten Fällen, in denen ich XSLT im Einsatz gesehen habe, war es ein „komplexer Haarknäuel, den außer dem ursprünglichen Autor niemand anzufassen wagt“. Diese Technik neigt seltsamerweise dazu, entweder in eine Komplexitätsfalle zu geraten oder Menschen mit einer Vorliebe für Komplexität anzuziehen. Für das Ziel, auf das der OP hinauswill, halte ich es jedenfalls nicht für die passende Wahl
    • Historische Einordnung ist zwar nötig, aber das Ziel dieses Artikels ist nicht, in der Vergangenheit zu verharren, sondern nach vorn zu gehen. Es geht darum, dieses Tool tatsächlich zu benutzen und zu beurteilen, ob es für den UI-Bau produktiv ist
    • XSLT ist für diesen Artikel nicht besonders wichtig. Es geht im Kern darum, heutigen Lesern zu erklären, warum so ein Tool nützlich ist. XSLT ist historisch verwandt, aber ich glaube nicht, dass eine Erwähnung hier helfen würde, die Idee besser zu vermitteln
    • Seit ich SXML/SSAX von oleg kiselyov kennengelernt habe, habe ich XSLT komplett aufgegeben. SSAX ist der beste XML-Parser, den ich je benutzt habe
    • Meine erste XSLT-Erfahrung war sketchers.com Sketchy Skechers.com. Leider scheint es das heute nicht mehr zu verwenden

  • Ich baue in letzter Zeit etwas Ähnliches auf Basis von HTML, Web Components und Signals. Das Projekt heißt Heximal Heximal-Link. Ich denke, dass eine stark modularisierte und deklarative App oder Seite, die HTML um Ausdrücke, Templates, Reaktivität und eine Komponentenstruktur erweitert, eine hervorragende Grundlage sein kann. Viele dieser Erweiterungen zu HTML könnten auch standardisiert werden

    • Die Idee ist interessant, aber auf Mobilgeräten (Android+Firefox) wird die Seite nicht gut dargestellt
    • Die Seite ist schwer lesbar. Auch in der HN-App sehe ich die anderen Kommentare nicht gut, daher weiß ich nicht, ob andere dasselbe Problem haben. Bezieht sich auf Mobile Firefox
    • Auf Mobilgeräten scheint ein Teil des Textes abgeschnitten zu sein, und auch Zoomen hilft nicht. Nur als Hinweis
    • Ich denke, dass dieser Ansatz Mainstream werden könnte. Wie bei C++ ist die starke Rückwärtskompatibilität ein echter Vorteil

  • Ich denke, dass die uiSchema von RJSF als Präsentationsschicht zur Ergänzung der jsonSchema-Modelldefinition einen guten Weg gezeigt hat uiSchema-Referenzlink. Das war beeindruckend entworfen, und ich erinnere mich, überrascht gewesen zu sein, dass es sich nicht stärker verbreitet hat

  • Ich bin besonders gespannt auf die Teile, die man noch nicht sieht. Neben solider Technik scheint es auch klare Rücksicht auf WYSIWYG-Programmierer zu geben, also Entwickler, die UIs intuitiv zusammenbauen. Ich glaube, dass mir Visual Basic als Kind den Zugang zum Programmieren eröffnet hat. Ohne die komplizierten Pointer von C++ konnte man leicht und fast magisch vieles tun, und ich hoffe, dass sich diese Linie auch im Web-Programming als einsteigerfreundlicher Ansatz fortsetzt, mit sinnvollen praktischen Kompromissen ohne Einbußen bei Reaktivität und Geschmeidigkeit. Noch interessanter ist https://docs.xmlui.com/mcp. Werkzeuge wie Claude könnten dadurch weniger Tokens benötigen, um UX-/Dashboard-Code zu erzeugen, und kompakteren Code schreiben. Ich werde es ab heute direkt ausprobieren

    • Bitte berichte unbedingt von deinen Erfahrungen

  • XAML (besonders die eng begrenzte Silverlight-Version) war, wenn man es gut eingesetzt hat, ein wirklich angenehmes Werkzeug. Wenn man es aber auf die einfachste und offensichtlichste Weise nutzte, die zugleich ineffizient war, konnte es auch furchtbar sein. Vermutlich ist es wegen HTML5 oder wegen mangelnder Tools in Vergessenheit geraten. Gute Tools sollten auch Anfängern zum Erfolg verhelfen, und genau darin hatte XAML seine Schwächen