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.
To use XSLT effectively, you need an intuitive understanding of functional programming, a good grip on low-level HTML5/CSS details, and an engine that can run it quickly and correctly. The first of these is very rare, especially among business programmers. It is about as far away from the "Visual Basic-inspired" design goals of XMLUI as possible. Yes, both involve XML but that's where the similar ends.
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.
but like pretty much every such system, it is assumed that one knows react and so forth, and how to manage a deployment --- if they really want to be compared to VisualBasic, what is the equivalent to:
Probably I'm not the target audience, but if they had a "Minimal Working Example" of not just how to code, but also how to deploy an app (can it be run locally, say if I wanted something to keep track of my 3D printers and CNC machines?).
I spent a summer working on XAML UI's for an internship, and recently dove back in as a side project to update some Windows specific apps that rely on WinForms(https://github.com/hass-agent/hass.agent). XML UI's are fairly underrated imo.
Crazy, I just spent the past month designing an XML syntax for defining components. Weird coincidence.
One issue I see in their choices is the HStack approach. What’s great about flexbox in CSS is that the flex direction can change dynamically. Admittedly I haven’t read the full docs for XMLUI, but binding the direction to the markup likely means you can’t do that.
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.
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.
> The project we’re announcing today, XMLUI, brings the VB model to the modern web
But this ugly XML was the worst part of the old UI building experience, and you've made it worse by turning into a poor man's programming language without all the tooling proper languages have to support the poor user.
The good part was the immediate visual feedback in a GUI editor where you couldn't break anything by forgetting to close an XML tag! And you didn't even have to know all the types to type in because you had a visible list of UI elements you could pick from
I knew folks were missing the Delphi-VCL and VB-WinForm experience. In a way, Flutter with Dart feels a bit like an attempt at bridging this gap between React-style web programming and those drag and drop UI and data builders.
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 ).
Firefox is still XUL. Some parts, like "content pages" for Settings and other bits, have been replaced with more modern web stuff, but the core of Firefox, and all of its primary UI has always been and continues to be XUL.
Cool looking but it uses JSON? Weird choice to slap another data scheme on-top of your data scheme. I will stick with XSLT for the time being as it is pure XML.
> return {
name: stop.commonName,
zone: getProp('Zone'),
wifi: getProp('WiFi'),
toilets: getProp('Toilets'),
// A comma-separated list of line names that serve this stop
lines: stop.lines ? stop.lines.map(line => line.name).join(', ') : ''
};
});
}
Recently used a lot of HaxeUI for a game and it felt similar to this. A lot of components included out of the box that “just work” with some basic styling. And you can use CSS styling on top to further customize as needed. Works across a lot of different platforms as well.
> XMLUI wraps React and CSS and provides a suite of components that you compose with XML markup.
So this goes from XML → React → XML (HTML)?
Are there any studies actually showing XML is easier to write that a scripting language? In my experience, XML is equally hard to write while being more limited.
Oh this brings me back. My first real coding job in 2003 was with a startup building dynamic user interfaces with XML, rendered with XSLT from the underlying data.
It wasn't perfect, but it did feel correct, in the sense that a UX should be ultimately a pure function of data. Which is an idea that has never gone away.
This makes a lot of sense: with AIs generating a large amount of code, the challenge moves towards validation and testing. If you generate towards a higher level of abstraction, there's less code and less moving parts to be reviewed and validated. Think of it as low-code/DSLs for GenAI, still code, but with less technical details to review and test.
I applaud the idea of bringing back the Visual Basic model to the web.
Again I don't expect people under 45 to remember how easy it was to develop a user interface that reacted to user actions.
I just don't see the need to create a new language to do it.
Firefox had XUL.
And macromedia had Flex.
Flex was amazing it had an XML version and an OOP one.. that where two views of exactly the same language.
There was so much work done in the 80s and 90s on RAD — rapid application development — that was all thrown in the trash when the web hit.
20+ years later we’ve managed to finally build up the right combination of hacks to make the web a passable application platform but it still feels like you’re forcing it. Because you are. The web was not designed to be an app platform and it shows. Still.
Just like there's a massive community of Microsoft-adjacent technologists who still think C++ can do new and exciting things, there's a similar community who think XML components with declarative databindings are also going to make a comeback. I think (with some nostalgia and sadness) both of these ideas have been soundly thrashed in the marketplace of ideas.
121 comments
[ 3.4 ms ] story [ 92.5 ms ] threadWhy not web components?
And given Jon Udell has written about XSLT before[0], I'm sure this was an intentional decision. Not sure I understand it though.
0: https://www.xml.com/pub/a/2003/08/13/udell.html
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.
https://docs.xmlui.com/
>This site is an XMLUI™ app.
but like pretty much every such system, it is assumed that one knows react and so forth, and how to manage a deployment --- if they really want to be compared to VisualBasic, what is the equivalent to:
- buy VB - install VB - launch VB - develop app - test/compile - distribute .exe
Probably I'm not the target audience, but if they had a "Minimal Working Example" of not just how to code, but also how to deploy an app (can it be run locally, say if I wanted something to keep track of my 3D printers and CNC machines?).
One issue I see in their choices is the HStack approach. What’s great about flexbox in CSS is that the flex direction can change dynamically. Admittedly I haven’t read the full docs for XMLUI, but binding the direction to the markup likely means you can’t do that.
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.
But this ugly XML was the worst part of the old UI building experience, and you've made it worse by turning into a poor man's programming language without all the tooling proper languages have to support the poor user.
The good part was the immediate visual feedback in a GUI editor where you couldn't break anything by forgetting to close an XML tag! And you didn't even have to know all the types to type in because you had a visible list of UI elements you could pick from
> return { name: stop.commonName, zone: getProp('Zone'), wifi: getProp('WiFi'), toilets: getProp('Toilets'), // A comma-separated list of line names that serve this stop lines: stop.lines ? stop.lines.map(line => line.name).join(', ') : '' }; }); }
So this goes from XML → React → XML (HTML)?
Are there any studies actually showing XML is easier to write that a scripting language? In my experience, XML is equally hard to write while being more limited.
https://github.com/apache/royale-asjs/blob/develop/examples/...
https://github.com/gnustep/libs-renaissance
It wasn't perfect, but it did feel correct, in the sense that a UX should be ultimately a pure function of data. Which is an idea that has never gone away.
I just don't see the need to create a new language to do it.
Firefox had XUL. And macromedia had Flex.
Flex was amazing it had an XML version and an OOP one.. that where two views of exactly the same language.
20+ years later we’ve managed to finally build up the right combination of hacks to make the web a passable application platform but it still feels like you’re forcing it. Because you are. The web was not designed to be an app platform and it shows. Still.
But with another stack, I miss how good and easy it was to do great interfaces with Delphi in the good old time!