XMLUI

• XMLUI applique au web moderne le modèle de développement par composants de Visual Basic, permettant de développer des applications web sans connaissances en React ni en CSS
• XMLUI permet de combiner facilement divers composants via un balisage XML et prend en charge le data binding réactif, la gestion des thèmes et l’extension de schémas
• Grâce au Model Context Protocol (MCP), il est possible de collaborer avec l’IA afin d’améliorer l’efficacité du développement et la maintenabilité du code
• En simplifiant l’écosystème React complexe, XMLUI offre un environnement où même les non-spécialistes peuvent facilement développer des interfaces et des applications
• Le déploiement et l’extension sont simples, et même des développeurs peu familiers avec React ou CSS peuvent réaliser divers projets web et implémentations de CMS

---

Introduction et aperçu

Le projet XMLUI cherche à transposer dans l’environnement web l’approche intuitive d’assemblage de composants que l’on trouvait dans Visual Basic dans les années 1990. À l’époque, Visual Basic permettait même à des non-programmeurs professionnels de relier différents composants pour créer facilement des logiciels utiles. En revanche, le web n’a pas réussi à atteindre ce niveau d’ergonomie ni à reproduire un tel écosystème. XMLUI encapsule les composants React et le CSS, et permet de développer des applications web uniquement à l’aide d’un balisage XML.

Voici un exemple de code XMLUI en quelques lignes :

<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>

Avec une douzaine de lignes de XML, il est ainsi possible d’exprimer les opérations suivantes :

• Remplir automatiquement les options d’un Select via des appels API
• Utiliser la valeur du Select pour récupérer des données depuis une autre API
• Extraire uniquement certains champs du résultat API et les lier à un affichage sous forme de tableau

XMLUI présente des caractéristiques modernes, basées sur les composants et réactives (reactive), tout en permettant aux utilisateurs de développer et de maintenir leurs applications sans connaissance interne de React ou de CSS. C’est un facteur de différenciation majeur qui abaisse les barrières habituellement imposées par l’écosystème JavaScript.

Écosystème de composants

Hier et aujourd’hui

À l’époque de Visual Basic, il était facile d’intégrer dans une application divers éléments de base (composants) comme des graphiques, des fonctions réseau, l’accès aux données ou la lecture multimédia. Mais cet écosystème de composants très productif n’a jamais été entièrement transposé sur le web. Les composants basés sur React dominent aujourd’hui le web, mais ils exigent toujours des compétences de développeur spécialisé. XMLUI encapsule ces composants React pour les rendre faciles à utiliser par tous.

Composants personnalisés

XMLUI propose non seulement une large variété de composants intégrés, mais permet aussi de définir ses propres composants, puis de les combiner et de les réutiliser selon les besoins. Par exemple, on peut définir ainsi un composant TubeStops qui affiche des informations sur les stations du métro londonien :

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

TubeStops récupère des données via une API selon le nom de la ligne et les affiche sous forme de tableau. Le balisage réel reste très lisible, et dès qu’il dépasse les 100 lignes, il devient facile de le refactorer en composant pour simplifier la maintenance. Récemment, avec l’aide des LLM (grands modèles de langage), le refactoring des composants et la maintenance du code sont devenus encore plus flexibles.

Liaison réactive et développement déclaratif

Dans XMLUI, les données et les changements de valeur de l’interface sont automatiquement synchronisés (Reactive Data Binding). Par exemple, si la sélection d’un composant Select change, l’adresse API qui la référence (l’url du DataSource) est elle aussi automatiquement mise à jour, ce qui relance la récupération des nouvelles données. Cette approche est comparable aux références de cellules dans Excel.

Il faut s’habituer à un paradigme de développement déclaratif (Declarative) plutôt qu’impératif, mais une fois cette logique acquise, l’expérience de développement devient rapide et intuitive. Par exemple, pour implémenter une fonction de recherche, il est facile de construire une structure où les changements de valeur d’un champ de saisie alimentent les données en temps réel et se répercutent dans un tableau, sans bouton.

Système de thèmes

Au départ, l’intérêt pour le système de thèmes n’était pas très élevé, mais les fonctions de gestion des thèmes de XMLUI se révèlent très puissantes. Sans écrire de CSS, il est possible de gérer de manière cohérente, à l’aide de variables, les couleurs, arrière-plans, marges, polices, etc. de chaque composant. Par exemple, la couleur d’un bouton peut être définie différemment selon le contexte et l’état (hover, etc.).

Les thèmes permettent un contrôle fin avec des formes comme color-primary ou backgroundColor-Button, ce qui facilite la définition d’une palette de couleurs globale pour l’interface, applicable de manière générale ou ciblée.

Utilisation de scripts

