Jon has been around for a long time, and I've been a long-time fan. He's a bit of an elder: he's seen a lot of things, and he's worth listening to.
> I’m a fan of web components but it’s the React flavor that dominate and they are not accessible to the kind of developer who could productively use Visual Basic components back in the day.
I think this is the most important statement in the piece. The rest of the post explains the technical details, but this explains _why_ this exists. This is a bold statement, but I don't think he's wrong.
Now, is XMLUI the _right_ set of abstractions to help these developers? We'll have to wait an see. But I love to see the attempt!
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.
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.
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.
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.
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.
I'm trying to build something very much like this, except that it's based on standard HTML, web components, and signals - it's called Heximal: https://heximal.dev/
I think HTML with expressions, templates, reactivity, and components is a really great substrate for these very modular, declarative apps and pages. And a lot of the things added on top of HTML could conceivably be standardized.
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?).
If this doesn’t use a compiler, the ”when” feature looks like it will require 'unsafe-eval' and potentially 'unsafe-inline' to be enabled in content security policy, which will disable browser XSS protections. Not optimal for an easy-to-use component system intended for display of remote data.
Edit: I don’t see a CSP on the dogfooded homepage so I would assume this is an issue.
When it started talking about mimicking the experience of Visual Basic, I was excited, because I have fond memories of that (and Borland Delphi after it) and its ability to let me design a window/dialog layout in a WYSIWYG manner,
But then it showed XML code (which of course I saw coming, given the title) and I was immediately reminded of WPF with its XAML, which was a nightmare for me. The excitement was instantly replaced with great disappointment :(
I'll readily admit that I haven't tried it so I don't know how much like WPF/XAML it'll be, but it's pretty clear it won't be like Visual Basic or Delphi.
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.
The article mentions XML, but the true revolution is JSX itself, which lets you describe any piece of logic as a React element. This opens the possibility to create DSL for everything, just like in Python.
> 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
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.
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.
So instead of ’const tubeStations = useDatasource()’ we now type ’<DataSource id=”tubeStations” />’ and anything beyond this basic example is left as exercise for the reader.
Doesn’t seem like a big improvement? In fact the opposite. Sure, React’s stateful hooks mixing in a semi-declarative mode of programming in otherwise imperative code isn’t exactly intuitive, but the flexibility and familiarity you get from having full JavaScript at your fingertips is worth everything. Hands up anyone who want to learn how to make a for-loop with filter+map in xml syntax. Didn’t think so.
If you want to fix react what you should do instead is keep jsx and give stateful hooks a dedicated section that can’t be mixed up in rendering code.
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.
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.
I confess I have failed multiple times to build simple web pages (like a blog and homepage, admittedly after not too much effort), while I've made multiple fairly complex javascript animations using canvas and p5.js library. And I've made a few websites as a kid! (I'm not sure using free WYSIWYG or HTML directly).
So appreciate a lot new developments in the really-easy-to-use open source and text tools that also enable more involved use case!
Admittedly I also have not tried to learn React or other frameworks (most times I got stuck on backend basics).
It would be awesome if (almost) anyone could easily type out a website using simple and open source tools (specially with a little more involved functionality than just static content, or more free looks), and it just worked (with minimal coding required for the backend -- that's what's great about plain html imo, it's just a few files that contain your whole website). I mean, meanwhile it's great that something like hosted blogs exist of course.
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.
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.
In 2004, we used this approach to drive QT to dynamically generate a UI for a (in retrospect) needlessly complex software installer. InstallShield use to make these horrifically difficult to maintain installers, combined with how visuals were stored in the MSI files. So, we then interpreted the XML back down to InstallShield dialogs, widgets, and their components. We extended the same to running pure QT on other platforms (Windows, at the time was problematic).
Using this approach (pre QT designer working this way), we were able to give the UX team the ability to move widget around in the installer, colour things, add images.. it actually worked incredibly well, to everyone's shock. I still remember the nightmare of dynamic signal and slot lookups.
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.
The browser platform with HTML/CSS is fundamently legacy over legacy and broken for most application styles ( not general pages ), and incurs insane development costs for even simple things ( been there done that for close to 17 years )
The current best option IMO is: Open Full Browser window size canvas (with webgl, webgpu backend graphics ) and draw everyhing yourself ( meaning with something else than the browser layout engine, lots of options available, Flutter, Avalonia etc... ) and deploy with your favourite programming language through WASM.
In fact a next generation browser should bascially be this, with the legacy browser functionality implemented as a WASM module that draws to this single canvas... The browser would become small and much easiert to secure ( only input, audio and general WASI style apis missing and to secure )
I dunno. I pretty much skipped over XAML, which is very similar for .NET desktop UI. Maybe this sticks better because it’s not MS? I certainly think current frameworks tend to be too much cruft for LOB/forms-on-data apps. But a special xml seems wrong to me.
> 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.
Web standards are so powerful today with all the browser native form components etc, so I think one should just exploit that one and use XSLT (https://caniuse.com/?search=xslt) if you want to create an own "UI markup language". It'll render straight to everything that your browser supports, which is a lot. Then just use CSS to style it however you wish if you want to. What's nice about this approach is also that you can create a true domain-specific markup language, which will always be more clean and compact than a generic one.
> to me this feels like an alternative to the JavaScript industrial complex that ticks all the right boxes
The goal is admirable, but the execution and implementation is, in a word, absurd. From the XMLUI website:
> XMLUI provides the glue that binds the React ecosystem into a declarative model.
This negates the raison d'être of React, which is to bring the development style of immediate mode UIs to the browser—that's the fundamental driving factor behind the creation of React. Components are incidental. (Web browsers in fact do components just fine, with native support for custom elements and shadow DOM—which, along with flexbox, is a descendant of XUL, the other 90s-era technology that worked the way the XMLUI authors lament isn't around.)
The purpose of React was to bring the development style of "immediate mode" UIs to the browser[1], which for better or worse inherently has a "retained" model of the UI that developers writing in-browser apps would have to deal with. So now with XMLUI, you have React trying to paper over the fundamental nature of the DOM to make it feel like it's immediate mode instead (and all the fakery involved with that), and you have XMLUI choosing to build upon React and do these retained objects instead—aligning with how the browser actually does things underneath React!
The "The Backstory" section on the XMLUI landing page is worth a look and really drives the point home (along with Jon's admission in his blog post that he's never been a React developer):
> It began with a relatively small effort to add web-based admin interfaces to some of the company’s products. This resulted in the core engineering team — experienced backend developers whose interactions with UI technology were limited to old-school battleship-gray Visual Basic, Delphi, or .Net/Winform — being surprised by the complexity of modern web development.¶
Calls for simplicity and easy/intuitive tool support were met mostly with blank stares from the React guys on the other side – and the designer, UX guy, and JavaScript folks on the server side of things.¶
But the /n software team refused to take no for an answer, and more than two years of work from a team of Javascript/React wizards resulted in the new semantic layer that is XMLUI.
"Simplicity" this is not. Ditch React. You don't need it. You're actively working against it. (And worse, it looks you've put yourself at the whims of hired "experts" who exemplify the stereotype of the React-only programmer who never learned the fundamentals, and in this case can't even spot that you're asking them to undo React.)
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.
Eventually people will separate interface from implementation, not unlike the now-disparaged OO programming paradigm. But not yet. This article discusses something well-known among insiders -- interface schemes frequently expire along with their hosting language, because they're not a recognizable, separate entity.
After AI entirely takes over programming, interfaces will become more portable and platform-agnostic than they are now.
"AI, write me a word processor."
"What language?"
"I don't care ... do you?"
Alternative reply: "COBOL, just because I know you can."
As humans augmented with agents write more code, solutions that require less context shifting to get stuff done will win.
A common web stack may include API handlers, OpenAPI spec, generated TypeScript definitions, generated TypeScript client, React logic and effects code, TSX code, HTML, and CSS.
This generally needs filesystem watchers, code generators, transpilers, compilers to get stuff done.
Something that can go from a backend handlers straight to terse markup for reactive UI would be a massive simplification to all this, and a big productivity boost.
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.
Close but no cigar, if you're trying to achieve VB like hunt and peck productivity then XML doesn't cut it any more now than it has in the last 30 years or so.
Blazor is pretty productive if you're looking for a mature component based XML (Razor) syntax but again, there is no Visual design element to throw thing together.
I've downloaded and printed the whole manual for action script 3 when I was an artist (I've always dabbled in programming), apparently you could create pretty robust web apps with XML. Never had the time to create one myself and as3 was dead soon after that, I think jQuery killed it.
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.
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.
It’s a stretch to believe that VB users are going to happily use XML for UI.
VB is drag and drop. Put a button here, some label there. Double click here to add an event. Write a tiny bit of code in an editor that has autocomplete and boom.
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.
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 may be wrong because my domain knowledge is limited, but it seems to me this should marketed to novices and non-programmers instead of your typical hn crowd. As a novice frontend "builder", it sounds this was made for people like me, but not this blog post - give me examples, whys and limits - tell me I won't even need to learn how React works.
To develop an app, today, one needs to know 3 programming languages: HTML + Javascript + CSS. XMLUI would downsize this requirement to 2, so a little better IMHO.
Surely, this has been tried many times - Microsoft with XAML for WPF, Silverlight (Flash killer), Forms, Adobe Flex (MXML), Google XML for Android, XUL etc. etc. All seem to suffer from the problems that Visual Basic did not have and becomes obvious when you go beyond some simple forms. OP seems to a long timer in this space so surprising shrug
* difficulty in mapping complex UI layouts to XML (VB was quite literally WYSIWYG and mind-blowing for its time)
* Verbose to specify (esp. multilevel nesting, complex navigation etc..)
* Cannot make sense of the XML content vs all the nested tags
* Keep switching between how the UI looks and the XML
... all generally point to the difficulty of separation of configuration and behavior.
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 ).
XMLUI
(blog.jonudell.net)615 points by mpweiher 20 July 2025 | 332 comments
Comments
There was also Adobe Flex of the similar era that exists these days as Apache Royale: https://apache.github.io/royale-docs/features/mxml
There was also XAML and inside Microsoft they made NetUI and FlexUI to make Office 2007+ too.
It all seems great on paper, but in practice the markup abstraction turned out to be worse than code first solutions like JSX even for novices.
> I’m a fan of web components but it’s the React flavor that dominate and they are not accessible to the kind of developer who could productively use Visual Basic components back in the day.
I think this is the most important statement in the piece. The rest of the post explains the technical details, but this explains _why_ this exists. This is a bold statement, but I don't think he's wrong.
Now, is XMLUI the _right_ set of abstractions to help these developers? We'll have to wait an see. But I love to see the attempt!
To be human is to be multitudes.
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.
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
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.
1. https://en.wikipedia.org/wiki/MXML
2. https://apache.github.io/royale-docs/features/mxml
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.
I think HTML with expressions, templates, reactivity, and components is a really great substrate for these very modular, declarative apps and pages. And a lot of the things added on top of HTML could conceivably be standardized.
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?).
Edit: I don’t see a CSP on the dogfooded homepage so I would assume this is an issue.
But then it showed XML code (which of course I saw coming, given the title) and I was immediately reminded of WPF with its XAML, which was a nightmare for me. The excitement was instantly replaced with great disappointment :(
I'll readily admit that I haven't tried it so I don't know how much like WPF/XAML it'll be, but it's pretty clear it won't be like Visual Basic or Delphi.
It's been a while since I played with it but I remember thinking it was well thought out & being surprised that it wasn't more widely adopted.
[0]: https://rjsf-team.github.io/react-jsonschema-form/docs/api-r...
That being said Visual Basic also create some absolutely terrible programs.
Also, the Docs link to home.xmlui.com and don't resolve
[1]: https://github.com/marmelab/react-admin [2]: https://github.com/refinedev/refine
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
see https://www-archive.mozilla.org/xpfe/xui.html
> 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(', ') : '' }; }); }
Doesn’t seem like a big improvement? In fact the opposite. Sure, React’s stateful hooks mixing in a semi-declarative mode of programming in otherwise imperative code isn’t exactly intuitive, but the flexibility and familiarity you get from having full JavaScript at your fingertips is worth everything. Hands up anyone who want to learn how to make a for-loop with filter+map in xml syntax. Didn’t think so.
If you want to fix react what you should do instead is keep jsx and give stateful hooks a dedicated section that can’t be mixed up in rendering code.
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...
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.
Example:
So appreciate a lot new developments in the really-easy-to-use open source and text tools that also enable more involved use case!
Admittedly I also have not tried to learn React or other frameworks (most times I got stuck on backend basics).
It would be awesome if (almost) anyone could easily type out a website using simple and open source tools (specially with a little more involved functionality than just static content, or more free looks), and it just worked (with minimal coding required for the backend -- that's what's great about plain html imo, it's just a few files that contain your whole website). I mean, meanwhile it's great that something like hosted blogs exist of course.
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.
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.
https://github.com/apache/royale-asjs/blob/develop/examples/...
Using this approach (pre QT designer working this way), we were able to give the UX team the ability to move widget around in the installer, colour things, add images.. it actually worked incredibly well, to everyone's shock. I still remember the nightmare of dynamic signal and slot lookups.
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.
The current best option IMO is: Open Full Browser window size canvas (with webgl, webgpu backend graphics ) and draw everyhing yourself ( meaning with something else than the browser layout engine, lots of options available, Flutter, Avalonia etc... ) and deploy with your favourite programming language through WASM.
In fact a next generation browser should bascially be this, with the legacy browser functionality implemented as a WASM module that draws to this single canvas... The browser would become small and much easiert to secure ( only input, audio and general WASI style apis missing and to secure )
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.
It wasn’t also easy to make a living fixing bad VB apps (or going back to Delphi).
I’m not saying that components are a bad idea, but the 90s implementations didn’t quite realize the dream.
The goal is admirable, but the execution and implementation is, in a word, absurd. From the XMLUI website:
> XMLUI provides the glue that binds the React ecosystem into a declarative model.
This negates the raison d'être of React, which is to bring the development style of immediate mode UIs to the browser—that's the fundamental driving factor behind the creation of React. Components are incidental. (Web browsers in fact do components just fine, with native support for custom elements and shadow DOM—which, along with flexbox, is a descendant of XUL, the other 90s-era technology that worked the way the XMLUI authors lament isn't around.)
The purpose of React was to bring the development style of "immediate mode" UIs to the browser[1], which for better or worse inherently has a "retained" model of the UI that developers writing in-browser apps would have to deal with. So now with XMLUI, you have React trying to paper over the fundamental nature of the DOM to make it feel like it's immediate mode instead (and all the fakery involved with that), and you have XMLUI choosing to build upon React and do these retained objects instead—aligning with how the browser actually does things underneath React!
The "The Backstory" section on the XMLUI landing page is worth a look and really drives the point home (along with Jon's admission in his blog post that he's never been a React developer):
> It began with a relatively small effort to add web-based admin interfaces to some of the company’s products. This resulted in the core engineering team — experienced backend developers whose interactions with UI technology were limited to old-school battleship-gray Visual Basic, Delphi, or .Net/Winform — being surprised by the complexity of modern web development.¶ Calls for simplicity and easy/intuitive tool support were met mostly with blank stares from the React guys on the other side – and the designer, UX guy, and JavaScript folks on the server side of things.¶ But the /n software team refused to take no for an answer, and more than two years of work from a team of Javascript/React wizards resulted in the new semantic layer that is XMLUI.
"Simplicity" this is not. Ditch React. You don't need it. You're actively working against it. (And worse, it looks you've put yourself at the whims of hired "experts" who exemplify the stereotype of the React-only programmer who never learned the fundamentals, and in this case can't even spot that you're asking them to undo React.)
1. <https://www.youtube.com/watch?v=8ZlN07IvoPI&t=2131s>
After AI entirely takes over programming, interfaces will become more portable and platform-agnostic than they are now.
"AI, write me a word processor."
"What language?"
"I don't care ... do you?"
Alternative reply: "COBOL, just because I know you can."
As humans augmented with agents write more code, solutions that require less context shifting to get stuff done will win.
A common web stack may include API handlers, OpenAPI spec, generated TypeScript definitions, generated TypeScript client, React logic and effects code, TSX code, HTML, and CSS.
This generally needs filesystem watchers, code generators, transpilers, compilers to get stuff done.
Something that can go from a backend handlers straight to terse markup for reactive UI would be a massive simplification to all this, and a big productivity boost.
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.
Blazor is pretty productive if you're looking for a mature component based XML (Razor) syntax but again, there is no Visual design element to throw thing together.
XUL from Mozilla, Silverlight and WPF from Microsoft, Glade for GTK and many others.
You define the widgets using markup then implement the behavior in some other language.
Then came Electron, Tauri and others that piggybacked on HTML and CSS.
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.
[1] https://primereact.org/datatable/
VB is drag and drop. Put a button here, some label there. Double click here to add an event. Write a tiny bit of code in an editor that has autocomplete and boom.
https://xmlui.com
https://github.com/xmlui-org/xmlui
1. https://datasette.io/
https://pasteboard.co/Rpp35synt4CW.png
Am I missing a joke, or has something broken?
https://github.com/gnustep/libs-renaissance
Do folks understand why?
- Components for data fetching
- IDs for bindings
Two seemingly simple details that lead to less code.
* difficulty in mapping complex UI layouts to XML (VB was quite literally WYSIWYG and mind-blowing for its time)
* Verbose to specify (esp. multilevel nesting, complex navigation etc..)
* Cannot make sense of the XML content vs all the nested tags
* Keep switching between how the UI looks and the XML
... all generally point to the difficulty of separation of configuration and behavior.
So his UI has 2 widgets: text input field and scrolled list. /s
Why not web components?
But with another stack, I miss how good and easy it was to do great interfaces with Delphi in the good old time!