At my last job, when I first started there (this was circa around 2006), we actually used a Firefox browser plugin with a custom XUL interface to enable our writers to write content faster. It has a very complex UI, as complex as anything that could be found in the browser itself. Thousands of lines of XML and JS.
XUL was deeply unpleasant to use and maintain, and I do not miss it at all. We eventually ended up rewriting it as a standard webapp. It made the writers a bit slower, but they adapted eventually.
It's used for things like pop-up menus, (i.e. things that can't be done with HTML) and was recently used in some obscure parts of the UI e.g. certificate viewer (however I'm not even sure that's still XUL any more)
I think it's safer to say: It's almost all HTML these days. XUL is very much deprecated.
It’s a mixture of XUL and HTML nowadays. The reason is, most of the things that were only available in XUL are now possible in HTML, and it’s eaaier to find developers who know HTML.
I agree, but also it’s the fact that there’s a steady supply of devs who already know decent HTML, while not many who know XUL. It would be easy to apply your HTML knowledge to XUL, but since we already support interleaving HTML and XUL, why not let people just use what they’re used to?
That said, I didn’t really look into it all that much! I just happen to know about it because I was doing some userChrome.css stuff back in the day.
Sadly you had to know the underlying structure of the components to work around the performance issues. Main pain point I had to work around was the fact that most containers where scrollable by default and brought a huge update cost.
For a time my job was to convert components written by a visual developer in mxml into custom components written in AS3. I knew the runtime model pretty well and was able to layout complex components in code. These had the benefits of not being nested into multiple UIComponent containers/component layers which all hooked into the UI update loop. Ah good times :)
XAML is still very much a thing on Microsoft platforms, and contrary to your assertion, it still works very well. I would even go so far as to say that WPF (the original XAML-based framework) is still the best UI framework around if cross-platform is not a requirement.
It's funny because it reminds me of Angular in that it's very markdown heavy with the code behind in another file. So they wrapped React to make angular.
angular was dead on arrival - to me - because it seems nuts to bolt on full programming language constructs into html attributes. In the same way React easily won because it chose the exact opposite: put the UI constructs inside the full programming language.
Both have their worts, but I'm perpetually puzzled by how angular ever made sense as ergonomic. I suppose people like Vue so there's still some insistence on augmenting templates with programming constructs. Seems inevitable that templates will want more and more powerful constructs... and boom.
I think Angular "won" a lot of users because it confused a lot of people by calling its templates .html files that designers could work in them without needing to know how to program. Then once they were in those HTML files they were trapped by all the nonstandard attributes. It was a fascinating bait-and-switch to watch middle management get trapped in, I saw it play out a couple times in slightly different but ultimately the same way.
With React those sorts of "I'm only comfortable with HTML" (or "I'm only comfortable with Figma but it gives me HTML") designers often know that they don't like JS and don't want to work in JSX files directly. If middle managers are looking for "efficiency and synergy" the "my designers won't work directly in React" problem looks a lot like a "let's use Angular for everything because I'm told it is 'just' HTML" solution, with the trap being set that Angular's template language is complex and confusing and still a template language despite being in files labeled .html. Then once trapped the sunk cost fallacy strikes hard because "everyone already knows Angular" (despite no one actually "knowing" Angular, they know HTML and fight the template language to get something that sort of works some of the time).
At least Vue tends to prefer .vue for its single-file components. It's not directly the same bait-and-switch.
At my first job, our most senior developer and my mentor was huge on Flex and instant it was going to be the next big thing.
At the time I thought it was inflexible to style and felt very non-native.
To be fair, it had its moment, moreso in desktop applications than on the web. I seem to remember a lot of installers being developed in Flex. The iPhone showed up just in time to kill it before it ever got its footing on the web.
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!
The funny thing about this - and I don't know whether this is as good or a bad thing - is that you could probably almost implement this XMLUI entirely in React/JSX.
Glancing over the markup, none of this seems too alien to React.
This all seems not too dissimilar to the generic pages-as-JSON DSL that every CMS/developer reinvents every other project.
Windows is a narrower platform than evergreen JS-enabled browsers, and the relevance of Windows as a platform is only going to go down. So the choice of the platform is right.
What are some GUI-enabled devices you wish you were able to address, but which cannot run Firefox, Safari, or a Chromium derivative?
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.
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.
I've been writing a UI framework for experiment automation and small tools using Qt Widgets with Python bindings (https://puzzlepiece.readthedocs.io) and it still works pretty well! I like the API, and it being immediately cross-platform is very useful. It does lack looks on Windows a little imo, but to be honest I'm not opposed to the utilitarian way the apps end up looking.
This weekend I asked Gemini Pro to create a Python Qt app (a serial file sender- something you'd use to send g-code files to a CNC machine or laser cutter). I did most of the dev on Windows but the app will run exactly the same on all 3 main platforms. Eventually I asked Gemini to extract the UI to its own .ui file, which it did. The resulting app worked better than the previous one I had coded myself (handling some various race conditions and other challenging issues much more quickly than me).
If I wanted, I coudl ask gemini to port the app to C++. (Gemini isn't the point here- that's just speeding up what I would have done on my own).
Nearly every widely-used commercial or in-house tool in the VFX and Animation sector of M&E are Qt based. The main difference compared to tradition desktop developers is the general attitude of design; the industry takes the stance of providing the same application experience across platforms, rather than trying to adhere to each platforms' UI/UX guidelines.
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.
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?”
I have switched to JUCE as a total cross-platform GUI/high-performance general application development environment, having used it for 7 years in the audio realm I have attained that state, whatever it is, where I realize I can just use it for everything and it’ll be perfectly fine.
Doesn’t take too much CMake wrangling either, and once you’ve got at least one half-decent, clonable JUCE -> CI pipeline working, the horizon gets wider and wider ..
That said, I have to admit that I think more and more about how fun it’d be to just put all JUCE GUI code in a Lazarus’ish front-end, using LUA for that part, and having a decent half Lua/half C++ monstrosity for doing things ..
The splash screen is a condition for using JUCE for free under the AGPLv3 license, particularly when distributing open-source projects or plugins without purchasing a commercial license.
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).
I've never used JUCE before but I agree that the imperative approach, while often larger in implementation, is usually very explicit about what is happening and allows full control. Declarative approaches always need escape hatches, and those escape hatches are usually tricky to open and pass through.
As a counterpoint, being primarily a web developer (although I did Windows desktop apps with Delphi in the 90s) I hard time doing UI with JUCE.
It never really clicked with me and I had a hard time really aligning things, with their Flexbox thing etc, how you set graphic values outside vs inside component classes, being sometimes confused how paint() vs resized() affect things etc.
Probably operator error but in the end I was happy to ditch it for the new WebView option in JUCE 8.
JUCE 8's WebView is an abomination that tarnishes an otherwise amazing framework.
Yes, coming from the web, JUCE' Flexbox and paint()/resize() semantics are going to be 'weird' - but thats the point. You have the power to decide when/how to update your GUI, frame by frame - and for high performance GUI's, this is vital.
These days it has to be said: you can get a LOT of your JUCE GUI work done for you by an LLM with great results.
Maybe but I actually got a ton of hallucination about the JUCE API with LLMs, as in they sometimes would just not produce workable code at all and invent functions repeatedly (endless infamous "you're right!").
My project is not a typical audio plugin so it's also why I was not benefiting as much about the graphic API as others may do.
But I'm not sure how the WebView is an abomination, it's actually a quite small API that works ... and is totally optional and didn't replace the original graphic API.
JUCE is also slow as heck and takes a lot of know-how to make performant. Notably, if you want any kind of real time animation or display, you don't do anything component based.
It also involves a custom C++ module system and build strategy that is hard to make fast and generally is impossible to use JUCE as a library, so you wind up recompiling it as a dependency an excessive number of times (which adds up in CI).
React itself was class based in the beginning, and that would have probably been a better model in the long run - it was a lot more code for sure, but less complexity.
This is definitely debatable. I grok the composable functions model quite well, and hooks let you separate logic out of components extremely well and intuitively once you understand the basics of React.
By comparison, I feel class component's promoted 'mile high' components where everything was inside of the class, which has many enormous drawbacks, one of the biggest being maintainability.
To this today though, I feel most people don't understand the simple rule of UI is the last mile concern. Developers still cram way too much into components rather than separating layers of concerns
It just works, in my experience, with Narrator on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. The graphical component editor lets you set stuff like labels and tab order and that's usually enough to make things work at least okay with a screen-reader. Getting things to work A+ requires more manual effort, such as implementing AccessibilityHandler for complex components. But the basic JUCE classes are usually much better than what you'd get from any "JavaScript inside WebView" GUI, precisely because you manually coordinate the presentation and the screenreader texts.
I've worked on Surge, which is (to my knowledge) the only fully accessible synthesizer. It uses Juce's a11y abilities to do this work, plus a whole lot of very thoughtful design. We have multiple blind users.
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.
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.
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.
Not sure what you mean by licensing failure or “one liner”. Browsers are natively limited to XSLT 1.0 not because of licensing, but because they simply didn’t want to implement the newer versions. However Saxon offers free XSLT 3.0 processors for JS, C, Java, and .NET, so there’s not really a limitation to doing modern XSLT development.
Licensing is just another aspect of friction, contributing to everyone sticking on 1.0 and making it annoying for anyone trying to move forward with XSLT. One liner is a lack of procedural logic in its implementation. Its fine for 1-1 mapping but as it gets used in more complicated scenarios it can be hard to developers to architect a solution because there's no space to breathe.
What specific licensing problems are your referring to that supposedly hold back XSLT? It’s an open spec, anyone can implement it, and there a free processors under MPL license.
And what specifically do you mean when you say everything has to be processed as a one liner? I’ve never used an XSLT processor where that was true.
To gain access to the better toolset you need v2 and v2 costs. Maybe the org doesn't have it, maybe getting a PO for it is annoying, maybe there's friction around getting it installed on a customer site. Perhaps its just a factor which resulted in everyone else sticking on 1.0. But it never took off in the way promised because of it.
That it is a fiercely declarative language makes it hard to integrate. Often developers are placed within an architecture that gives them limited options and only being able to use XSLT while trying to integrate other network calls or services is non-trivial and a complete headfuck sometimes, compared with more general purpose languages like python or javascript.
You are misinformed about license cost, as I’ve already explained in multiple comments.
Hard to integrate in what way? XSLT is a language focused on several things that it’s very good at but it’s not intended to replace Python or be a general purpose language. Yet there are many common data related tasks where a messy and hard to maintain pile of imperative code can be replaced with a simple XSLT.
I'm talking about the cost as being friction that resulted in 1.0 being so dominant and 2.0 being scarce.
Not everyone gets to pick and choose how they use XSLT. Place I used to work, the services team used to have a sign:
> [X] Days since last custom report
They hated it and I can't blame them, making a series of soap calls, consuming the most degenerate api ever written and generating a document for the customer was a pain. Bear in mind this was an enterprisey "do everything system", oversold by sales and the services team had to use XSLT to bridge the gap between customer expectation and what the salesman sold them.
What they needed was a host for a general purpose language, what they got was XSLT.
Reinventing XML traversal/transformation in JavaScript will lead really fast into abstracting away the recursive tree traversal, then mapping node marchers to functions. Which is 99% what XSLT provides off the shelf.
many developers just want to have some space to do some extra logic and XSLT doesn't really accommodate for that. You have to deal with the input and create the output without pausing for breath. While this is fine in simple use-cases where the mapping is 1-1 but when the mapping gets more complicated then it becomes difficult to maintain.
That’s simply not true. Certainly it can be hard to wrap your head around architecting complex logic in XSLT 1.0, but it's not unlike how you have to change your thinking for functional programming generally. More ergonomic imperative logic and several other features in XSLT 2.0 made it a much more developer friendly language.
Most orgs don't transition to 2.0 which is a big part of why XSLT sucks.
> but it's not unlike how you have to change your thinking for functional programming generally
I'd write lisp any day of the week over XSLT. I don't think XSLT deserves a place alongside other functional languages because its bound so tightly to xml. Sure, one can argue it has its place when processing XML but I'd pick a general purpose language and process XML with that over XSLT every time.
You keep making assertions and generalizations without backing them up with anything concrete while simultaneously moving goalposts. In the cases where you do, you’re just wrong: XSLT is not held back by licensing, it doesn’t “require one liners”, and it has supported JSON since 3.0, which has been around for almost a decade.
XSLT was held back by licensing, its why everything supports 1.0 and barely anything supports 2.0. If 2.0 was released for free then everything would use 2.0.
well then tell me why .NET's XSLT platform is rooted in 1.0 instead of just saying "no". From my understanding licensing was a factor that played into the reasons why .NET natively remains on 1.0. The transition to 2.0 appeared to have specific friction: why?
for reference: I'm not talking about today, I'm talking about that point in time where (for example) .NET could have adopted XSLT 2.0 but chose not to.
.NET didn't transition to XSLT 2.0 for the simple reason that demand wasn't really there. The way they saw it, LINQ was a better all-around option, with XLINQ specifically being an adequate replacement for XPath, and VB even got a bunch of special syntax to work with XML that made it more concise than XSLT in many cases: https://learn.microsoft.com/en-us/dotnet/visual-basic/progra...
That said, it is emphatically not true that XSLT 2+ was somehow license-restricted. I worked at a company that used XSLT 2.0 and XQuery for code generation back in 2006, and we used the free edition with Saxon with no issues - paid versions had some optimizations and features like static type checking which we simply didn't need.
For the most part, XSLT 1.0 was "good enough" for most cases when XML was still the primary interchange format, and later JSON took over so there was less incentive for framework providers to spend resources on keeping up-to-date with the standard. Especially since XSLT 2.0 was such a massive leap in many ways, including a different data model that made many existing XSLT 1.0 processors incompatible in ways that required a massive redesign.
I wrestled with how much history to bring into this because I want to look forward not back. The purpose of the announcement is to encourage people to try the tool and find out for themselves if it is a productive way to build the user interfaces they need.
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.
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.
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.
You're basically correct, but this isn't due to a philosophical choice. Simply speaking, XSLT stopped evolving before Ajax really got popular, and it was eventually purged from most browsers altogether on security grounds. So nobody really tried to build XSLT engines that could address modern use-cases.
Somewhat ironically, the semantic web was initially supposed to be built on browsers making calls for XML data (the X in Ajax) to then be displayed via XSLT. This model failed to gain adoption mostly because, let's be honest, XSLT is just blooming hard.
I know it depends of the definition of "modern browser", but I'm fairly sure that MSIE and pre-chrome Edge had lost support for it at some point, since MSXML stopped being shipped with them.
I honestly don't know what the current state of the art is, but Firefox doesn't do native XSLT anymore afaik (yes, you can do it in JS, but it's an extra step).
Recreating whole documents is how XSLT has been commonly used, but that’s an implementation detail, and you can nearly as easily write XSLT to produce components. You can output XHTML components and update the vdom - kind of an abstraction leak but not a bad tradeoff if you want to reuse the rendering XSLT. Alternatively, XSLT 3.0 can produce (and consume!) JSON, so you can use it as way to bridge XML into a traditional React app or to simply process JSON.
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.
The performance of available XSLT translation engines would be a big consideration for me, especially in a hot-reload context to support fast iterations.
That was my first thought: no XSLT 3 engine that I know of keeps an in-memory object that supports iterative retemplating on diff changes to the source. I think the closest to this is in the functional communities and their lenses. Given how "far" XSLT can reach through a document via Xpath, I don't think it's an easy-to-solve problem.
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.
XMLUI does not execute JavaScript with "eval" or anything that would not comply with CSP. It runs interpreted JavaScript asynchronously in a sandbox and does not allow use of "eval" (and another dozen low-level functions, such as setTimeout).
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.
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.
> 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.
It's important to note that pretty much nobody used the visual designer though. The resulting xml was pretty terrible, writing the UIs manually (in xmls, while looking at preview) was infinitely better
That's just Android though. A good example of doing this well is JavaFX with Scene Builder. The XML corresponds to the UI tree 1:1 and the designer makes XML that looks hand written (or vice-versa). FXML is also a pretty intuitive schema and there's a dialect of CSS intended for UI that I find more intuitive than web CSS.
Plenty of apps used the visual designer. You could tell because the UI would be a right mess the moment you didn't use the app on a screen that matched theirs.
Good apps were using semantically correct design layouts but there were, and still are, tons of bad apps out there, just like there were a ton of VB6 applications.
> 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.
There is also Lazarus[1], which uses Pascal but feels closer to what I remember of the VB6 experience.
Our experiences do not match. I used Borland Delphi to build business apps 20 years ago just using the UI builder. I've been using Android Studio to build apps at FAANGs for 10 years now and I cannot remember the last time the Design tab was useful - it was always faster and more reliable to just edit the XML file.
Yes, Delphi didn't do resizing windows and crashed half the time, but I was pretty happy with the WYSIWYG / UI building functionality for production apps.
Android Studio's UI builder is nowhere near that level of usefulness. I have a hard time believing anyone is using the UI builder in Android Studio for anything other than tutorials or entry level Android apps. It doesn't render the layout properly 90% of the time, or just renders some placeholders with no content and calls it a day.
For a modern IDE, Android Studio is somewhere between just OK and bad, mostly because it has features the other IDEs didn't at the time, but the dev experience is behind Turbo Pascal in the 90s on MS DOS. The editor is laggy. The debugger is slow and hangs often. The list goes on, but I'll stop the rant here.
Android Studio had the exact WYSIWYG experience other toolkits used to have, it was just hidden behind an <AbsoluteLayout> because designing mobile applications the way desktop applications used to be designed is an awful idea.
Drop an AbsoluteLayout into a design and you can drag, drop, and resize buttons to your hearts' content. You'd have the same problem with VB6 where your buttons would fall off the screen if someone ran your application at a lower resolution than you designed it for, but that was never a problem for the desktop designer.
For the same reason dumping buttons on an arbitrary coordinate and resizing by eye is no longer acceptable on desktop, that same ease of design died out in Android for any serious application developer. It stuck around a while longer on desktop, unfortunately, but modern frameworks pretty much all use declarative layouts these days.
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
Using XML to declaratively define UI trees is an idea so obvious that many developers back in late 90s - early 00s had their own bespoke frameworks for that.
And you know what? It worked great. WPF with XAML - from 2006 originally! - is still, to this day, by far the easiest way to write a desktop Windows app with adaptive layout etc.
XUL was conceived by Dave Hyatt FOR Mozilla AT Netscape. Netscape was going to end development of not-Windows Mozilla because maintaining 3 front-end teams was more than the Netscape/Mozilla leadership believed it had resources for and XPFE was the solution.
If you believe XUL was developed for anything other than Mozilla's XPFE, you have been mislead.
Also, would you please provide names for those many pre-XUL XML-based UI languages I'm genuinely curious. Other than the web itself, HTML+JS+CSS, I'm at a loss for what those many XML-based UI markup languages you're referring to could possibly be. As a Mozilla participant at Netscape, and someone with hours of discussion with Hyatt over those early years, and a (very small) contributor to XPFE as early as Dave's XUL menus first draft, I'd be real interested to learn about prior art. Did we somehow miss all of those per-existing examples?
XUL was created by Netscape employees for Netscape's XPToolkit project¹. I didn't think that saying that "Mozilla² adopted XUL" would be considered controversial or somehow denigrating, so apologies if if came off that way.
AOL acquired Netscape in 1999, then became the first company to ship XUL as part of Netscape 6 in 2000. https://en.wikipedia.org/wiki/Netscape_6#:~:text=With%20publ... AOL abandoned XUL to the Mozilla open source community not long after, when they disbanded the Netscape team in 2003.²
> Also, would you please provide names for those many pre-XUL XML-based UI languages I'm genuinely curious.
WML, XFDL, and Glade XML all shipped in 1998, two years before Netscape 6. Adobe's XFA also shipped before Netscape 6.
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.
You're forgetting the state management required to link the components. Here's a take (by Claude) on what it would look like, even if you ignore the entire `useDataSource` implementation it's an entirely different beast:
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.
To be frank, this would likely not help you. A simple web page is effectively simpler XML as the HTML elements that are already there are quite enough.
I might be completely off the mark here (edit while writing the comment, considering you mention static HTML I probably am, going to leave the comment anyway for others to see), but considering you seem to think that you need React (or any javascript for that matter) to me seems to hint at a practical knowledge gap about HTML and webpages in general.
Which, is more common these days exactly because modern libraries effectively abstract it away to the point where people only see HTML when looking at the DOM representation in the browser devtools.
> 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),
It is interesting to me how we effectively regressed here. At least as far as common knowledge goes. You can still go to a basic shared webhosting provider, get a domain, some storage, mysql/mariadb datbase, php and do all of that with relatively little effort. Of course, PHP isn't considered to be relevant anymore which is entirely fair. But it is by far the most straightforward way to get a website going with an actual backend that doesn't require you to do cloud wrangling and all that.
Yea, I am indeed quite deficient in HTML knowledge and webpages in general. I'll look into PHP, thanks. Overall I have standards (that might be unachievable?) that I think tools should aim to be extremely simple if at all possible (at least there should be niche tools that achieve this, I mean), and what I've seen from web development doesn't quite meet those goals :P
I really like OpenSCAD for instance, which despite being a little difficult to do complex stuff with, is quite easy to learn (and you can indeed do complex things with a little methodology). Like, everything about the web seems a little obtuse to me. One day I'll learn a little more to hopefully make more educated comments :)
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.
I was thinking the same thing. Programmed ColdFusion for over a decade and loved the language, however I moved onto .NET, the PHP and now Rails. ColdFusion was a wonderful language, but the frameworks weren't there and the market share wasn't there either. Ironically enough, one of my clients still uses it for their application and we actually began talks about moving them over to Rails.
OpenLaszlo was an eariler, more powerful, more fun, open source alternative to FLEX. It's obsolete now that Flash is dead, but I really got in the "zone" with it.
OpenLaszlo used XML with embedded JavaScript in a way that let you extend XML by defining your own tags in XML+JavaScript. I've done a lot of work with it, and once you make your peace with XML (which seemed like a prudent thing to do at the time), it's a really productive enjoyable way to program! But that's more thanks to the design of OpenLaszlo itself, rather than XML.
OpenLaszlo (which was released in 2001) inspired Adobe Flex (which was released in 2004), but Flex missed the point of several of the most important aspects of OpenLaszlo (first and foremost being cross platform and not locking you into Flash, which was the entire point of Flex, but also the declarative constraints and "Instance First Development" and the "Instance Substitution Principal", as defined by Oliver Steele).
The mantle of constraint based programming (but not Instance First Development) has been recently taken up by "Reactive Programming" craze (which is great, but would be better with a more homoiconic language that supported Instance First Development and the Instance Substitution Principle, which are different but complementary features with a lot of synergy). The term "Reactive Programming" describes a popular old idea: what spreadsheets had been doing for decades.
OpenLaszlo and Garnet (a research user interface system written by Brad Myers at CMU in Common Lisp) were exploring applying automatic constraints to user interface programming. Garnet started in the early 1990's. Before that, Ivan Sutherland's Sketchpad explored constraints in 1963, and inspired the Visual Geometry Project in the mid 1980's and The Geometer's Sketchpad in 1995.
>Declarative Programming: Declarative programming is an elegant way of writing code that describes what to do, instead of how to do it. OpenLaszlo supports declarative programming in many ways: using XML to declare JavaScript classes, create object instances, configure them with automatic constraints, and bind them to XML datasets. Declarative programming dovetails and synergizes with other important OpenLaszlo techniques including objects, prototypes, events, constraints, data binding and instance first development.
>Garnet is an advanced user interface development environment written in Common Lisp, developed by Brad Meyers (the author of the article). I worked for Brad on the Garnet project at the CMU CS department back in 1992-3.
More about TCL/Tk, OpenLaszlo, Garnet, constraint programming, history of constraints: Coco KVO, Objective Smalltalk constraints, Sutherland, Sketchpad, Geometers Sketchpad, Knowledge Representation frames, push vs pull constraints, etc:
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.
While flexbox is more powerful, those semantics would require prior knowledge of other CSS attributes and to develop an intuitive understanding of them.
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 really would like you to contrast that with what you have to do with HTML on the Internet. Think about it. HTML on the Internet has gone back to the dark ages because it presupposes that there should be a browser that should understand its formats. This has to be one of the worst ideas since MS-DOS. [Laughter] This is really a shame. It's maybe what happens when physicists decide to play with computers, I'm not sure. [Laughter] In fact, we can see what's happend to the Internet now, is that it is gradually getting—There are two wars going on. There's a set of browser wars which are 100 percent irrelevant. They're basically an attempt, either at demonstrating a non-understanding of how to build complex systems, or an even cruder attempt simply to gather territory. I suspect Microsoft is in the latter camp here. You don't need a browser, if you followed what this Staff Sergeant in the Air Force knew how to do in 1961. You just read it in. It should travel with all the things that it needs, and you don't need anything more complex than something like X Windows. Hopefully better. But basically, you want to be able to distribute all of the knowledge of all the things that are there, and in fact, the Internet is starting to move in that direction as people discover ever more complex HTML formats, ever more intractable. This is one of these mistakes that has been recapitulated every generation. It's just simply not the way to do it.
And yet in the nearly thirty years since he said that, the browser has come to dominate how people interact with UIs. Both in terms of sheer popularity (not only do we have complex applications on the web, but we also package complex applications with browsers as desktop applications) as well as influence (SwiftUI, Flutter, and Jetpack Compose all borrow heavily from frameworks developed primarily for the web).
I think a lot of this has to do with the idea that Kay is criticising here: HTML as a mechanism for building applications has been so successful because it needs to be interpreted by a browser. That provides a tremendous level of sandboxing that makes it a lot easier to trust whatever website you're loading than the application you're installing. It also provides a grab-bag of useful controls and elements, while still being completely flexible with creating new ones without needing to resort to OOP inheritance chains or raw graphics drawing APIs. This is all to say nothing of accessibility, which is practically built into the browser.
> Full Browser window size cancas ... and draw everything yourself
This was already tried to some extent with Flash. Many sites were a single Flash module (or multiple). Implementing accessibility then required maintaining an invisible DOM representation of the Flash canvas. I personally don't want to return to the era where login and register buttons were dedicated Flash modules (MegaUpload did this back in ~2009) and many sites were an 800x600 image using the <area> tag for hitpoints.
Even Flutter has a DOM target because painting to a full <canvas> violates at the very least the operating system's text rendering, scrolling, and accessibility.
I agree with you that these things are important. However they are ( in implementation terms ) rather small issues, and determining i rather pay 4-8x more in development and maintenance costs just for this, while you can go the other way and make those features a bit hardware to implement seems like a not so good business case to me.
e.g we are using Avalonia. Of course everything is drawn in a scalable way, with responsive design etc... Accessibility is built in of course ( with integration with the relevant browser apis ) screenreaders work perfectly as do other accessibility features ) Its not the hap hazard way that flash did this (before there were relevant standards for these features anyways )
Invoking a brower api / interop is easy, the difference is we do not need to compromise our productivity for small things.
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.
It was pretty easy to debug most of it with Dom Inspector and Venkman, themselves written in XUL. Even the XBL bindings and other sometimes challenging bits, were directly inspectable and editable. As a minor contributor to Mozilla's early XUL work and later Firefox's XUL work, mostly stripping XUL overlays and reducing clutter in the Firefox case, it seemed pretty straight forward to me.
> 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.)
Great points! I love Nic Barker's frantic hand gestures while he explains how React works in that video. "Oh gosh, you don't want the hear this! Ha ha *grin*!":
>DonHopkins on April 25, 2019 | parent | context | favorite | on: Immediate Mode GUI
>Immediate mode GUI's don't let you apply useful object oriented programming techniques like subclassing and prefabs (persistence) to implement and configure custom components.
>Properly object oriented retained mode GUIs let you subclass components to implement custom views and event handling, and develop and publish reusable prefabs and libraries of pre-configured, stylized, specialized component. [...]
>I don't know what you mean about easily composing immediate mode API's, or agree that different immediate mode APIs don't need to know about each other. They depend on a lot of behind-the-scenes implicit hidden state (practically a hidden shadow-DOM-like retained mode), so I suspect in many cases they'd walk all over each other (especially text editors dealing with input focus and keyboard navigation). Unity3D has two immediate mode APIs, one for the editor and one for runtime, and they sure don't mix. [...]
>How would you write a functional extension for Unity3D's old immediate mode GUI that let you embed an ACE code editor in a Unity WebGL app? What would the API and state management even look like? How could you make it platform independent?
>And even if you solved all of those problems with an immediate mode API, by its very nature it still wouldn't enable you to build GUIs in the interface editor or store them in prefabs, and you'd still have to recompile you app (which can take half an hour with Unity) every time you wanted to tweak the user interface (which is why I like programming Unity apps in JavaScript as much as possible). [...]
>Embedding object oriented "retained mode" widgets with different APIs inside of each other is old hat and common for backwards compatibility. Whenever you write a new GUI toolkit, embedding widgets from the last toolkit is one of the first things you do (including recursively embedding widgets from the toolkit-before-last).
>Concrete example: Microsoft lets you embed old fashioned OLE controls in Windows Forms / Presentation Foundation applications, which might be implemented in MFC themselves. And MFC is all about embedding old Win32 widgets implemented in C, and newer OLE components implemented in Visual Basic or whatever, in venerable C++ MFC user interfaces. Say what you want about how much Win32/MFC/OLE/WF/WPF sucks, and I'll wholeheartedly agree, but if you're running Windows, you probably have widgets on your screen using several different retained mode APIs embedded more than two levels deep right now. [...]
>The problem with immediate mode that is you have to come up with somewhere to store and retrieve any values or state required on a case-by-case basis (including the edited value itself, and other view state like scrollbar state for text editors, etc), and that tightly couples your component function with whatever's using it, so they're not very reusable or simple. With OOP, the object has its own place to store that stuff, which is cleanly decoupled from whatever's using the component.
>Then there's the issue of event handlers. Some user interface components just aren't so simple that they only have one true/false return value like buttons. Text editors can notify on value change, end edit, select, deselect, etc. And Unity's retained mode GUI supports persistent event handlers that let designers hook up events with methods of objects with parameters, without writing or recompiling any code.
>And there's also a lot more to layout that you can easily express with an immediate mode GUI. Sometimes you have to measure a bunch of things and align them in various ways, like grids or flex layouts, and adapt to the screen size and other constraints (i.e. responsive design), and that's really hard to do with immediate mode, while retain mode has a rich set of layout components you can use and extend. And there's nothing like XCode's layout constraints for immediate mode. [...]
>A perfect example is TextMesh Pro's text editor. It has so many different (and useful) features and parameters and callbacks and ways to configure it, and it keeps so much state in order to redisplay efficiently with the fewest number of draw calls and reformatting, that it would be extremely impractical and inefficient and unwieldy for it to use an immediate mode API. Especially with C# positional arguments instead of Pythonic or Lisp-like optional unordered keyword arguments.
>When you encapsulate your immediate mode layout in a class, or write an engine that interprets (i.e. JSON) data to drive the immediate mode API, or use reflection in your wrapper functions to dispatch event callbacks and bind your widget data to your model data, you're just rolling your own informally-specified, bug-ridden, slow implementation of half of retained mode. (See Greenspun's tenth rule.)
Well, yeah, obviously, somebody has to retain some state at some point. The nice thing about a good IMGUI is that it's easy to integrate with your own state-maintenance logic. It's all about separation of concerns.
In practice, every time I've built an IMGUI, it's always turned into some kind of hybrid immediate/retained-mode approach. There's nothing desirable about forcing the business logic to remember the state of a button on the screen, after all. It comes down to how easy it is to build and maintain the mixed-paradigm model that everybody inevitably ends up with anyway.
In the case of the last framework I put together, individual buttons can be treated as true immediate-mode controls, where hit-testing, labeling, and other interaction with the program takes place at render time, while button groups retain the necessary state to lay themselves out, handle mutual exclusion, and so forth. Nothing keeps the app from maintaining its own list of buttons and calling it a group or whatever, but if I don't need to do that myself I can let the GUI do it.
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.
> 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.
I do this for custom software I build for clients, mostly on the backend though[1]. Started it two years ago, have rapid velocity and, without AI generally take 30 to 60 minutes to implement a new feature that touches backend persistence and front end UI.
‐----------
[1] I did a show HN on a tiny front end component that gets the most use, recently, I think. ISTR most people in the comments said they they preferred React, a few said it was not novel enough to be a paper (they are correct. It isn't). You can see it here: https://github.com/lelanthran/ZjsComponent/
I'm not really in the mood to open up the whole stack I use yet, I still make money bu having a low effort way to build web apps, and due to the way it works it requires a fraction of the tokens required when actually using AI assist (output for the last time I implemented a backend call from scratch was 10 lines, most of which were comments).
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.
In other hands, I have seen Excel spreadsheet hundred-products pricelists become a freaking tangle of merged cells, multiple rows for products, spelling mistakes, multiple spaces everywhere, and price cells hand-formatted. And I had to export the contents to machine readable .csv...
“Webxcel creates a full-fledged RESTful web backend from your Microsoft Excel workbooks. It is written in 100% plain Visual Basic macros and comes with a lot of handy tools to help you build the next big thing.”
That's a disingenuous take. You could write one, but it won't be allowed to connect to anything other than itself because Excel doesn't give it the network stack or IO it needs. Unless you use VBA, of course.
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.
Html tables are very different from excel tables. Fundamentally html tables were used because rows are a good way to split up the page vertically (you could have one row for the header, one for the content one for the footer). And columns are good for splitting it up horizontally (you could have one column for the side panel, and one for the content, and the last one for an obnoxious blinking ad).
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).
If we somehow manage to solve the two main spreadsheet downsides (imo): testing and change/version control, then spreadsheets would be a terrific programming paradigm.
As it is now I find it very powerful and empowering, but also scary.
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.
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.
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.
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.
Because using htmx is asking to get defaced via XSS, or worse. Security is an afterthought for the project, which is evident from the placement of the related documentation.
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.
It seems a little strange to accuse jquery. I think what actually "killed it" was modern HTML. Jquery was just an intermediate API that let you target modern browsers and IE without having duplicate/shim code to maintain yourself.
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.
2005-2007 I worked on a webapp where the app layer rendered to XML, and then optionally server-side applied an XSLT transform to generate either HTML, RSS, or Atom, but you could also request the raw XML (and browsers could apply the XSLT client side, but for debugging/testing it was great to be able to then also see the underlying XML.
It had some benefits in terms of enforcing strict separation as well, but it was also painful to deal with the many deficiencies of XSLT (e.g. try reformatting dates...) that meant the XML ended up having annoying redundant values where it was easier to provide multiple versions of the same value than doing the conversions in XSLT.
These days I'm doing something similar by having apps return JSON and having the I built dynamically from the JSON with javascript, and I like that better than the XML => XSLT as much as "in principle" I agree with you that the pure approach of XSLT feels "correct". It's just too painful to apply as-is.
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.
Our hope is that by building up a set of these patterns, and making them available to agents via MCP, it will be as easy as possible to get things right.
No offense, but you failed here. What if nothing gets returned? Now you're basically just writing code. Debatably even that example you're just writing code. An onLoad callback with array indexing and child access? This is just JavaScript wrapped in XML.
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 ).
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.
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 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! :-)
Ivan Sutherland's Sketchpad (aka Robot Draftsman) was created in 1963, and inspired the Visual Geometry Project in the mid 1980's and The Geometer's Sketchpad in 1995
Laszlo... I remember this one, dipped my toes in it, like many, many other GUI tools. I've been using the same backend framework for 20 years with no need to change but I can't decide which frontend GUI library I should invest my time for the future. It all looks like constant rehashing of the same ideas but with limited lifespan.
XUL applications outside of Mozilla existed well before XULRunner (itself barely a product.) Of course Mozilla was the main client at XUL's birth in 1999, but when I joined staff@mozilla.org 25 years ago I worked with OEOne, an ISV delivering a full Linux front-end using XUL. That was late 2000, maybe early 2001. A year or so before them, our parent company, AOL, began working with OEMs on XUL-based thin clients and AOL even re-built Prodigy (the low tier trial run for the AOL main client) with Gecko and XUL in 2001-2002. And of course, Mozilla itself shipped on a nearly a dozen platforms in 2002, and entirely XUL.
XUL was born in 1998 and the spec was finalized in 2001.
I worked on the cross platform TomTom Home content management app in 2007-2008, which used XULRunner and XP/COM extensively.
But XULRunner only really existed to serve Mozilla's Firefox web browser, and anyone using it for their own applications, like TomTom Home or Songbird, was on their own without any support.
Mozilla didn't take our XULRunner PRs seriously, or put much more than promises and lip service into XULRunner supporting other applications than Firefox.
If Mozilla was actually serious about supporting XULRunner for anything but Firefox, then it might have taken the place of Electron a lot earlier that Electron's release in 2013. That was a huge missed opportunity and tragedy of broken promises and wasted effort.
>I first looked at Red Swoosh and its Firefox extension, FoxTorrent. It would have been ideal, since we using the xulrunner platform for TomTom Home, but Akamai acquired Red Swoosh, and it vanished without a trace. [...]
>One way to get Akamai to unilaterally lower their bandwidth prices is to threaten to use BitTorrent instead. [...]
>TomTom had an "iTunes-like" desktop content management and device control desktop app called TomTom Home, which was implemented in xulrunner (the underlying framework of Firefox and Thunderbird, kind of a predecessor to Electron for writing cross platform desktop apps in JavaScript with C++ XP/COM plugins).
>The first thing I tried was to make an XP/COM plugin out of the LibTorrent library. That worked ok, but the idea of increasing the size and complexity of what was already essentially a web browser with a whole bunch more complex code that does lots of memory allocation and networking all the time, didn't seem like a good design. This was long before Firefox supported multiple processes, so the same app handing bittorrent would bloat the app and degrade the user interface responsiveness.
>However RedSwoosh, FoxTorrent and BitTorrent DNA all ran in separate processes that just handled all the BitTorrent stuff, and that you could talk to via https (to stream the file with a special url, and retrieve progress telemetry on another url). And it's incredibly easy to integrate xulrunner or any web browser with those servers via http, so no C++ XP/COM plugin required.
>Another issue is that you don't want every application to have its own BitTorrent client built in, or you will trash the network and disk, since otherwise they would compete for resources. It needs to be a centralized a system service, shared by any app that needs it.
>BitTorrent DNA worked nicely that way. And it could fall back to the CDN to download at full speed if there weren't enough seeders.
Also unfortunately, XULRunner was in no shape to run on mobile or embedded devices, so we ended up running WebKit on the TomTom embedded Linux devices, instead of trying to shoehorn Mozilla into small mobile devices.
>Both Chrome and Safari were based on WebKit (which itself started as a fork of KDE's KHTML and KJS libraries), which a lot of other vendors use too.
>Although Chrome eventually diverged years later with the development of Blink, Chrome was the result of a multi-company, industry-wide unification strategy on WebKit, the core of Safari. [...]
>Mozilla was in no shape to run on mobile or embedded devices (and still isn't afaik), while WebKit ran quite nicely on mobile and embedded devices, thank you.
And as we all know, Android is as important to Google as iOS is to Apple.
>So there was really no chance of either of them (or any other of the many companies interested in mobile and embedded devices, like TomTom for example) ever building on top of Mozilla/xulrunner.
QML copies many core ideas from JavaFX (released 2008) and Microsoft's WPF (released 2006).
Microsoft's XAML for declarative UIs is the most reused/reimplemted approach among this bunch. Its variants are in WPF, Silverlight, WinUI, Avalon and Uno.
I'm curious, not talking down: would you be interested in sharing your age and/or years of experience coding, and if you're feeling very generous, the languages youve written code in for more than 2+ years?
I'm 37, 17 years full-time-ish, VB6, ObjC, Java, Dart.
I'm asking, I guess, because I feel like I've seen these concepts before in pre-iOS ObjC, and Java, and IIRC a good chunk of the late 90s and early 00s was obsessed with doing this stuff in XML.
I barely remember, in my hobbled, probably incorrect, perception the ideas are old enough to that I am a bit flummoxed at how to interlocute with the idea that they're novel breakthroughs.
I'm ashamed to admit I thought the page was parodying this concept from back then of anything + XML = awesome. Im admitting it to give a concrete sense of how my subconscious processed this as settled territory.
In order: 42 years old; 17 years (at least? starting to lose count!); PHP -> JavaScript -> Clojure/ClojureScript -> TypeScript.
Perhaps more pertinent to the topic, in my last job I implemented the bulk of an XForms implementation. Pertinent because XForms has a lot of conceptual overlap with what I’ve seen in XMLUI so far.
I think it’s worth clarifying my point above with that context: it isn’t the concept that I find novel, at all. It’s the sheer depth and breadth of declarative expressiveness that I see in the examples. Maybe the best way I can put it is that what seems novel to me is how much novelty it appears to enable, before breaking through the abstraction to give it more capabilities.
What we've been seeing for a while is that the rate of wheel reinvention has skyrocketed. Just look at the PostgreSQL ecosystem and you'll see many libraries for each feature you might be interested in.
I am not sure about prior art but the ability to mix built-in and user-defined components, and fluidly refactor the mixture, feels very powerful to me.
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.
I think it was a big missed opportunity. The frustrating thing about web UIs is that they don't obey my system-level display preferences (for stuff like fonts and colors). XUL was an approach that did that. Whether it's XML or something else is not the big issue, it's more a question of how to use a declarative style to specify a UI in a way that blends with the user's display preferences.
If memory serves, the system style stuff was a bolt on that Dave Hyatt did a bit later than the core work, and mostly for Windows.
The one theme for all platforms that was initially envisioned by Netscape kinda sucked ("Blue" for anyone that might remember.) And when Ben Goodger began his native-looking theme for Windows (pretty sure he started with preferences, maybe even before he got hired,) Dave got to work on Windows OS style queries and hooking OS style into XUL so the Mozilla suite's emerging new default theme could reflect those in its widgets. That work was ongoing even after most of the rest of XUL had been settled and I think Dave was still working on that even at Apple, right up until Mozilla decided Firefox would also ship on Mac and Linux and not just Windows* (as the several of us working on it has envisioned.) Once Firefox was running on Mac, Dave was precluded from continuing because of his Safari work. (He'd gotten permission to keep at when it was not directly competing with his Apple work.)
* Firefox was, for about its first year, meant to be Windows only. Ben Goodger had recently built a .Net wrapper for Gecko called Manticore, and there was Hyatt's Chimera for Mac, and Marco's Galeon for Linux, so the thinking was the major platforms would be covered with great standalone Gecko based browsers (no mail, HTML authoring, chat, etc.) But then Ben abandoned Manticore. Dave was convinced that XUL could actually kick ass on Windows (though also certain it could not on Mac) and so Ben started mozilla/browser to be the standalone Gecko browser for Windows. Ben also quickly abandoned that project and Blake Ross, an intern I'd recruited to Mozilla the year before, picked it up. He and I conspired on it with several others joining the effort during the end times at Netscape. Bryan Ryner stepped up to make it work on Linux, for example. staff@mozilla.org, well 5 of us I think, were sitting at a picnic table outside of Netscape's Bldg 21 when we decided that after Netscape wound down, we'd transition from the Suite to standalone browser and email (then called Phoenix and Minotaur). Cross platform would thus become a requirement. We weren't going to drop Seamonkey without replacements for it on Mac, Windows, and Linux. It took a while to get the Mac version up and running and as soon as that happened, Hyatt had to bail. About a year later, we released Firefox 1.0.
XHTML was not a previous version of HTML; it was a failed successor.
HTML was originally conceived as a subset of SGML, but browsers tried to be as forgiving as possible of malformed markup and HTML-in-practice drove standards folks nuts. XHTML was intended to fix this by making a pure-XML representation of HTML, which would be unambiguous and fast to parse, but its very strict error handling made it extremely difficult to adopt. It turns out people would generally rather have a slightly wrong page than one that just said "XML Parsing Error".
WHATWG broke with W3C in 2005 to standardize HTML-in-practice into HTML5, giving up on XML compatibility and strict parsing.
I'm 90% certain that the origin of WHATWG was in late 2003 or early 2004 when Dave Hyatt (Ex-Mozilla, then with Apple) Ian Hickson (ex-Opera, ex-Mozilla, then at Google) Start Parmenter (ex-Mozilla, then at OSAF or Oracle, I think,) Brendan Eich (still with Mozilla,) and a couple other folks were at Mozilla's brand new closet of an office, talking about XHTML's shortcomings, advanced we'd made with XUL, and how the web could best move forward given the XHTML failure and challenges from new platforms. I was a fly on the wall for that conversation and then a fly in IRC for more conversations, but it has been ages and my memory's not what it was then, (and I'm too lazy to dig through 30 years of archived emails to verify) so take it with a grain of salt.
> It’s not failed: it’s the only language used in the ePub standard.
"XHTML" can refer to both a failed series of standards intended to replace HTML (XHTML 1.0, XHMTL 1.1, and XHMTL 2.0) and the XML syntax of HTML that is part of the HTML living standard, which itself resulted from the failure of the XHMTL series of standards. EPUB 3's "XHTML" is the latter, not the former.
I remember trying to write a cross-platform interface for some software in XUL, around 2003. I even bought two (physical!) books on the subject. It was totally impossible! The libraries were ever-changing and you needed the entire Mozilla CVS tree checked out to compile anything and just getting that to compile was endless complexity. I gave up and used an early port of Gtk to Windows.
Such a "could have been great" technology if it wasn't for Mozilla ...
One of the big reasons VB died, people will tell you, was the language. And that's true. But what they don't mention is that the other reason was the components. I'm not sure this is replicating a success story but rather failing to learn from what was not a success story.
I ran a very successful company (successful for a time) that sold Visual Basic developer tools via a printed mail-order catalog named VBxtras.
Two things killed Visual Basic:
1. The web. Visual Basic was first and foremost a Windows desktop app development tool, and their UI-first model of app development did not translate well to the web, or at least the attempts to translate to the web did not resonate.
2. Microsoft. Rather than continue the simplicity Visual Basic offered, Microsoft "improved" it by releasing VB.NET which abandoned the core simplicity that made Visual Basic so wildly popular among "Occupational Programmers," as Kathleen Dollard[1] and I lamented back in the day. The upshot was that former Visual Basic programmers fell into two (2) camps; they either:
A.) Abandoned VB for something else, or nothing at all, because they did not want to have to become a professional programmer, OR
B.) Switched to C# because if they were going to learn how to be a "real" programmer they might as learn C# and not C#'s disfavored sibling VB.NET.
BTW, the company that has developed XMLUI was one of our better vendors of VBX components for Visual Basic. They have since renamed to /n software, but at first they were named IP*Works (I think I stylized that name correctly per how they did at the time.)
I am not sure whether calling WPF a huge failure is justified. It works extremely well when everything is adaptable to its MVC-adjcent MVVM design pattern. In this case it's almost child's play to build rich and conplex GUIs that keep in sync with internal state.
Microsoft dropped the ball when they rewrote WPF in incompatible forms for the web (Silverlight) and Windows Phone (WinUI) shortly after releasing WPF itself. That ruined developer trust for their GUI library longevity.
The irony is that WPF itself never went away, and receives support and even occasional minor new features even to this day on .NET Core.
Much like WinForms, there are still many internal line-of-business apps written in it decades ago that are just happily chugging along, ignoring all the post-Silverlight churn in Microsoft dev story.
I really liked WPF for Windows Phone back then. The tooling was great.
I bought a massive 1000+ page book, "Pro WPF in C# 2010," one day. I also had to buy "Home Maintenance For Dummies" the same day. The bookstore cashier laughed at me.
I spent an unhealthy number of hours working in XUL in 2000-2001 working on the Komodo editor, which, bizarrely, used Firefox as its GUI platform. XUL was neat, but oh god so complicated. XML was the new hotness around the peak of the DotCOM era and Mozilla’s use of XML for a GUI framework fit the zeitgeist.
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.
Don't forget XSLT. Worked directly in the browser. I only found out because the battle.net StarCraft page was made using it and I just happened to find it while poking around.
I stand corrected:
The Microsoft era (2007-2014)
In Jan 2007 I joined Microsoft as an evangelist.
Exactly at the time that Microsoft pushed for the XAML crap... So indeed not reinvented the wheel, just not having giving it up despite the complete failure of it.
I like XAML, the whole point of it is tooling support which was undermined when the tools were so buggy for so long. Now that many of the bugs have been fixed and computers are much faster it’s become a really productive UI paradigm for me. I’ll eventually switch over to Avalonia for better performance and cross platform support.
Yes, among many other things. Applied Researcher so full stack and constant greenfield.
I also worked at DevDiv MS during the Foundation series era so I know why many of the issues with WPF are there, basically political infighting and penny pinching. It didn’t help that Gates quit and Balmer took over. Patterns and Practices didn’t properly understand WPF so they gave bad official advice on how to solve problems, it didn’t help that this was near peak Object Oriented mania and language features like generics were still new so there was a lot of unnecessary boilerplate. Code generation did help with this. WPF has a very high skill threshold for making custom controls that are not just compositions of existing controls, open sourcing WPF has helped a lot with this.
WPF is a flawed implementation of a really good idea, and if you can work around the flaws like I do then it’s actually really great. I totally understand why other people don’t like it.
I know it’ll sounds like I’m a snobbish hipster but the vast majority of people never get to the skill level required to properly use these tools. And while React starts out easier it doesn’t stay that way.
This was tried with Polymer way back in 2014 too, ex. making network requests with <iron-ajax> - https://github.com/PolymerElements/iron-ajax
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.
Also Mozilla did their app in real XML UI with XUL. But even they themself stopped using it after 20 years.
At my last job, when I first started there (this was circa around 2006), we actually used a Firefox browser plugin with a custom XUL interface to enable our writers to write content faster. It has a very complex UI, as complex as anything that could be found in the browser itself. Thousands of lines of XML and JS.
XUL was deeply unpleasant to use and maintain, and I do not miss it at all. We eventually ended up rewriting it as a standard webapp. It made the writers a bit slower, but they adapted eventually.
AFAIK Mozilla still uses XUL to draw their browser UI.
It's used for things like pop-up menus, (i.e. things that can't be done with HTML) and was recently used in some obscure parts of the UI e.g. certificate viewer (however I'm not even sure that's still XUL any more)
I think it's safer to say: It's almost all HTML these days. XUL is very much deprecated.
As we killed XBL, our XUL components because web components. https://briangrinstead.com/blog/firefox-webcomponents/
It’s a mixture of XUL and HTML nowadays. The reason is, most of the things that were only available in XUL are now possible in HTML, and it’s eaaier to find developers who know HTML.
> and it’s eaaier to find developers who know HTML
Rather: find developers who have a shallow knowledge of HTML.
I do claim that it takes much less time as a developer to get to a decent level of XUL knowledge than to get to a decent devel of HTML knowledge.
I agree, but also it’s the fact that there’s a steady supply of devs who already know decent HTML, while not many who know XUL. It would be easy to apply your HTML knowledge to XUL, but since we already support interleaving HTML and XUL, why not let people just use what they’re used to?
That said, I didn’t really look into it all that much! I just happen to know about it because I was doing some userChrome.css stuff back in the day.
Just came across this Firefox.html announcement in another thread and it might have some more context: https://web.archive.org/web/20230402033035/https://mail.mozi...
Adobe Flex was really nice. I shipped some good desktop apps with it, I recall it being a much better experience than Electron
Sadly you had to know the underlying structure of the components to work around the performance issues. Main pain point I had to work around was the fact that most containers where scrollable by default and brought a huge update cost. For a time my job was to convert components written by a visual developer in mxml into custom components written in AS3. I knew the runtime model pretty well and was able to layout complex components in code. These had the benefits of not being nested into multiple UIComponent containers/component layers which all hooked into the UI update loop. Ah good times :)
XAML is still very much a thing on Microsoft platforms, and contrary to your assertion, it still works very well. I would even go so far as to say that WPF (the original XAML-based framework) is still the best UI framework around if cross-platform is not a requirement.
It's funny because it reminds me of Angular in that it's very markdown heavy with the code behind in another file. So they wrapped React to make angular.
angular was dead on arrival - to me - because it seems nuts to bolt on full programming language constructs into html attributes. In the same way React easily won because it chose the exact opposite: put the UI constructs inside the full programming language.
Both have their worts, but I'm perpetually puzzled by how angular ever made sense as ergonomic. I suppose people like Vue so there's still some insistence on augmenting templates with programming constructs. Seems inevitable that templates will want more and more powerful constructs... and boom.
I think Angular "won" a lot of users because it confused a lot of people by calling its templates .html files that designers could work in them without needing to know how to program. Then once they were in those HTML files they were trapped by all the nonstandard attributes. It was a fascinating bait-and-switch to watch middle management get trapped in, I saw it play out a couple times in slightly different but ultimately the same way.
With React those sorts of "I'm only comfortable with HTML" (or "I'm only comfortable with Figma but it gives me HTML") designers often know that they don't like JS and don't want to work in JSX files directly. If middle managers are looking for "efficiency and synergy" the "my designers won't work directly in React" problem looks a lot like a "let's use Angular for everything because I'm told it is 'just' HTML" solution, with the trap being set that Angular's template language is complex and confusing and still a template language despite being in files labeled .html. Then once trapped the sunk cost fallacy strikes hard because "everyone already knows Angular" (despite no one actually "knowing" Angular, they know HTML and fight the template language to get something that sort of works some of the time).
At least Vue tends to prefer .vue for its single-file components. It's not directly the same bait-and-switch.
At my first job, our most senior developer and my mentor was huge on Flex and instant it was going to be the next big thing.
At the time I thought it was inflexible to style and felt very non-native.
To be fair, it had its moment, moreso in desktop applications than on the web. I seem to remember a lot of installers being developed in Flex. The iPhone showed up just in time to kill it before it ever got its footing on the web.
And coldfusion shudder
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!
The funny thing about this - and I don't know whether this is as good or a bad thing - is that you could probably almost implement this XMLUI entirely in React/JSX.
Glancing over the markup, none of this seems too alien to React.
This all seems not too dissimilar to the generic pages-as-JSON DSL that every CMS/developer reinvents every other project.
It is implemented using React.
> XMLUI wraps React and CSS and provides a suite of components that you compose with XML markup.
code currently only works on JS evergreen browsers. i guess like VB only worked with windows and if shipped with the right DLLs.
Windows is a narrower platform than evergreen JS-enabled browsers, and the relevance of Windows as a platform is only going to go down. So the choice of the platform is right.
What are some GUI-enabled devices you wish you were able to address, but which cannot run Firefox, Safari, or a Chromium derivative?
So, exactly like VB? (From memory it required a msvbvm DLL).
VBRUN300.DLL
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.
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.
I've been writing a UI framework for experiment automation and small tools using Qt Widgets with Python bindings (https://puzzlepiece.readthedocs.io) and it still works pretty well! I like the API, and it being immediately cross-platform is very useful. It does lack looks on Windows a little imo, but to be honest I'm not opposed to the utilitarian way the apps end up looking.
The 'Fusion' style on Windows looks a bit slicker than the base Windows style IMO.
I always wanted to check out https://qskinny.github.io/ it looks compelling and sticks to c++
Hah, that is awesome. How does Qt fare these days in the non-Linux world though?
This weekend I asked Gemini Pro to create a Python Qt app (a serial file sender- something you'd use to send g-code files to a CNC machine or laser cutter). I did most of the dev on Windows but the app will run exactly the same on all 3 main platforms. Eventually I asked Gemini to extract the UI to its own .ui file, which it did. The resulting app worked better than the previous one I had coded myself (handling some various race conditions and other challenging issues much more quickly than me).
If I wanted, I coudl ask gemini to port the app to C++. (Gemini isn't the point here- that's just speeding up what I would have done on my own).
Good on Windows. Pretty good on Mac, but never quite looks 100%. Not sure how well Qt is going to cope with macOS 26 style transparency though.
Nearly every widely-used commercial or in-house tool in the VFX and Animation sector of M&E are Qt based. The main difference compared to tradition desktop developers is the general attitude of design; the industry takes the stance of providing the same application experience across platforms, rather than trying to adhere to each platforms' UI/UX guidelines.
Examples: Autodesk Maya, 3DS Max, Mudbox Foundry Nuke, Mari, Katana SideFX Houdini Substance Painter, Designer
I believe the Blizzard game launcher uses QT?
Blizzard to me has always had the best execution of UI in their software/games.
Curious if there are any Qt projects you’d single out as being great?
I didn't know Blizzard uses Qt! In terms of some good Qt apps, VirtualBox remains my favorite.
AFAIK GOG Galaxy also uses Qt. In a game dev studio i worked on a few years ago the engine's editor was also written in Qt.
The Telegram desktop app also uses Qt Widgets.
XMLUI has 3%-4% of the features in designer. They have to catch up with 30 years first until it's worth a second look.
And wxwidgets and glade files...
I am simultaneously in the seemingly opposite camps of "haha we reinvent HTML lol" and "Actually this sounds immediately useful to me".
To be human is to be multitudes.
"Only that, which carries contradiction within itself, is alive."
- G. W. F. Hegel
Thank you putting me onto this concept. I had not heard of Walt Whitman or his work before.
"Do I contradict myself? Very well, then I contradict myself."
Beautifully said. All that matters in the end: will it be immediately useful to people like you who imagine that it might be?
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.
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?”
I have switched to JUCE as a total cross-platform GUI/high-performance general application development environment, having used it for 7 years in the audio realm I have attained that state, whatever it is, where I realize I can just use it for everything and it’ll be perfectly fine.
Doesn’t take too much CMake wrangling either, and once you’ve got at least one half-decent, clonable JUCE -> CI pipeline working, the horizon gets wider and wider ..
That said, I have to admit that I think more and more about how fun it’d be to just put all JUCE GUI code in a Lazarus’ish front-end, using LUA for that part, and having a decent half Lua/half C++ monstrosity for doing things ..
Is it still not possible to use JUCE for free/open-source without the pesky "Made with JUCE" popup? Or did they remove that?
The splash screen is a condition for using JUCE for free under the AGPLv3 license, particularly when distributing open-source projects or plugins without purchasing a commercial license.
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).
I've never used JUCE before but I agree that the imperative approach, while often larger in implementation, is usually very explicit about what is happening and allows full control. Declarative approaches always need escape hatches, and those escape hatches are usually tricky to open and pass through.
As a counterpoint, being primarily a web developer (although I did Windows desktop apps with Delphi in the 90s) I hard time doing UI with JUCE.
It never really clicked with me and I had a hard time really aligning things, with their Flexbox thing etc, how you set graphic values outside vs inside component classes, being sometimes confused how paint() vs resized() affect things etc.
Probably operator error but in the end I was happy to ditch it for the new WebView option in JUCE 8.
JUCE 8's WebView is an abomination that tarnishes an otherwise amazing framework.
Yes, coming from the web, JUCE' Flexbox and paint()/resize() semantics are going to be 'weird' - but thats the point. You have the power to decide when/how to update your GUI, frame by frame - and for high performance GUI's, this is vital.
These days it has to be said: you can get a LOT of your JUCE GUI work done for you by an LLM with great results.
Maybe but I actually got a ton of hallucination about the JUCE API with LLMs, as in they sometimes would just not produce workable code at all and invent functions repeatedly (endless infamous "you're right!").
My project is not a typical audio plugin so it's also why I was not benefiting as much about the graphic API as others may do.
But I'm not sure how the WebView is an abomination, it's actually a quite small API that works ... and is totally optional and didn't replace the original graphic API.
The WebView is not great for realtime UI's and encourages all the mistakes of the Web, in a realtime environment.
Sure, its optional, I suppose that is a benefit.
JUCE is also slow as heck and takes a lot of know-how to make performant. Notably, if you want any kind of real time animation or display, you don't do anything component based.
It also involves a custom C++ module system and build strategy that is hard to make fast and generally is impossible to use JUCE as a library, so you wind up recompiling it as a dependency an excessive number of times (which adds up in CI).
React itself was class based in the beginning, and that would have probably been a better model in the long run - it was a lot more code for sure, but less complexity.
This is definitely debatable. I grok the composable functions model quite well, and hooks let you separate logic out of components extremely well and intuitively once you understand the basics of React.
By comparison, I feel class component's promoted 'mile high' components where everything was inside of the class, which has many enormous drawbacks, one of the biggest being maintainability.
To this today though, I feel most people don't understand the simple rule of UI is the last mile concern. Developers still cram way too much into components rather than separating layers of concerns
Can anyone with experience share more about JUICE and accessibility?
It just works, in my experience, with Narrator on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. The graphical component editor lets you set stuff like labels and tab order and that's usually enough to make things work at least okay with a screen-reader. Getting things to work A+ requires more manual effort, such as implementing AccessibilityHandler for complex components. But the basic JUCE classes are usually much better than what you'd get from any "JavaScript inside WebView" GUI, precisely because you manually coordinate the presentation and the screenreader texts.
I've worked on Surge, which is (to my knowledge) the only fully accessible synthesizer. It uses Juce's a11y abilities to do this work, plus a whole lot of very thoughtful design. We have multiple blind users.
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.
0: https://www.xml.com/pub/a/2003/08/13/udell.html
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.
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.
Not sure what you mean by licensing failure or “one liner”. Browsers are natively limited to XSLT 1.0 not because of licensing, but because they simply didn’t want to implement the newer versions. However Saxon offers free XSLT 3.0 processors for JS, C, Java, and .NET, so there’s not really a limitation to doing modern XSLT development.
Licensing is just another aspect of friction, contributing to everyone sticking on 1.0 and making it annoying for anyone trying to move forward with XSLT. One liner is a lack of procedural logic in its implementation. Its fine for 1-1 mapping but as it gets used in more complicated scenarios it can be hard to developers to architect a solution because there's no space to breathe.
What specific licensing problems are your referring to that supposedly hold back XSLT? It’s an open spec, anyone can implement it, and there a free processors under MPL license.
And what specifically do you mean when you say everything has to be processed as a one liner? I’ve never used an XSLT processor where that was true.
To gain access to the better toolset you need v2 and v2 costs. Maybe the org doesn't have it, maybe getting a PO for it is annoying, maybe there's friction around getting it installed on a customer site. Perhaps its just a factor which resulted in everyone else sticking on 1.0. But it never took off in the way promised because of it.
That it is a fiercely declarative language makes it hard to integrate. Often developers are placed within an architecture that gives them limited options and only being able to use XSLT while trying to integrate other network calls or services is non-trivial and a complete headfuck sometimes, compared with more general purpose languages like python or javascript.
You are misinformed about license cost, as I’ve already explained in multiple comments.
Hard to integrate in what way? XSLT is a language focused on several things that it’s very good at but it’s not intended to replace Python or be a general purpose language. Yet there are many common data related tasks where a messy and hard to maintain pile of imperative code can be replaced with a simple XSLT.
I'm talking about the cost as being friction that resulted in 1.0 being so dominant and 2.0 being scarce.
Not everyone gets to pick and choose how they use XSLT. Place I used to work, the services team used to have a sign:
> [X] Days since last custom report
They hated it and I can't blame them, making a series of soap calls, consuming the most degenerate api ever written and generating a document for the customer was a pain. Bear in mind this was an enterprisey "do everything system", oversold by sales and the services team had to use XSLT to bridge the gap between customer expectation and what the salesman sold them.
What they needed was a host for a general purpose language, what they got was XSLT.
You might want to check the username of the person you arr responding to.
its just a name. They keep sealioning me anyway, as if XSLT isn't worthy of any criticism.
Reinventing XML traversal/transformation in JavaScript will lead really fast into abstracting away the recursive tree traversal, then mapping node marchers to functions. Which is 99% what XSLT provides off the shelf.
many developers just want to have some space to do some extra logic and XSLT doesn't really accommodate for that. You have to deal with the input and create the output without pausing for breath. While this is fine in simple use-cases where the mapping is 1-1 but when the mapping gets more complicated then it becomes difficult to maintain.
That’s simply not true. Certainly it can be hard to wrap your head around architecting complex logic in XSLT 1.0, but it's not unlike how you have to change your thinking for functional programming generally. More ergonomic imperative logic and several other features in XSLT 2.0 made it a much more developer friendly language.
Most orgs don't transition to 2.0 which is a big part of why XSLT sucks.
> but it's not unlike how you have to change your thinking for functional programming generally
I'd write lisp any day of the week over XSLT. I don't think XSLT deserves a place alongside other functional languages because its bound so tightly to xml. Sure, one can argue it has its place when processing XML but I'd pick a general purpose language and process XML with that over XSLT every time.
You keep making assertions and generalizations without backing them up with anything concrete while simultaneously moving goalposts. In the cases where you do, you’re just wrong: XSLT is not held back by licensing, it doesn’t “require one liners”, and it has supported JSON since 3.0, which has been around for almost a decade.
why the fuck would you want to use it with json.
XSLT was held back by licensing, its why everything supports 1.0 and barely anything supports 2.0. If 2.0 was released for free then everything would use 2.0.
Why wouldn’t you just Google instead of repeatedly insisting on things that are wrong?
https://www.npmjs.com/package/saxon-js https://github.com/Saxonica/Saxon-HE
well then tell me why .NET's XSLT platform is rooted in 1.0 instead of just saying "no". From my understanding licensing was a factor that played into the reasons why .NET natively remains on 1.0. The transition to 2.0 appeared to have specific friction: why?
for reference: I'm not talking about today, I'm talking about that point in time where (for example) .NET could have adopted XSLT 2.0 but chose not to.
.NET didn't transition to XSLT 2.0 for the simple reason that demand wasn't really there. The way they saw it, LINQ was a better all-around option, with XLINQ specifically being an adequate replacement for XPath, and VB even got a bunch of special syntax to work with XML that made it more concise than XSLT in many cases: https://learn.microsoft.com/en-us/dotnet/visual-basic/progra...
That said, it is emphatically not true that XSLT 2+ was somehow license-restricted. I worked at a company that used XSLT 2.0 and XQuery for code generation back in 2006, and we used the free edition with Saxon with no issues - paid versions had some optimizations and features like static type checking which we simply didn't need.
For the most part, XSLT 1.0 was "good enough" for most cases when XML was still the primary interchange format, and later JSON took over so there was less incentive for framework providers to spend resources on keeping up-to-date with the standard. Especially since XSLT 2.0 was such a massive leap in many ways, including a different data model that made many existing XSLT 1.0 processors incompatible in ways that required a massive redesign.
Thank you for the correction <3.
I wrestled with how much history to bring into this because I want to look forward not back. The purpose of the announcement is to encourage people to try the tool and find out for themselves if it is a productive way to build the user interfaces they need.
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.
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.
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.
You're basically correct, but this isn't due to a philosophical choice. Simply speaking, XSLT stopped evolving before Ajax really got popular, and it was eventually purged from most browsers altogether on security grounds. So nobody really tried to build XSLT engines that could address modern use-cases.
Somewhat ironically, the semantic web was initially supposed to be built on browsers making calls for XML data (the X in Ajax) to then be displayed via XSLT. This model failed to gain adoption mostly because, let's be honest, XSLT is just blooming hard.
I don't think it was ever "purged" - I mean, which modern browser doesn't handle XSLT 1.0?
Nor did the spec itself stop evolving. The problem is that the browsers have deprecated the technology before XSLT 2+ could be adopted.
> which modern browser doesn't handle XSLT 1.0?
I know it depends of the definition of "modern browser", but I'm fairly sure that MSIE and pre-chrome Edge had lost support for it at some point, since MSXML stopped being shipped with them.
I honestly don't know what the current state of the art is, but Firefox doesn't do native XSLT anymore afaik (yes, you can do it in JS, but it's an extra step).
Recreating whole documents is how XSLT has been commonly used, but that’s an implementation detail, and you can nearly as easily write XSLT to produce components. You can output XHTML components and update the vdom - kind of an abstraction leak but not a bad tradeoff if you want to reuse the rendering XSLT. Alternatively, XSLT 3.0 can produce (and consume!) JSON, so you can use it as way to bridge XML into a traditional React app or to simply process JSON.
When I discovered oleh kiselyov's SXML/SSAX. It is such a amazing way to work with xml that I simply stopped doing xslt all together.
SSAX is probably the best xml parser I have ever used.
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.
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.
The example looks very minimal and neat by modern standards, shows how much messier modern websites are, I had to even think where is the "wtf".
The performance of available XSLT translation engines would be a big consideration for me, especially in a hot-reload context to support fast iterations.
That was my first thought: no XSLT 3 engine that I know of keeps an in-memory object that supports iterative retemplating on diff changes to the source. I think the closest to this is in the functional communities and their lenses. Given how "far" XSLT can reach through a document via Xpath, I don't think it's an easy-to-solve problem.
>No mention of XSLT?
Nope, but they sure had to make 1/2 the content about "AI" (otherwise nobody would read it?).
I remember Blizzard games' website were built by XSLT before, those websites were impressive.
if the target audience is 'citizen developer', aka Visual Basic (classic), I am not sure introducing XSLT is such a good idea.
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.
1. https://en.wikipedia.org/wiki/MXML
2. https://apache.github.io/royale-docs/features/mxml
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'm sure Microsoft hopping from one XAML implementation to an entirely new one every five years didn't help either.
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.
We would love to know how that goes.
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.
Gonna echo what someone else said, I can’t seem to fit the whole page text on my phone in portrait orientation.
Your idea sounds interesting but your site is unreadable on mobile (Android+Firefox).
This sounds exactly like Zope's DTML template language, from 25 years ago. https://zope.readthedocs.io/en/latest/zopebook/AppendixA.htm...
Hi, cant read your site? other comments arent loading on my HN app so not sure if other people have same issue. Mobile firefox
I can't fully see the text on mobile, the beginning is cut off and zooming out doesn't help. Just so you know. :)
I think this could catch on, very much like C++ caught on. It’s very powerful to be backwards compatible.
Impressive that they note:
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?).
It’s painfully slow (on a newish mobile). While the concept is great for dynamic data, static docs are a terrible use case.
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.
XMLUI does not execute JavaScript with "eval" or anything that would not comply with CSP. It runs interpreted JavaScript asynchronously in a sandbox and does not allow use of "eval" (and another dozen low-level functions, such as setTimeout).
So the project has implemented a custom JavaScript parser and evaluator in TypeScript?
that is insane.
Just ship https://github.com/NeilFraser/JS-Interpreter and you’re good to go! /s
As a follow-up: Angular actually did this! https://docs.angularjs.org/guide/expression
> AngularJS does not use JavaScript's eval() to evaluate expressions. Instead AngularJS's $parse service processes these expressions.
Note that those are the AngularJS aka ”Angular 1” docs.
For Angular as in ”Angular 2” docs, see https://angular.dev/guide/templates/expression-syntax
Looks like they actually went this route, but implemented it from scratch.
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.
I like what RJSF did with uiSchema[0] for their presentation layer (to supplement the jsonSchema model definitions).
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...
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.
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.
> 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.
It's important to note that pretty much nobody used the visual designer though. The resulting xml was pretty terrible, writing the UIs manually (in xmls, while looking at preview) was infinitely better
That's just Android though. A good example of doing this well is JavaFX with Scene Builder. The XML corresponds to the UI tree 1:1 and the designer makes XML that looks hand written (or vice-versa). FXML is also a pretty intuitive schema and there's a dialect of CSS intended for UI that I find more intuitive than web CSS.
Plenty of apps used the visual designer. You could tell because the UI would be a right mess the moment you didn't use the app on a screen that matched theirs.
Good apps were using semantically correct design layouts but there were, and still are, tons of bad apps out there, just like there were a ton of VB6 applications.
> 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.
There is also Lazarus[1], which uses Pascal but feels closer to what I remember of the VB6 experience.
1: https://www.lazarus-ide.org/
> but the experience was pretty good.
Our experiences do not match. I used Borland Delphi to build business apps 20 years ago just using the UI builder. I've been using Android Studio to build apps at FAANGs for 10 years now and I cannot remember the last time the Design tab was useful - it was always faster and more reliable to just edit the XML file.
Yes, Delphi didn't do resizing windows and crashed half the time, but I was pretty happy with the WYSIWYG / UI building functionality for production apps.
Android Studio's UI builder is nowhere near that level of usefulness. I have a hard time believing anyone is using the UI builder in Android Studio for anything other than tutorials or entry level Android apps. It doesn't render the layout properly 90% of the time, or just renders some placeholders with no content and calls it a day.
For a modern IDE, Android Studio is somewhere between just OK and bad, mostly because it has features the other IDEs didn't at the time, but the dev experience is behind Turbo Pascal in the 90s on MS DOS. The editor is laggy. The debugger is slow and hangs often. The list goes on, but I'll stop the rant here.
Android Studio had the exact WYSIWYG experience other toolkits used to have, it was just hidden behind an <AbsoluteLayout> because designing mobile applications the way desktop applications used to be designed is an awful idea.
Drop an AbsoluteLayout into a design and you can drag, drop, and resize buttons to your hearts' content. You'd have the same problem with VB6 where your buttons would fall off the screen if someone ran your application at a lower resolution than you designed it for, but that was never a problem for the desktop designer.
For the same reason dumping buttons on an arbitrary coordinate and resizing by eye is no longer acceptable on desktop, that same ease of design died out in Android for any serious application developer. It stuck around a while longer on desktop, unfortunately, but modern frameworks pretty much all use declarative layouts these days.
Lazarus is pretty much an exact implementation of Visual Basic, just mapped to FreePascal instead of VB
Lazarus is a very faithful clone of Delphi, which is the Pascal-based main competitor of VB of the time.
an exact implementation of Delphi, I would say.
VB didn't create those terrible programs, I did.
I don't mind XML but the release is 4.23 MB. Minified. There are 90 dependencies (931 fully resolved).
Also, the Docs link to home.xmlui.com and don't resolve
We will soon have a way for standalone apps to shed unused dependencies, just as the build for the docs site does.
Thanks for the 404 heads-up.
This looks similar to React application frameworks like react-admin [1] or Refine [2]:
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.[1]: https://github.com/marmelab/react-admin [2]: https://github.com/refinedev/refine
> 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
The VSCode extension can help with some of that: https://docs.xmlui.org/vscode
how do u like jsx then?
JSX has all the tooling available.
Those who do not understand (or remember) XUL are forced to reinvent it.
see https://www-archive.mozilla.org/xpfe/xui.html
Pretty sure Jon Udell remembers XUL.
I do indeed.
/me feigns shock
Using XML to declaratively define UI trees is an idea so obvious that many developers back in late 90s - early 00s had their own bespoke frameworks for that.
And you know what? It worked great. WPF with XAML - from 2006 originally! - is still, to this day, by far the easiest way to write a desktop Windows app with adaptive layout etc.
If XMLUI is a reinvention of XUL, then XUL* is just a reinvention of the many XML-based UI markup languages before it.
* Fun fact: XUL was conceived at Netscape. Mozilla adopted it for XPFE.
XUL was conceived by Dave Hyatt FOR Mozilla AT Netscape. Netscape was going to end development of not-Windows Mozilla because maintaining 3 front-end teams was more than the Netscape/Mozilla leadership believed it had resources for and XPFE was the solution.
If you believe XUL was developed for anything other than Mozilla's XPFE, you have been mislead.
Also, would you please provide names for those many pre-XUL XML-based UI languages I'm genuinely curious. Other than the web itself, HTML+JS+CSS, I'm at a loss for what those many XML-based UI markup languages you're referring to could possibly be. As a Mozilla participant at Netscape, and someone with hours of discussion with Hyatt over those early years, and a (very small) contributor to XPFE as early as Dave's XUL menus first draft, I'd be real interested to learn about prior art. Did we somehow miss all of those per-existing examples?
XUL was created by Netscape employees for Netscape's XPToolkit project¹. I didn't think that saying that "Mozilla² adopted XUL" would be considered controversial or somehow denigrating, so apologies if if came off that way.
AOL acquired Netscape in 1999, then became the first company to ship XUL as part of Netscape 6 in 2000. https://en.wikipedia.org/wiki/Netscape_6#:~:text=With%20publ... AOL abandoned XUL to the Mozilla open source community not long after, when they disbanded the Netscape team in 2003.²
> Also, would you please provide names for those many pre-XUL XML-based UI languages I'm genuinely curious.
WML, XFDL, and Glade XML all shipped in 1998, two years before Netscape 6. Adobe's XFA also shipped before Netscape 6.
¹ https://www-archive.mozilla.org/xpfe/whoswho ² at the time meaning, "the software suite formerly known as Netscape Communicator" ³ https://www.mentalfloss.com/article/502789/day-2003-netscape...
React is so unnecessary. Would make more sense to do this with web components. The event model of VB, before .Net, was much more coherent.
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 read that as Haskell and I definitely think HaskellUI would solve all problems. /j
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.
You're forgetting the state management required to link the components. Here's a take (by Claude) on what it would look like, even if you ignore the entire `useDataSource` implementation it's an entirely different beast:
https://gist.github.com/ricardobeat/8aedb9c6d3a1b0bfaba9cc55...
> exercise for the reader
The demo app shows a bunch of patterns. https://docs.xmlui.org/tutorial-01
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...
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.
Related: Flutter based fml.dev.
Example:
So you built a worse alternative to React, on top of React?
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.
To be frank, this would likely not help you. A simple web page is effectively simpler XML as the HTML elements that are already there are quite enough.
I might be completely off the mark here (edit while writing the comment, considering you mention static HTML I probably am, going to leave the comment anyway for others to see), but considering you seem to think that you need React (or any javascript for that matter) to me seems to hint at a practical knowledge gap about HTML and webpages in general.
Which, is more common these days exactly because modern libraries effectively abstract it away to the point where people only see HTML when looking at the DOM representation in the browser devtools.
> 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),
It is interesting to me how we effectively regressed here. At least as far as common knowledge goes. You can still go to a basic shared webhosting provider, get a domain, some storage, mysql/mariadb datbase, php and do all of that with relatively little effort. Of course, PHP isn't considered to be relevant anymore which is entirely fair. But it is by far the most straightforward way to get a website going with an actual backend that doesn't require you to do cloud wrangling and all that.
Yea, I am indeed quite deficient in HTML knowledge and webpages in general. I'll look into PHP, thanks. Overall I have standards (that might be unachievable?) that I think tools should aim to be extremely simple if at all possible (at least there should be niche tools that achieve this, I mean), and what I've seen from web development doesn't quite meet those goals :P
I really like OpenSCAD for instance, which despite being a little difficult to do complex stuff with, is quite easy to learn (and you can indeed do complex things with a little methodology). Like, everything about the web seems a little obtuse to me. One day I'll learn a little more to hopefully make more educated comments :)
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.
Great point!
This reminds me of XForms and its fully declarative approach. It allowed you to add interactivity to your HTML without writing code.
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.
Again I don't expect people under 45 to remember how easy it was to develop a user interface that reacted to user actions.
This recent HN submission gives a pretty good idea: https://news.ycombinator.com/item?id=44621102
Let's be honest, XUL was a pain for a number of mozilla-specific choices (rdf...). A lighter, better XUL would be absolutely fine.
I think Flex was that better XUL
reminds me of Macromedia MXML (used in Flash, Coldfusion and Flex)!
https://github.com/apache/royale-asjs/blob/develop/examples/...
I was thinking the same thing. Programmed ColdFusion for over a decade and loved the language, however I moved onto .NET, the PHP and now Rails. ColdFusion was a wonderful language, but the frameworks weren't there and the market share wasn't there either. Ironically enough, one of my clients still uses it for their application and we actually began talks about moving them over to Rails.
OpenLaszlo was an eariler, more powerful, more fun, open source alternative to FLEX. It's obsolete now that Flash is dead, but I really got in the "zone" with it.
Residential, Commercial and Industrial zones:
https://www.youtube.com/watch?v=8snnqQSI0GE
https://github.com/SimHacker/micropolis/tree/master/laszlo/m...
Here's some stuff about OpenLaszlo and other related ui systems:
https://news.ycombinator.com/item?id=21841054
DonHopkins on Dec 20, 2019 | parent [–]
My remark was just an old Java joke I repurposed for Ant! "Java is a DSL for taking large XML files and converting them to stack traces." -Andrew Back
https://www.reddit.com/r/programming/comments/eaqgk/java_is_...
But in all seriousness:
OpenLaszlo used XML with embedded JavaScript in a way that let you extend XML by defining your own tags in XML+JavaScript. I've done a lot of work with it, and once you make your peace with XML (which seemed like a prudent thing to do at the time), it's a really productive enjoyable way to program! But that's more thanks to the design of OpenLaszlo itself, rather than XML.
https://en.wikipedia.org/wiki/OpenLaszlo
OpenLaszlo (which was released in 2001) inspired Adobe Flex (which was released in 2004), but Flex missed the point of several of the most important aspects of OpenLaszlo (first and foremost being cross platform and not locking you into Flash, which was the entire point of Flex, but also the declarative constraints and "Instance First Development" and the "Instance Substitution Principal", as defined by Oliver Steele).
https://en.wikipedia.org/wiki/Apache_Flex
https://web.archive.org/web/20190318072102/https://blog.oste...
The mantle of constraint based programming (but not Instance First Development) has been recently taken up by "Reactive Programming" craze (which is great, but would be better with a more homoiconic language that supported Instance First Development and the Instance Substitution Principle, which are different but complementary features with a lot of synergy). The term "Reactive Programming" describes a popular old idea: what spreadsheets had been doing for decades.
OpenLaszlo and Garnet (a research user interface system written by Brad Myers at CMU in Common Lisp) were exploring applying automatic constraints to user interface programming. Garnet started in the early 1990's. Before that, Ivan Sutherland's Sketchpad explored constraints in 1963, and inspired the Visual Geometry Project in the mid 1980's and The Geometer's Sketchpad in 1995.
https://en.wikipedia.org/wiki/Reactive_programming
http://www.cs.cmu.edu/afs/cs/project/garnet/www/garnet-home....
https://en.wikipedia.org/wiki/Sketchpad
http://math.coe.uga.edu/TME/Issues/v10n2/4scher.pdf
https://en.wikipedia.org/wiki/The_Geometer%27s_Sketchpad
I've written more about OpenLaszlo and Garnet:
What is OpenLaszlo, and what's it good for?
https://web.archive.org/web/20160312145555/http://donhopkins...
>Declarative Programming: Declarative programming is an elegant way of writing code that describes what to do, instead of how to do it. OpenLaszlo supports declarative programming in many ways: using XML to declare JavaScript classes, create object instances, configure them with automatic constraints, and bind them to XML datasets. Declarative programming dovetails and synergizes with other important OpenLaszlo techniques including objects, prototypes, events, constraints, data binding and instance first development.
Constraints and Prototypes in Garnet and Laszlo
https://web.archive.org/web/20160405015129/http://www.donhop...
>Garnet is an advanced user interface development environment written in Common Lisp, developed by Brad Meyers (the author of the article). I worked for Brad on the Garnet project at the CMU CS department back in 1992-3.
More about TCL/Tk, OpenLaszlo, Garnet, constraint programming, history of constraints: Coco KVO, Objective Smalltalk constraints, Sutherland, Sketchpad, Geometers Sketchpad, Knowledge Representation frames, push vs pull constraints, etc:
https://news.ycombinator.com/item?id=17360883
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.
Was NSIS too limited for your use case?
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.
While flexbox is more powerful, those semantics would require prior knowledge of other CSS attributes and to develop an intuitive understanding of them.
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 )
Alan Kay in 1997:
> I really would like you to contrast that with what you have to do with HTML on the Internet. Think about it. HTML on the Internet has gone back to the dark ages because it presupposes that there should be a browser that should understand its formats. This has to be one of the worst ideas since MS-DOS. [Laughter] This is really a shame. It's maybe what happens when physicists decide to play with computers, I'm not sure. [Laughter] In fact, we can see what's happend to the Internet now, is that it is gradually getting—There are two wars going on. There's a set of browser wars which are 100 percent irrelevant. They're basically an attempt, either at demonstrating a non-understanding of how to build complex systems, or an even cruder attempt simply to gather territory. I suspect Microsoft is in the latter camp here. You don't need a browser, if you followed what this Staff Sergeant in the Air Force knew how to do in 1961. You just read it in. It should travel with all the things that it needs, and you don't need anything more complex than something like X Windows. Hopefully better. But basically, you want to be able to distribute all of the knowledge of all the things that are there, and in fact, the Internet is starting to move in that direction as people discover ever more complex HTML formats, ever more intractable. This is one of these mistakes that has been recapitulated every generation. It's just simply not the way to do it.
And yet in the nearly thirty years since he said that, the browser has come to dominate how people interact with UIs. Both in terms of sheer popularity (not only do we have complex applications on the web, but we also package complex applications with browsers as desktop applications) as well as influence (SwiftUI, Flutter, and Jetpack Compose all borrow heavily from frameworks developed primarily for the web).
I think a lot of this has to do with the idea that Kay is criticising here: HTML as a mechanism for building applications has been so successful because it needs to be interpreted by a browser. That provides a tremendous level of sandboxing that makes it a lot easier to trust whatever website you're loading than the application you're installing. It also provides a grab-bag of useful controls and elements, while still being completely flexible with creating new ones without needing to resort to OOP inheritance chains or raw graphics drawing APIs. This is all to say nothing of accessibility, which is practically built into the browser.
> Full Browser window size cancas ... and draw everything yourself
This was already tried to some extent with Flash. Many sites were a single Flash module (or multiple). Implementing accessibility then required maintaining an invisible DOM representation of the Flash canvas. I personally don't want to return to the era where login and register buttons were dedicated Flash modules (MegaUpload did this back in ~2009) and many sites were an 800x600 image using the <area> tag for hitpoints.
Even Flutter has a DOM target because painting to a full <canvas> violates at the very least the operating system's text rendering, scrolling, and accessibility.
I agree with you that these things are important. However they are ( in implementation terms ) rather small issues, and determining i rather pay 4-8x more in development and maintenance costs just for this, while you can go the other way and make those features a bit hardware to implement seems like a not so good business case to me.
e.g we are using Avalonia. Of course everything is drawn in a scalable way, with responsive design etc... Accessibility is built in of course ( with integration with the relevant browser apis ) screenreaders work perfectly as do other accessibility features ) Its not the hap hazard way that flash did this (before there were relevant standards for these features anyways ) Invoking a brower api / interop is easy, the difference is we do not need to compromise our productivity for small things.
Flutter sadly deprecated the DOM renderer: https://docs.flutter.dev/platform-integration/web/renderers
I would be so happy with inline-rendered, unblockable ads, always slightly different input/gesture handling and no accessibility!
Bye bye ad blocks?
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.
We are aiming for people who not only don't want (or are not able) to learn/write React, but also CSS.
My recollection of XUL was that it was great when it worked, but horrific to debug.
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.
It was pretty easy to debug most of it with Dom Inspector and Venkman, themselves written in XUL. Even the XBL bindings and other sometimes challenging bits, were directly inspectable and editable. As a minor contributor to Mozilla's early XUL work and later Firefox's XUL work, mostly stripping XUL overlays and reducing clutter in the Firefox case, it seemed pretty straight forward to me.
> 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.)
1. <https://www.youtube.com/watch?v=8ZlN07IvoPI&t=2131s>
Great points! I love Nic Barker's frantic hand gestures while he explains how React works in that video. "Oh gosh, you don't want the hear this! Ha ha *grin*!":
https://youtu.be/8ZlN07IvoPI?t=2654
There was an interesting hn discussion about immediate mode a few years ago:
Immediate mode GUI
https://news.ycombinator.com/item?id=19744513
http://behindthepixels.io/IMGUI/
I wrote up some of my own opinions:
https://news.ycombinator.com/item?id=19745034
>DonHopkins on April 25, 2019 | parent | context | favorite | on: Immediate Mode GUI
>Immediate mode GUI's don't let you apply useful object oriented programming techniques like subclassing and prefabs (persistence) to implement and configure custom components.
>Properly object oriented retained mode GUIs let you subclass components to implement custom views and event handling, and develop and publish reusable prefabs and libraries of pre-configured, stylized, specialized component. [...]
>I don't know what you mean about easily composing immediate mode API's, or agree that different immediate mode APIs don't need to know about each other. They depend on a lot of behind-the-scenes implicit hidden state (practically a hidden shadow-DOM-like retained mode), so I suspect in many cases they'd walk all over each other (especially text editors dealing with input focus and keyboard navigation). Unity3D has two immediate mode APIs, one for the editor and one for runtime, and they sure don't mix. [...]
>How would you write a functional extension for Unity3D's old immediate mode GUI that let you embed an ACE code editor in a Unity WebGL app? What would the API and state management even look like? How could you make it platform independent?
>And even if you solved all of those problems with an immediate mode API, by its very nature it still wouldn't enable you to build GUIs in the interface editor or store them in prefabs, and you'd still have to recompile you app (which can take half an hour with Unity) every time you wanted to tweak the user interface (which is why I like programming Unity apps in JavaScript as much as possible). [...]
>Embedding object oriented "retained mode" widgets with different APIs inside of each other is old hat and common for backwards compatibility. Whenever you write a new GUI toolkit, embedding widgets from the last toolkit is one of the first things you do (including recursively embedding widgets from the toolkit-before-last).
>Concrete example: Microsoft lets you embed old fashioned OLE controls in Windows Forms / Presentation Foundation applications, which might be implemented in MFC themselves. And MFC is all about embedding old Win32 widgets implemented in C, and newer OLE components implemented in Visual Basic or whatever, in venerable C++ MFC user interfaces. Say what you want about how much Win32/MFC/OLE/WF/WPF sucks, and I'll wholeheartedly agree, but if you're running Windows, you probably have widgets on your screen using several different retained mode APIs embedded more than two levels deep right now. [...]
>The problem with immediate mode that is you have to come up with somewhere to store and retrieve any values or state required on a case-by-case basis (including the edited value itself, and other view state like scrollbar state for text editors, etc), and that tightly couples your component function with whatever's using it, so they're not very reusable or simple. With OOP, the object has its own place to store that stuff, which is cleanly decoupled from whatever's using the component.
>Then there's the issue of event handlers. Some user interface components just aren't so simple that they only have one true/false return value like buttons. Text editors can notify on value change, end edit, select, deselect, etc. And Unity's retained mode GUI supports persistent event handlers that let designers hook up events with methods of objects with parameters, without writing or recompiling any code.
>And there's also a lot more to layout that you can easily express with an immediate mode GUI. Sometimes you have to measure a bunch of things and align them in various ways, like grids or flex layouts, and adapt to the screen size and other constraints (i.e. responsive design), and that's really hard to do with immediate mode, while retain mode has a rich set of layout components you can use and extend. And there's nothing like XCode's layout constraints for immediate mode. [...]
>A perfect example is TextMesh Pro's text editor. It has so many different (and useful) features and parameters and callbacks and ways to configure it, and it keeps so much state in order to redisplay efficiently with the fewest number of draw calls and reformatting, that it would be extremely impractical and inefficient and unwieldy for it to use an immediate mode API. Especially with C# positional arguments instead of Pythonic or Lisp-like optional unordered keyword arguments.
>When you encapsulate your immediate mode layout in a class, or write an engine that interprets (i.e. JSON) data to drive the immediate mode API, or use reflection in your wrapper functions to dispatch event callbacks and bind your widget data to your model data, you're just rolling your own informally-specified, bug-ridden, slow implementation of half of retained mode. (See Greenspun's tenth rule.)
Well, yeah, obviously, somebody has to retain some state at some point. The nice thing about a good IMGUI is that it's easy to integrate with your own state-maintenance logic. It's all about separation of concerns.
In practice, every time I've built an IMGUI, it's always turned into some kind of hybrid immediate/retained-mode approach. There's nothing desirable about forcing the business logic to remember the state of a button on the screen, after all. It comes down to how easy it is to build and maintain the mixed-paradigm model that everybody inevitably ends up with anyway.
In the case of the last framework I put together, individual buttons can be treated as true immediate-mode controls, where hit-testing, labeling, and other interaction with the program takes place at render time, while button groups retain the necessary state to lay themselves out, handle mutual exclusion, and so forth. Nothing keeps the app from maintaining its own list of buttons and calling it a group or whatever, but if I don't need to do that myself I can let the GUI do it.
Looks like XAML https://en.wikipedia.org/wiki/Extensible_Application_Markup_...
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."
it reminded me of Adobe Flex (probably without its "bad" parts) - nice work, congrats to the developers.
Looks neat!
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.
> 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.
I do this for custom software I build for clients, mostly on the backend though[1]. Started it two years ago, have rapid velocity and, without AI generally take 30 to 60 minutes to implement a new feature that touches backend persistence and front end UI.
‐----------
[1] I did a show HN on a tiny front end component that gets the most use, recently, I think. ISTR most people in the comments said they they preferred React, a few said it was not novel enough to be a paper (they are correct. It isn't). You can see it here: https://github.com/lelanthran/ZjsComponent/
I'm not really in the mood to open up the whole stack I use yet, I still make money bu having a low effort way to build web apps, and due to the way it works it requires a fraction of the tokens required when actually using AI assist (output for the last time I implemented a backend call from scratch was 10 lines, most of which were comments).
You can also use WPF/Avalonia (.NET) or MAUI (.NET) You will see why XML for UI is beautiful but nightmare to debug if something is off and crashing.
Maybe I just didn't understand it but to me WPF felt like it was designed by an insane person.
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.
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.
Spreadsheet is a form of programming, so you can build anything there.
Spreadsheets traditionally don’t support iteration (loops) or recursion. In Excel you had to go the VBA route for actual programming.
In my hands they do
In other hands, I have seen Excel spreadsheet hundred-products pricelists become a freaking tangle of merged cells, multiple rows for products, spelling mistakes, multiple spaces everywhere, and price cells hand-formatted. And I had to export the contents to machine readable .csv...
That is the spirit.
In the distant future:
The future is now with Microsoft Excel Web Services, which is part of SharePoint.
https://learn.microsoft.com/en-us/sharepoint/dev/general-dev...
Not a common opinion, but one I happen to share.
Let’s see an HTTP server in an Excel sheet.
I didn’t check their claim, but https://github.com/michaelneu/webxcel:
“Webxcel creates a full-fledged RESTful web backend from your Microsoft Excel workbooks. It is written in 100% plain Visual Basic macros and comes with a lot of handy tools to help you build the next big thing.”
Ha! Sure beats the pure bash HTTP server. ;-)
Fairly sure Excel can get access to the entire .NET runtime.
Plus, someone made a MOV only compiler, soon...
https://learn.microsoft.com/en-us/office/client-developer/ex...
Calling user-defined functions (UDFs) from a worksheet is as simple as calling built-in functions: You enter the function via a cell formula.
That's a disingenuous take. You could write one, but it won't be allowed to connect to anything other than itself because Excel doesn't give it the network stack or IO it needs. Unless you use VBA, of course.
See https://spreadsheets-are-all-you-need.ai/index.html
Maybe just me but seeing side by side "spreadsheets are all you need" and ".ai" seem to be somewhat uh... competing claims.
It's a play on "Attention is all you need", the seminal AI paper.
The author of that website implemented GPT-2 inference on Excel
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.
Html tables are very different from excel tables. Fundamentally html tables were used because rows are a good way to split up the page vertically (you could have one row for the header, one for the content one for the footer). And columns are good for splitting it up horizontally (you could have one column for the side panel, and one for the content, and the last one for an obnoxious blinking ad).
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).
Div tags were widely spread by 2010, though.
We were pretty far past the era of falling back to tables by that point.
Also 1x1 pixel spacer GIFs.
IE6 forced us to do crazy stupid stuff, like <div> </div> - and don't even start talking about <!-- ie "preprocessor like directives" -->
If we somehow manage to solve the two main spreadsheet downsides (imo): testing and change/version control, then spreadsheets would be a terrific programming paradigm.
As it is now I find it very powerful and empowering, but also scary.
I took a graphics programming class where one dude did a bunch 3d rendering stuff in excel.
Rather than try to understand, I decided he was into witchcraft.
IIRC, for a long time in the late 90s, Fedex was glued together with spreadsheets.
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.
I don't agree. Rather than breaking down, abstractions in UI have stabilized and centralized. Everyone uses React.
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.
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.
XMLUI reminds me of XUL (XML User Interface Language)
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.
XUL! why not just use htmx and the platform?
Because using htmx is asking to get defaced via XSS, or worse. Security is an afterthought for the project, which is evident from the placement of the related documentation.
security rules for htmx are no different than any other hypermedia approach: you need to escape all user content
https://htmx.org/essays/web-security-basics-with-htmx/
How is this better?
It probably isn’t.
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.
It seems a little strange to accuse jquery. I think what actually "killed it" was modern HTML. Jquery was just an intermediate API that let you target modern browsers and IE without having duplicate/shim code to maintain yourself.
That's why I said "think"
Many projects have tried this approach over the years (which means it is not a bad idea).
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.
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.
2005-2007 I worked on a webapp where the app layer rendered to XML, and then optionally server-side applied an XSLT transform to generate either HTML, RSS, or Atom, but you could also request the raw XML (and browsers could apply the XSLT client side, but for debugging/testing it was great to be able to then also see the underlying XML.
It had some benefits in terms of enforcing strict separation as well, but it was also painful to deal with the many deficiencies of XSLT (e.g. try reformatting dates...) that meant the XML ended up having annoying redundant values where it was easier to provide multiple versions of the same value than doing the conversions in XSLT.
These days I'm doing something similar by having apps return JSON and having the I built dynamically from the JSON with javascript, and I like that better than the XML => XSLT as much as "in principle" I agree with you that the pure approach of XSLT feels "correct". It's just too painful to apply as-is.
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.
Here's the How To for that: https://docs.xmlui.org/howto#set-the-initial-value-of-a-sele...
Our hope is that by building up a set of these patterns, and making them available to agents via MCP, it will be as easy as possible to get things right.
No offense, but you failed here. What if nothing gets returned? Now you're basically just writing code. Debatably even that example you're just writing code. An onLoad callback with array indexing and child access? This is just JavaScript wrapped in XML.
Surely this has to be a joke. If I wanted to write web stuff in XML, I would just write HTML.
I will be that guy: HTML is not XML. People wanted to write malformed html so xhtml never went anywhere.
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.
This stuff is not new, many React libraries have been doing since years, eg. the DataTable component of Primereact [1]
[1] https://primereact.org/datatable/
Direct links to their web landing page, and Github code:
https://xmlui.com
https://github.com/xmlui-org/xmlui
This combined with something like Datasette¹ would be a really nice toolbox for quickly developing simple database applications.
1. https://datasette.io/
When I click the link, I just get a bunch of JSON...
https://pasteboard.co/Rpp35synt4CW.png
Am I missing a joke, or has something broken?
The ergonomics makes my eyes bleed. I think we can do better.
Reminds me of renaissance for openstep.
https://github.com/gnustep/libs-renaissance
I understand the motivation for this, but don't understand why this can't just be a collection of web components.
I kind of want Python to have a desktop / web neutral library that does this and always am annoyed to learn it does not exist.
Do folks understand why?
What makes this different from React (which it is built on)?
- Components for data fetching
- IDs for bindings
Two seemingly simple details that lead to less code.
This reminds me of xaml with css thrown in. It is almost like this validates Microsoft's blazor plans with C#
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.
Unfortunately this doesn't provide a comparison to similar solutions, like XUL or htmx.
Is this supposed to be unreadable raw code or is the site overloaded?
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.
We hope the landing page conveys that message! https://www.xmlui.org/
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 ).
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.
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 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! :-)
XULRunner's initial release was in 2006.
OpenLaszlo was released in 2001.
Garnet was released in the early 90's.
Ivan Sutherland's Sketchpad (aka Robot Draftsman) was created in 1963, and inspired the Visual Geometry Project in the mid 1980's and The Geometer's Sketchpad in 1995
https://news.ycombinator.com/item?id=44627569
https://en.wikipedia.org/wiki/XULRunner
https://en.wikipedia.org/wiki/OpenLaszlo
https://en.wikipedia.org/wiki/The_Geometer%27s_Sketchpad
https://en.wikipedia.org/wiki/Sketchpad
Laszlo... I remember this one, dipped my toes in it, like many, many other GUI tools. I've been using the same backend framework for 20 years with no need to change but I can't decide which frontend GUI library I should invest my time for the future. It all looks like constant rehashing of the same ideas but with limited lifespan.
XUL applications outside of Mozilla existed well before XULRunner (itself barely a product.) Of course Mozilla was the main client at XUL's birth in 1999, but when I joined staff@mozilla.org 25 years ago I worked with OEOne, an ISV delivering a full Linux front-end using XUL. That was late 2000, maybe early 2001. A year or so before them, our parent company, AOL, began working with OEMs on XUL-based thin clients and AOL even re-built Prodigy (the low tier trial run for the AOL main client) with Gecko and XUL in 2001-2002. And of course, Mozilla itself shipped on a nearly a dozen platforms in 2002, and entirely XUL.
XUL was born in 1998 and the spec was finalized in 2001.
I worked on the cross platform TomTom Home content management app in 2007-2008, which used XULRunner and XP/COM extensively.
But XULRunner only really existed to serve Mozilla's Firefox web browser, and anyone using it for their own applications, like TomTom Home or Songbird, was on their own without any support.
Mozilla didn't take our XULRunner PRs seriously, or put much more than promises and lip service into XULRunner supporting other applications than Firefox.
https://en.wikipedia.org/wiki/TomTom#Support_applications
https://en.wikipedia.org/wiki/Songbird_(software)
If Mozilla was actually serious about supporting XULRunner for anything but Firefox, then it might have taken the place of Electron a lot earlier that Electron's release in 2013. That was a huge missed opportunity and tragedy of broken promises and wasted effort.
https://news.ycombinator.com/item?id=7601083
>I first looked at Red Swoosh and its Firefox extension, FoxTorrent. It would have been ideal, since we using the xulrunner platform for TomTom Home, but Akamai acquired Red Swoosh, and it vanished without a trace. [...]
https://news.ycombinator.com/item?id=20140349
>One way to get Akamai to unilaterally lower their bandwidth prices is to threaten to use BitTorrent instead. [...]
>TomTom had an "iTunes-like" desktop content management and device control desktop app called TomTom Home, which was implemented in xulrunner (the underlying framework of Firefox and Thunderbird, kind of a predecessor to Electron for writing cross platform desktop apps in JavaScript with C++ XP/COM plugins).
>The first thing I tried was to make an XP/COM plugin out of the LibTorrent library. That worked ok, but the idea of increasing the size and complexity of what was already essentially a web browser with a whole bunch more complex code that does lots of memory allocation and networking all the time, didn't seem like a good design. This was long before Firefox supported multiple processes, so the same app handing bittorrent would bloat the app and degrade the user interface responsiveness.
>However RedSwoosh, FoxTorrent and BitTorrent DNA all ran in separate processes that just handled all the BitTorrent stuff, and that you could talk to via https (to stream the file with a special url, and retrieve progress telemetry on another url). And it's incredibly easy to integrate xulrunner or any web browser with those servers via http, so no C++ XP/COM plugin required.
>Another issue is that you don't want every application to have its own BitTorrent client built in, or you will trash the network and disk, since otherwise they would compete for resources. It needs to be a centralized a system service, shared by any app that needs it.
>BitTorrent DNA worked nicely that way. And it could fall back to the CDN to download at full speed if there weren't enough seeders.
Also unfortunately, XULRunner was in no shape to run on mobile or embedded devices, so we ended up running WebKit on the TomTom embedded Linux devices, instead of trying to shoehorn Mozilla into small mobile devices.
https://news.ycombinator.com/item?id=34227548
>Both Chrome and Safari were based on WebKit (which itself started as a fork of KDE's KHTML and KJS libraries), which a lot of other vendors use too.
>Although Chrome eventually diverged years later with the development of Blink, Chrome was the result of a multi-company, industry-wide unification strategy on WebKit, the core of Safari. [...]
>Mozilla was in no shape to run on mobile or embedded devices (and still isn't afaik), while WebKit ran quite nicely on mobile and embedded devices, thank you. And as we all know, Android is as important to Google as iOS is to Apple.
>So there was really no chance of either of them (or any other of the many companies interested in mobile and embedded devices, like TomTom for example) ever building on top of Mozilla/xulrunner.
There was also HTMLayout released around 2003.
QML copies many core ideas from JavaFX (released 2008) and Microsoft's WPF (released 2006).
Microsoft's XAML for declarative UIs is the most reused/reimplemted approach among this bunch. Its variants are in WPF, Silverlight, WinUI, Avalon and Uno.
Flex and other "new" web features are direct decedents of Mozilla's XUL, from 25 years ago.
I'm curious, not talking down: would you be interested in sharing your age and/or years of experience coding, and if you're feeling very generous, the languages youve written code in for more than 2+ years?
I'm 37, 17 years full-time-ish, VB6, ObjC, Java, Dart.
I'm asking, I guess, because I feel like I've seen these concepts before in pre-iOS ObjC, and Java, and IIRC a good chunk of the late 90s and early 00s was obsessed with doing this stuff in XML.
I barely remember, in my hobbled, probably incorrect, perception the ideas are old enough to that I am a bit flummoxed at how to interlocute with the idea that they're novel breakthroughs.
I'm ashamed to admit I thought the page was parodying this concept from back then of anything + XML = awesome. Im admitting it to give a concrete sense of how my subconscious processed this as settled territory.
In order: 42 years old; 17 years (at least? starting to lose count!); PHP -> JavaScript -> Clojure/ClojureScript -> TypeScript.
Perhaps more pertinent to the topic, in my last job I implemented the bulk of an XForms implementation. Pertinent because XForms has a lot of conceptual overlap with what I’ve seen in XMLUI so far.
I think it’s worth clarifying my point above with that context: it isn’t the concept that I find novel, at all. It’s the sheer depth and breadth of declarative expressiveness that I see in the examples. Maybe the best way I can put it is that what seems novel to me is how much novelty it appears to enable, before breaking through the abstraction to give it more capabilities.
What we've been seeing for a while is that the rate of wheel reinvention has skyrocketed. Just look at the PostgreSQL ecosystem and you'll see many libraries for each feature you might be interested in.
What is that gets reinvented in Postgres sorry I can’t get it? Can u please care to explain?
Not in PG but in its ecosystem. Just look at any "awesome PostgreSQL" listings, like:
Merci. Awesome indeed.
I am not sure about prior art but the ability to mix built-in and user-defined components, and fluidly refactor the mixture, feels very powerful to me.
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.
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.
Using XML external entity references for i18n was certainly an "interesting" idea.
May your translations live in "interesting" documents.
https://www-archive.mozilla.org/projects/intl/iuc15/paper/iu...
I think it was a big missed opportunity. The frustrating thing about web UIs is that they don't obey my system-level display preferences (for stuff like fonts and colors). XUL was an approach that did that. Whether it's XML or something else is not the big issue, it's more a question of how to use a declarative style to specify a UI in a way that blends with the user's display preferences.
If memory serves, the system style stuff was a bolt on that Dave Hyatt did a bit later than the core work, and mostly for Windows.
The one theme for all platforms that was initially envisioned by Netscape kinda sucked ("Blue" for anyone that might remember.) And when Ben Goodger began his native-looking theme for Windows (pretty sure he started with preferences, maybe even before he got hired,) Dave got to work on Windows OS style queries and hooking OS style into XUL so the Mozilla suite's emerging new default theme could reflect those in its widgets. That work was ongoing even after most of the rest of XUL had been settled and I think Dave was still working on that even at Apple, right up until Mozilla decided Firefox would also ship on Mac and Linux and not just Windows* (as the several of us working on it has envisioned.) Once Firefox was running on Mac, Dave was precluded from continuing because of his Safari work. (He'd gotten permission to keep at when it was not directly competing with his Apple work.)
* Firefox was, for about its first year, meant to be Windows only. Ben Goodger had recently built a .Net wrapper for Gecko called Manticore, and there was Hyatt's Chimera for Mac, and Marco's Galeon for Linux, so the thinking was the major platforms would be covered with great standalone Gecko based browsers (no mail, HTML authoring, chat, etc.) But then Ben abandoned Manticore. Dave was convinced that XUL could actually kick ass on Windows (though also certain it could not on Mac) and so Ben started mozilla/browser to be the standalone Gecko browser for Windows. Ben also quickly abandoned that project and Blake Ross, an intern I'd recruited to Mozilla the year before, picked it up. He and I conspired on it with several others joining the effort during the end times at Netscape. Bryan Ryner stepped up to make it work on Linux, for example. staff@mozilla.org, well 5 of us I think, were sitting at a picnic table outside of Netscape's Bldg 21 when we decided that after Netscape wound down, we'd transition from the Suite to standalone browser and email (then called Phoenix and Minotaur). Cross platform would thus become a requirement. We weren't going to drop Seamonkey without replacements for it on Mac, Windows, and Linux. It took a while to get the Mac version up and running and as soon as that happened, Hyatt had to bail. About a year later, we released Firefox 1.0.
This is an incredible piece of lore, thank you for sharing!
XHTML was not a previous version of HTML; it was a failed successor.
HTML was originally conceived as a subset of SGML, but browsers tried to be as forgiving as possible of malformed markup and HTML-in-practice drove standards folks nuts. XHTML was intended to fix this by making a pure-XML representation of HTML, which would be unambiguous and fast to parse, but its very strict error handling made it extremely difficult to adopt. It turns out people would generally rather have a slightly wrong page than one that just said "XML Parsing Error".
WHATWG broke with W3C in 2005 to standardize HTML-in-practice into HTML5, giving up on XML compatibility and strict parsing.
I'm 90% certain that the origin of WHATWG was in late 2003 or early 2004 when Dave Hyatt (Ex-Mozilla, then with Apple) Ian Hickson (ex-Opera, ex-Mozilla, then at Google) Start Parmenter (ex-Mozilla, then at OSAF or Oracle, I think,) Brendan Eich (still with Mozilla,) and a couple other folks were at Mozilla's brand new closet of an office, talking about XHTML's shortcomings, advanced we'd made with XUL, and how the web could best move forward given the XHTML failure and challenges from new platforms. I was a fly on the wall for that conversation and then a fly in IRC for more conversations, but it has been ages and my memory's not what it was then, (and I'm too lazy to dig through 30 years of archived emails to verify) so take it with a grain of salt.
It’s not failed: it’s the only language used in the ePub standard. Though this might change with ePub 3.3 which is considering adding HTML support.
> It’s not failed: it’s the only language used in the ePub standard.
"XHTML" can refer to both a failed series of standards intended to replace HTML (XHTML 1.0, XHMTL 1.1, and XHMTL 2.0) and the XML syntax of HTML that is part of the HTML living standard, which itself resulted from the failure of the XHMTL series of standards. EPUB 3's "XHTML" is the latter, not the former.
Its design goal was to supplant HTML as the language of the web, and regularize communication between browsers and servers. At this it has failed.
I remember trying to write a cross-platform interface for some software in XUL, around 2003. I even bought two (physical!) books on the subject. It was totally impossible! The libraries were ever-changing and you needed the entire Mozilla CVS tree checked out to compile anything and just getting that to compile was endless complexity. I gave up and used an early port of Gtk to Windows.
Such a "could have been great" technology if it wasn't for Mozilla ...
Reminds me of XAML and WPF.
I agree and that was a huge failure.
One of the big reasons VB died, people will tell you, was the language. And that's true. But what they don't mention is that the other reason was the components. I'm not sure this is replicating a success story but rather failing to learn from what was not a success story.
I ran a very successful company (successful for a time) that sold Visual Basic developer tools via a printed mail-order catalog named VBxtras.
Two things killed Visual Basic:
1. The web. Visual Basic was first and foremost a Windows desktop app development tool, and their UI-first model of app development did not translate well to the web, or at least the attempts to translate to the web did not resonate.
2. Microsoft. Rather than continue the simplicity Visual Basic offered, Microsoft "improved" it by releasing VB.NET which abandoned the core simplicity that made Visual Basic so wildly popular among "Occupational Programmers," as Kathleen Dollard[1] and I lamented back in the day. The upshot was that former Visual Basic programmers fell into two (2) camps; they either:
A.) Abandoned VB for something else, or nothing at all, because they did not want to have to become a professional programmer, OR
B.) Switched to C# because if they were going to learn how to be a "real" programmer they might as learn C# and not C#'s disfavored sibling VB.NET.
I blogged about occupational programmers several times back then: https://mikeschinkel.com/tags/occupationalprogrammers/
BTW, the company that has developed XMLUI was one of our better vendors of VBX components for Visual Basic. They have since renamed to /n software, but at first they were named IP*Works (I think I stylized that name correctly per how they did at the time.)
[1] Ironically Kathleen is now leads the .NET Core CLI at Microsoft, and is also lead over VB, I think: https://devblogs.microsoft.com/dotnet/author/kathleen-a-doll...)
I am not sure whether calling WPF a huge failure is justified. It works extremely well when everything is adaptable to its MVC-adjcent MVVM design pattern. In this case it's almost child's play to build rich and conplex GUIs that keep in sync with internal state.
Microsoft dropped the ball when they rewrote WPF in incompatible forms for the web (Silverlight) and Windows Phone (WinUI) shortly after releasing WPF itself. That ruined developer trust for their GUI library longevity.
The irony is that WPF itself never went away, and receives support and even occasional minor new features even to this day on .NET Core.
Much like WinForms, there are still many internal line-of-business apps written in it decades ago that are just happily chugging along, ignoring all the post-Silverlight churn in Microsoft dev story.
I really liked WPF for Windows Phone back then. The tooling was great.
I bought a massive 1000+ page book, "Pro WPF in C# 2010," one day. I also had to buy "Home Maintenance For Dummies" the same day. The bookstore cashier laughed at me.
I spent an unhealthy number of hours working in XUL in 2000-2001 working on the Komodo editor, which, bizarrely, used Firefox as its GUI platform. XUL was neat, but oh god so complicated. XML was the new hotness around the peak of the DotCOM era and Mozilla’s use of XML for a GUI framework fit the zeitgeist.
Komodo was my favorite editor. There weren't many editors at that point in time that had great Perl support.
It was very innovative.
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.
I thought of XUL right away too.
Don't forget XSLT. Worked directly in the browser. I only found out because the battle.net StarCraft page was made using it and I just happened to find it while poking around.
so basically Windows Presentation Foundation (WPF) ... ?
android layout xml is great, glad to see more broad attempts
So Winforms for React.
See also XAML: https://en.wikipedia.org/wiki/Extensible_Application_Markup_...
OpenLaszlo was even more similar to this…
https://en.m.wikipedia.org/wiki/OpenLaszlo
XAML is an example for how not to do it.
This seems like a neat idea that is 20 years too late.
https://xkcd.com/927/
What's old is new again. It's Adobe Flex for the kids. I like it.
Yet another implementation of data binding
> XMLUI
So his UI has 2 widgets: text input field and scrolled list. /s
XML?
Why not web components?
Focus, I'd assume.
So it’s like JSX but with implicit imports and stringly-typed props?
The author is probably too young to have experienced the crap of XML based interface. Like XUL and co.
But with another stack, I miss how good and easy it was to do great interfaces with Delphi in the good old time!
"Since 1995 nearly all of my professional work has been enabled by, and published on, the web." https://jonudell.net
I stand corrected: The Microsoft era (2007-2014) In Jan 2007 I joined Microsoft as an evangelist.
Exactly at the time that Microsoft pushed for the XAML crap... So indeed not reinvented the wheel, just not having giving it up despite the complete failure of it.
I like XAML, the whole point of it is tooling support which was undermined when the tools were so buggy for so long. Now that many of the bugs have been fixed and computers are much faster it’s become a really productive UI paradigm for me. I’ll eventually switch over to Avalonia for better performance and cross platform support.
You do Windows GUI development?
Yes, among many other things. Applied Researcher so full stack and constant greenfield.
I also worked at DevDiv MS during the Foundation series era so I know why many of the issues with WPF are there, basically political infighting and penny pinching. It didn’t help that Gates quit and Balmer took over. Patterns and Practices didn’t properly understand WPF so they gave bad official advice on how to solve problems, it didn’t help that this was near peak Object Oriented mania and language features like generics were still new so there was a lot of unnecessary boilerplate. Code generation did help with this. WPF has a very high skill threshold for making custom controls that are not just compositions of existing controls, open sourcing WPF has helped a lot with this.
WPF is a flawed implementation of a really good idea, and if you can work around the flaws like I do then it’s actually really great. I totally understand why other people don’t like it.
I know it’ll sounds like I’m a snobbish hipster but the vast majority of people never get to the skill level required to properly use these tools. And while React starts out easier it doesn’t stay that way.
Ummm, errr. Jon Udell[1] was a columnist for Byte (RIP) magazine. He has been around a looooooong time.
[1] https://en.wikipedia.org/wiki/Jon_Udell