XMLUI n’est pas entièrement déclaratif. Comme avec Visual Basic, il permet l’introduction partielle de scripts simples (principalement JavaScript), par exemple pour le traitement des réponses API (transformResult) ou le rendu conditionnel. Le niveau de difficulté reste accessible à des développeurs généralistes, sans exiger une expertise avancée.

Model Context Protocol (MCP) et collaboration avec l’IA

À la question « Maintenant que les LLM peuvent créer directement des applications React, à quoi sert encore XMLUI ? », l’auteur met en avant la valeur de XMLUI du point de vue de l’accessibilité du code, de la maintenabilité et de la collaboration.

Le MCP (Model Context Protocol) fournit un serveur permettant à des agents tels que les LLM de rechercher, comprendre et citer le code, la documentation et les exemples XMLUI. Cela permet à l’IA et aux développeurs de communiquer dans le même espace sémantique et de coordonner progressivement la génération automatique et la modification du code.

• Exemple : avancer dans le développement en interrogeant immédiatement un LLM sur l’utilisation d’une fonction, des exemples, la documentation ou des cas d’usage

Des recommandations sont également fournies pour bien collaborer avec les LLM. Par exemple : discuter avant toute proposition de code, n’utiliser que des exemples documentés, ou limiter le styling inutile. Le site de documentation propose aussi une section « How To » et une intégration MCP, afin que l’IA puisse y accéder facilement.

Gestion de contenu et usage CMS

Avec XMLUI, il est aussi facile de construire des sites web et des CMS, et d’effectuer les modifications ou la maintenance courantes sans connaissances de React ni de Next.js. En pratique, le site officiel de XMLUI, les démos et la documentation sont tous créés et maintenus avec XMLUI.

Il est pratique de pouvoir fournir dans un même document le code, les explications et une démo en temps réel.

Extensibilité

XMLUI encapsule par défaut divers composants React, mais il est aussi facile d’encapsuler de nouveaux composants externes. Par exemple, l’éditeur de documents avancé Tiptap a pu être facilement encapsulé dans XMLUI sous la forme de TableEditor. Concrètement, les parties difficiles de l’édition Markdown, comme la création de tableaux, peuvent ainsi être résolues facilement via un éditeur visuel.

Ainsi, alors qu’autrefois les rôles entre développeurs de composants et développeurs de solutions étaient clairement séparés, XMLUI permet désormais aussi aux développeurs généralistes d’étendre et de combiner eux-mêmes des composants d’interface utiles.

Déploiement

Le déploiement d’une application XMLUI est très simple.

• Configuration minimale : seuls Main.xmlui, index.html et le fichier JS de XMLUI sont nécessaires
• N’importe quel serveur web statique peut être utilisé, et l’application peut fonctionner directement depuis un bucket AWS S3
• Un environnement serveur complexe n’est pas indispensable, même s’il reste possible d’ajouter un serveur local, un proxy CORS, etc. si nécessaire

Le développement web pour tous

Le créateur de XMLUI, Gent Hito, s’est consacré chez /n software, CData et ailleurs à réduire les barrières d’entrée des environnements de développement.

• /n software : facilité d’utilisation des composants réseau
• CData : simplification de l’accès aux données
• XMLUI : simplification du développement d’interfaces

Au cours des vingt dernières années, le développement d’interfaces web s’est progressivement spécialisé et complexifié, mais XMLUI a été conçu pour permettre même à des développeurs non spécialistes de créer facilement leurs propres interfaces et applications. En pratique, il peut être appliqué directement à divers exemples comme des interfaces de tableau de bord liées à CoreSSH.

Il est vivement recommandé à tous les développeurs qui recherchent un environnement plus simple pour créer des applications web, en particulier les créateurs de solutions non spécialistes, les développeurs juniors et les développeurs à dominante back-end.

[GN⁺]

Avis Hacker News

• Jon est dans le métier depuis longtemps, et j’en suis fan. C’est quelqu’un d’expérimenté, avec beaucoup de vécu, et cela vaut la peine d’écouter ce qu’il a à dire. J’aime beaucoup les web components, mais si React domine, c’est à mon avis parce que l’environnement reste difficile d’accès pour les développeurs qui savaient bien tirer parti des anciens composants Visual Basic. C’est le point le plus important de cet article. Les explications techniques comptent aussi, mais il met surtout le doigt sur la raison profonde pour laquelle ce genre de tentative est nécessaire. Reste à voir si XMLUI fournira un niveau d’abstraction adapté à ces développeurs. En tout cas, voir ce type de défi émerger est déjà réjouissant

  • Le code actuel ne fonctionne que dans les navigateurs JS evergreen. Cela rappelle un peu l’époque où l’ancien VB ne marchait correctement que sous Windows avec certains DLL installés

