Jon has been around for a long time, and I've been a long-time fan. He's a bit of an elder: he's seen a lot of things, and he's worth listening to.
> I’m a fan of web components but it’s the React flavor that dominate and they are not accessible to the kind of developer who could productively use Visual Basic components back in the day.
I think this is the most important statement in the piece. The rest of the post explains the technical details, but this explains _why_ this exists. This is a bold statement, but I don't think he's wrong.
Now, is XMLUI the _right_ set of abstractions to help these developers? We'll have to wait an see. But I love to see the attempt!
I 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.
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.
> 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 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.
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).
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.
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'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.
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 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 ..
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
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
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.
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 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.
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.
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.
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.
> 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.
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.
> 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.
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.
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).
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).
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.
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.
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.
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.
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.
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:
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.
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."
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! :-)
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.
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.
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'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.
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.
> 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 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.
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 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.
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.
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.
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 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.
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.
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!
code currently only works on JS evergreen browsers. i guess like VB only worked with windows and if shipped with the right DLLs.
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.
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.
> 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.
Bye bye ad blocks?
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.
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.
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?
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...
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.
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.
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.
And wxwidgets and glade files...
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.
Your idea sounds interesting but your site is unreadable on mobile (Android+Firefox).
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.
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'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.
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 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 ..
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.
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.
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.
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.
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.
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.
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 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.
if the target audience is 'citizen developer', aka Visual Basic (classic), I am not sure introducing XSLT is such a good idea.
>No mention of XSLT?
Nope, but they sure had to make 1/2 the content about "AI" (otherwise nobody would read it?).
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.
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.
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
This combined with something like Datasette¹ would be a really nice toolbox for quickly developing simple database applications.
1. https://datasette.io/
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.
> 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.
> 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.
> 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/
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.
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.
[dead]
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.
Just ship https://github.com/NeilFraser/JS-Interpreter and you’re good to go! /s
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.
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
how do u like jsx then?
JSX has all the tooling available.
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
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.
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.
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
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.
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.
This reminds me of XForms and its fully declarative approach. It allowed you to add interactivity to your HTML without writing code.
I was training a JavaScript developer to do DevOps. I described the C(++) GUI libraries to him, GTK and Qt. His reaction: "So you can't make the UI look exactly the way you want it to. You can't dial it in."
This will largely fail to gain market share just like PaperGUI[1] and Polymer[2] did (much to my chagrin). UX and web developers simply feel the need for more control over the UI.
However, I do find it interesting that there is enough interest in this trend that people keep recreating tools for it over the years. I wonder why.
1: https://google.github.io/paper-gui/
2: https://polymer-library.polymer-project.org/1.0/docs/about_1...
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.
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.
Looks like XAML https://en.wikipedia.org/wiki/Extensible_Application_Markup_...
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/
So you built a worse alternative to React, on top of React?
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.
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.
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.
> 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.
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?
Direct links to their web landing page, and Github code:
https://xmlui.com
https://github.com/xmlui-org/xmlui
it reminded me of Adobe Flex (probably without its "bad" parts) - nice work, congrats to the developers.
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.
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.
> 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.
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. ;-)
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
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.
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.
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.
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).
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).
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" -->
IIRC, for a long time in the late 90s, Fedex was glued together with spreadsheets.
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.
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.
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.
Let's be honest, XUL was a pain for a number of mozilla-specific choices (rdf...). A lighter, better XUL would be absolutely fine.
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
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.
XMLUI reminds me of XUL (XML User Interface Language)
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.
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?
The ergonomics makes my eyes bleed. I think we can do better.
This reminds me of xaml with css thrown in. It is almost like this validates Microsoft's blazor plans with C#
Reminds me of renaissance for openstep.
https://github.com/gnustep/libs-renaissance
reminds me of Macromedia MXML (used in Flash, Coldfusion and Flex)!
https://github.com/apache/royale-asjs/blob/develop/examples/...
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
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.
What's old is new again. It's Adobe Flex for the kids. I like it.
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."
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?
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! :-)
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.
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.
There was also HTMLayout released around 2003.
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?
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'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.
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.
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.
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 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.
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 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.
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.
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 thought of XUL right away too.
android layout xml is great, glad to see more broad attempts
So Winforms for React.
This seems like a neat idea that is 20 years too late.
See also XAML: https://en.wikipedia.org/wiki/Extensible_Application_Markup_...
XAML is an example for how not to do it.
OpenLaszlo was even more similar to this…
https://en.m.wikipedia.org/wiki/OpenLaszlo
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!
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.
Yet another implementation of data binding
[dead]
[dead]
[dead]
[dead]
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.
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