thisislife2
eyelidlessness
I don’t think this is a reinvention of XHTML. It’s definitely closer in spirit to XUL, but seems different enough still that I wouldn’t call it reinvention.
What seems particularly novel about this is that it’s taken the compositional approach of modern UI component libraries, and distilled it down to units of composition that can express a lot of behavior and logic declaratively. At least at a glance, that’s an impressive feat. Not necessarily in terms its technical capabilities (though that seems impressive too), but in terms of how it simplifies modeling interactive and data-driven UI.
j1elo
Speaking of expressing a UI declaratively, and composition with web components... as a former Qt/QML dev, I always felt like Web innovations of the last decade and a half are just rehashes of the inspirations and ideas behind what Qt's QML started offering already since 2010.
Things like CSS Grid, which was a great and celebrated new toy in 2017, but as foreigner from the Web world, I still remember how I read those news and didn't know if they were kidding.
To the standards body that may concern: just copy QML and standardize it already! :-)
junon
XUL felt magical when it came out. Was kind of sad when it got sunset or whatever happened to it. Felt like it could have been something great.
nailer
I read this article originally as being a look back at some tech that somebody had made 20 years ago, that had a lot of interesting ideas, rather than someone suggesting yet another XML based UI mechanism.
deanebarker
I thought of XUL right away too.
jeroenhd
XML UI is all over the place. I'm working with some legacy code using JSF with some extensions and it's pretty much everything described here. There's a Java server involved so it doesn't work with saved pages (but it automatically takes care of any backend calls, so unless you want an offline-first app that can be a benefit actually). I'm pretty sure ASP.NET, or whatever Microsoft calls it these days, works very similarly.
The frontend pendulum keeps swinging back and forth between serverside rendering and clientside rendering so maybe in a few years we can reinvent ASP/JSF and call it revolutionary again.
yoz-y
As a programmer I found that all no-or-less-code approaches break up sooner than one would expect.
Eventually I chosen to always use the programming language itself for data fetching, looping and leave the templating (lit html in my case) to just passing in the data structures.
altairprime
Eventually; but having something less complex than a general-purpose programming language to build prototypes and v1.0 products to test business-purpose fit is really important, too. Lets users have ideas and build them and try them out without having to engage a programmer. Hella valuable for workflow-process design, too. Best to have that one programmer on tap who can fix problems and recognize when it’s too unwieldy, of course.
criddell
I've also seen examples that are pushed way further than I thought possible. I'm thinking about some of the things people do in Excel.
djha-skin
In 2010 I was working for a student computer support shop. We had web developers building our own ticketing system. In those days, I was told that everything in the UI was just tables. It was the only way they could get enough control on UI elements before div tags became widely spread.
accrual
I still love using tables in 2025 for webapps designed to run on old browsers. It's easy to render data into them (it's just headers, rows, columns) and they automatically have a cool, functional look (IMO).
rzzzt
Also 1x1 pixel spacer GIFs.
efitz
All abstractions break down. The more the e difference in in expressivity or complexity between the abstraction and whatever it abstracts, the faster it breaks down.
djha-skin
I don't agree. Rather than breaking down, abstractions in UI have stabilized and centralized. Everyone uses React.
majewsky
React is not an abstraction, it's a framework. The core abstraction is "a component takes data only from its parent, and only passes data back up through provided callbacks". The exact spot where this abstraction breaks down is whenever you need to use a hook.
mnafees
I wrote Qt C++ for 7 years as an open source contributor to KDE. This reminds me of QtWidgets’ .ui files—custom XML files following a specific schema. Later, Qt introduced QML, which I personally found unintuitive, and over time I lost interest in Qt altogether. That said, I still think XML for UI definitions makes sense, and it’s understandable that some larger environments continue to use it.
hermitcrab
Some of us are still programming in Qt using just C++ and .ui files. Never bothered to switch to QML. I wasn't convinced there were enough advantages to make it worth the effort.
mrweasel
Using VB as a reference seems incorrect. Much of the appeal of Visual Basic, and Delphi, was the UI builder. Just click a button to create new project and you already had a window ready to go. Drag and drop in components, click buttons and what-not to wire up functionality. The barrier to entire was so incredibly low, having to edit XML files feels miles away from that ease of use.
That being said Visual Basic also create some absolutely terrible programs.
jeroenhd
Before Compose took over as the new direction for Android app development, the Android Studio designer IDE had a very VB6-style designer where you could drag and drop components, while the underlying UI files were all XML based. The callback generation wasn't as easy as with VB, and different phone sizes meant you had to deal with resizing (which VB applications usually just didn't bother with), but the experience was pretty good.
These days you've got Gambas for a free and open source VB, including the terrible language, but in my experience the looks are a bit off when you design on one desktop environment and run the application on another.
zamalek
XAML (at least the tighter-scoped Silverlight incarnation of it) was an absolute joy to use - if you used it correctly. It was an absolute monster if you used it in the most obvious (and incorrect) way. That's probably the reason other than HTML5 that it fell off: good tools steer novices into the pit of success, and XAML really didn't do that at all.
cheschire
No mention of XSLT? Feels like it would be highly relevant since many folks have not considered transforming or styling XML since those days, and would be interested in understanding the huge leap from that to this.
And given Jon Udell has written about XSLT before[0], I'm sure this was an intentional decision. Not sure I understand it though.
majewsky
Every time I've seen XSLT deployed, it was "that one hairball that no one besides the original author dares to touch". I'm not sure what it is about the technology, but it seems to either inevitably desolve into a complex mess or attract complexity fetishists. Either way, not something that would be an obvious choice for what OP is going for.
Quarrelsome
its because it demands to everything to be effectively processed in a one liner and is locked into its early version due to a licensing failure (I've yet to work in an org that pays up). So if you work in XSLT, then you're stuck in 1999.
IMHO the pattern to improve XSLT is to call out into more useful languages like javascript, which ofc somewhat defeats the point of using it, but it is a useful pattern to slowly move away from it, when encountering it in legacy projects.
danielvaughn
It’s probably irrelevant to an introduction. I think in this post the goal is to explain to a modern audience why something like this is beneficial. XSLT is part of the history here, but including it wouldn’t help sell the idea.
A4ET8a8uTh0_v2
I am hesitant. On the one hand, visualization as presented might drive some interest ( and maybe adoption ), but XLST would definitely be useful for a person that would actually suggest it as a solution toa nything. Not to search very far, I myself found recently I have to not just massage XML data, but also 'sell it' to my various bosses.
I guess what I am saying is: I see your point. I am also saying ( as I dig in a little deeper ) that XLST would likely be helpful.
danielvaughn
Oh yeah for sure, there should be somewhere on their site that does some kind of comparison to XSLT. Because as you pointed out, anyone who knows their history is going to wonder about it.
I’ve personally never written an application using XSLT, but I’ve researched it a bit. In my limited understanding, I believe XSLT was designed for transformations that happen on initial page load, or in a SSR context. For dynamic client interactions like the ones enabled by React, it wouldn’t suffice since it’s designed to recreate the entire document on every pass.
^ I could be very wrong about this, would love for someone more knowledgeable than me to chime in and correct me.
HellsMaddy
My first exposure to XSLT was sketchers.com: https://thedailywtf.com/articles/Sketchy-Skecherscom
Sadly it doesn't seem like they're using it anymore.
sheepscreek
The performance of available XSLT translation engines would be a big consideration for me, especially in a hot-reload context to support fast iterations.
homarp
if the target audience is 'citizen developer', aka Visual Basic (classic), I am not sure introducing XSLT is such a good idea.
leptons
>No mention of XSLT?
Nope, but they sure had to make 1/2 the content about "AI" (otherwise nobody would read it?).
sheepscreek
I am super excited about the stuff we cannot see - I have a feeling the quality of engineering here is going to be solid + backed by consideration for the WYSIWYG programmers. Developing in Visual Basic is how programming became accessible for me as a kid.
I could do stuff with ease that had seemed like magic and completely out of reach without C++ and complex pointer gymnastics. So thankful to the movement and I sincerely hope this project can bring that novice-first approach to web programming that does not compromise on responsiveness and smoothness, while making sane compromises, and doesn’t hold you back.
Even more exciting is this - https://docs.xmlui.com/mcp.
It can reduce the amount of code tools like Claude need to generate (fewer tokens need to be generated) for a usable high-functioning UX/dashboard. I am going to start using this today.
stillpointlab
This looks (at a glance) similar in many ways to Adobe's defunct MXML [1] which was the backbone of the Flex platform built on Flash.
Apparently this lives on in Apache Royale [2]
Using XML for an user interface description language is quite common, from XUL to XAML to JSX. In my experience, XML is well suited to this task.
Neywiny
Almost immediately is the reason I don't like using this stuff. A hardcoded default value. There are so many things these UI generators can almost do but don't, and a default value for a dynamic selection is often one of the trickier ones to get right.
fxtentacle
In my opinion, the best GUI approach is still JUCE. Every UI element is a C++ class with a drawing function. You create new UI elements by composing other elements to create another C++ class, for which the editor will auto-generate the source code. For buttons, you have a large if...else... area in the drawing function to handle different states like hover, pressed, active, disabled, etc. Behind the scenes, a thin drawing library will use Metal/OpenGL/DirectX as needed.
I find it refreshing that everything is imperative. You can put a breakpoint anywhere and you'll see when it gets called, with which parameters, by whom. You can also export intermediate rendering states to imdraw. Plus it's almost pixel-perfect (except for font antialiasing) on all platforms.
The XML variant being peddled here is, in my opinion, exactly what I usually try to avoid: framework-dependent magic. I'm 100% sure that 3 framework upgrades down the line, the layout will be slightly off. Because it was never you owning the layout, it was always you begging the framework for its consideration. The only thing that somewhat mitigates this issue with Electron is that it uses "old" technology. CSS isn't going to change much by itself anymore.
righthand
I haven’t tried JUCE yet but I miss the days where everything was a C++ class in Qt. Everyone clamours for a templating language but:
class MyButton extends QObject {
…
$button = new Button();
$button->color = “blue”;
$icon = new Svg();
$layout = new QtHorizontal();
$layout->push($icon, $button);
$this->layout = $layout;
…
}
This to me is much more readable than fiddling with stacked, embedded, and nested mustache/XML syntax split across files. Templating languages only really guarantee one unique thing about understanding the code: “Is my module embedded under the correct parent module?”
CharlesW
I've never heard of JUCE before, but from what I understand JUCE is more like the web platform itself (juce::Component is like DOM or canvas elements), while XMLUI is more appropriately compared to declarative UI systems built on top of JUCE (GUI Magic, JIVE, or VITRO).
Declarative and imperative UI approaches aren't mutually exclusive, and it's common for software to leverage both (e.g. SwiftUI and UIKit).
djha-skin
I was training a JavaScript developer to do DevOps. I described the C(++) GUI libraries to him, GTK and Qt. His reaction: "So you can't make the UI look exactly the way you want it to. You can't dial it in."
This will largely fail to gain market share just like PaperGUI[1] and Polymer[2] did (much to my chagrin). UX and web developers simply feel the need for more control over the UI.
However, I do find it interesting that there is enough interest in this trend that people keep recreating tools for it over the years. I wonder why.
1: https://google.github.io/paper-gui/
2: https://polymer-library.polymer-project.org/1.0/docs/about_1...
Seems like we keep reinventing the wheel - the previous version of of HTML, XHTML (eXtensible HyperText Markup Language) is a direct subset of XML. Also, related - Mozilla Firefox used to have something called XUL (XML User Interface Language - https://en.wikipedia.org/wiki/XUL - using which you could build complete desktop web applications with the Firefox / Gecko web engine (something that is now popular with the Chromium Embedded Framework). (After Mozilla abandoned the XUL codebase, it has been forked and is now maintained as the Unified XUL Platform (UXP) implementation - https://forum.palemoon.org/viewtopic.php?f=46&t=30840 ).