• Vers 2014, Polymer avait déjà tenté quelque chose de similaire. Par exemple, les requêtes réseau étaient implémentées via des composants comme <iron-ajax> lien vers iron-ajax. Il y a aussi eu l’époque où Adobe Flex était très en vogue, et aujourd’hui cela subsiste sous Apache Royale lien Apache Royale. Chez Microsoft, il y a aussi eu XAML, NetUI et FlexUI, et même l’interface d’Office 2007 a été construite ainsi. En théorie, tout cela était élégant, mais dans la pratique, j’ai eu l’impression que ces abstractions à base de balisage étaient moins efficaces pour les débutants qu’une approche orientée code comme JSX

  • Il y avait aussi Coldfusion (frissons de nostalgie)

• J’ai à la fois l’impression que « nous sommes encore en train de réinventer HTML » et le sentiment que « ça pourrait m’être utile tout de suite ». L’être humain est par nature contradictoire

  • Merci de m’avoir fait découvrir le poète Walt Whitman et son œuvre. « Est-ce que je me contredis ? Alors oui, je me contredis volontiers »
  • Formulation vraiment parlante. Au final, la vraie question est de savoir si cela est immédiatement utile pour les personnes dont tu imagines qu’elles en ont besoin, comme toi

• J’ai contribué à KDE en open source pendant 7 ans avec Qt C++. Cette approche me fait penser aux fichiers .ui de QtWidgets, c’est-à-dire à des fichiers UI personnalisés suivant un schéma XML spécifique. Plus tard, QML est arrivé, mais je l’ai trouvé peu intuitif et j’ai perdu l’intérêt. Cela dit, je pense toujours qu’utiliser XML pour définir une UI a du sens, et je comprends pourquoi cela reste employé à grande échelle

  • Il y a encore des gens qui utilisent Qt uniquement avec C++ et des fichiers .ui. Ils n’ont pas estimé avoir de raison suffisante pour migrer vers QML
  • J’ai entendu dire que le launcher de jeux Blizzard utilisait aussi QT, et j’ai toujours trouvé que le niveau de finition des interfaces chez Blizzard était excellent. Je serais curieux de connaître d’autres projets Qt recommandables
  • Les fichiers wxWidgets ou glade relèvent du même esprit

• À mon avis, la meilleure approche GUI, c’est JUCE. Tous les éléments d’interface sont des classes C++, avec des fonctions de dessin séparées. On peut créer de nouveaux éléments en composant d’autres éléments dans une nouvelle classe, et l’éditeur génère automatiquement le code source. Pour les boutons, etc., il y a de grands blocs if…else pour gérer le rendu selon l’état (hover, pressed, active, disabled, etc.). En interne, cela repose sur des bibliothèques de dessin légères comme Metal/OpenGL/DirectX. Je trouve cette approche entièrement impérative rafraîchissante. On peut poser des breakpoints partout et voir immédiatement comment quelque chose est appelé et avec quels paramètres. Il est aussi facile d’exporter un état intermédiaire du rendu vers imdraw. À part l’anticrénelage des polices, le rendu est presque pixel-perfect sur toutes les plateformes. En revanche, l’approche XML présentée ici ressemble au genre de magie dépendante du framework que j’essaie toujours d’éviter. Je suis à peu près certain qu’après trois mises à jour, le layout commencera à se décaler petit à petit. Ce n’est pas l’utilisateur qui contrôle directement la mise en page, il dépend de la bonne volonté du framework. Electron souffre un peu moins de ce problème parce qu’il repose sur des technologies anciennes comme CSS, mais sinon on finit toujours par se battre avec le contrôle du layout

  • Je n’ai pas utilisé JUCE, mais l’époque où tout, dans Qt, était représenté par des classes C++ me manque parfois. Les langages de templates sont à la mode, mais je trouve les compositions de classes et d’objets bien plus lisibles. Le principal avantage des templates semble être de répondre à la question « est-ce que ce module est bien imbriqué sous son parent ? »
  • J’aimerais bien que quelqu’un partage un retour d’expérience sur JUICE et l’accessibilité
  • Je ne connais pas très bien JUCE, mais JUCE::Component semble comparable aux éléments DOM/canvas, donc on pourrait le rapprocher de la plateforme web. XMLUI devrait plutôt être comparé aux systèmes d’UI déclarative au-dessus de JUCE (GUI Magic, JIVE, VITRO). Déclaratif et impératif ne sont pas incompatibles. Les environnements où les deux coexistent, comme SwiftUI et UIKit, sont courants
  • Je n’ai pas utilisé JUCE non plus, mais l’impératif est facile à contrôler parce qu’on sait clairement tout ce qui se passe, même quand l’implémentation grossit. Le déclaratif a toujours besoin d’une porte de sortie, et cette porte est soit à construire soi-même, soit difficile à franchir
  • Je l’ai utilisé pendant 7 ans dans le développement audio, et aujourd’hui j’utilise simplement JUCE pour toutes les GUI cross-platform hautes performances et les applications généralistes. Une fois qu’on a mis en place une pipeline JUCE -> CI à peu près exploitable, les possibilités deviennent vraiment infinies. Cela dit, j’imagine parfois que ce serait amusant d’écrire tout le code GUI de JUCE avec un frontend façon Lazarus, par exemple en LUA, puis de le mélanger à du C++ pour créer une monstruosité Lua-C++

• Je trouve dommage que XSLT n’ait pas été mentionné. Pour ceux qui ont déjà réfléchi à la mise en forme et à la transformation de XML, c’est un élément important pour montrer à quel point les évolutions actuelles représentent un grand saut. Vu que Jon Udell a aussi écrit sur XSLT lien de référence, je me demande s’il l’a volontairement écarté cette fois, sans bien comprendre pourquoi

  • Sur le terrain, XSLT a surtout donné des « pelotes de cheveux complexes que personne n’ose toucher à part l’auteur d’origine ». Cette techno a une étrange tendance à tomber dans le piège de la complexité ou à attirer les fétichistes de la complexité. Quoi qu’il en soit, je ne pense pas que ce soit un bon choix pour l’objectif visé par l’OP
  • La référence historique a son intérêt, mais ici le but n’est pas de se concentrer sur le passé, c’est d’aller de l’avant. L’objectif est d’essayer cet outil directement et d’évaluer s’il est productif pour construire des UI
  • XSLT n’est pas si important dans cet article. L’essentiel est d’expliquer aux lecteurs d’aujourd’hui pourquoi ce type d’outil peut être utile. XSLT a un lien historique, mais le mentionner ici n’aiderait sans doute pas à faire passer l’idée
  • Depuis que j’ai découvert SXML/SSAX d’oleh kiselyov, j’ai complètement abandonné XSLT. SSAX est le meilleur parseur XML que j’aie utilisé
  • Ma première expérience de XSLT, c’était sketchers.com Sketchy Skechers.com. Malheureusement, il semble qu’ils ne l’utilisent plus aujourd’hui

• En ce moment, je construis quelque chose de similaire à base de HTML, web components et signals. C’est un projet appelé Heximal lien Heximal. Je pense qu’ajouter à HTML des expressions, des templates, de la réactivité et une structure de composants peut fournir une excellente base pour créer des applications ou des pages très modulaires et déclaratives. Beaucoup de ces ajouts à HTML pourraient aussi être standardisés

  • L’idée est intéressante, mais sur mobile (Android + Firefox), le site s’affiche mal
  • Le site est difficile à lire. Dans l’app HN non plus je ne vois pas bien les autres commentaires, donc je ne sais pas si d’autres ont le même problème. Je suis sur Firefox mobile
  • Sur mobile, une partie du texte semble coupée, et même en zoomant cela ne se corrige pas. À prendre en compte
  • Je pense que cette approche pourrait devenir dominante. Comme pour C++, sa grande force est la rétrocompatibilité

• Je pense que le uiSchema de RJSF a montré une bonne direction comme couche de présentation complémentaire au modèle défini par jsonSchema lien uiSchema Reference. Le design m’avait marqué, et j’avais été surpris que cela ne se diffuse pas davantage

• Ce qui m’enthousiasme particulièrement, c’est ce qu’on ne voit pas encore. Au-delà de la solidité technique, j’ai l’impression qu’il y a une vraie attention portée aux programmeurs WYSIWYG, c’est-à-dire à ceux qui construisent des interfaces de façon intuitive. Je pense que c’est grâce à Visual Basic que j’ai pu entrer dans la programmation quand j’étais enfant. On pouvait faire beaucoup de choses facilement, presque magiquement, sans la complexité des pointeurs en C++, et j’aimerais que cette logique se prolonge dans la programmation web avec une approche qui mette les débutants au premier plan, sans compromettre la réactivité ni la fluidité, tout en trouvant les bons compromis réalistes. Encore plus intéressant : https://docs.xmlui.com/mcp. Des outils comme Claude pourraient réduire le nombre de tokens nécessaires pour générer du code UX/de tableau de bord, et produire un code plus concis. Je vais l’essayer dès aujourd’hui

  • N’hésite surtout pas à revenir partager ton retour d’expérience

• XAML, surtout dans sa version Silverlight plus limitée, pouvait être vraiment agréable quand il était bien utilisé. En revanche, dès qu’on l’employait de la manière la plus simple et la plus évidente — et en même temps la plus inefficace — cela devenait horrible. C’est probablement quelque chose qui a été oublié à cause de HTML5 ou du manque d’outillage. Un bon outil devrait aider même les débutants à réussir, et XAML était insuffisant sur ce point