Ask HN: What could I build to make your life a little easier?
9 points by uint9_t 1d ago 10 comments
Ask HN: What is the state of support for mutable torrents?
5 points by absurdistan 3d ago 1 comments
XMLUI
346 mpweiher 185 7/20/2025, 2:03:39 PM blog.jonudell.net ↗
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.
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...
To be human is to be multitudes.
"Do I contradict myself? Very well, then I contradict myself."
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?
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.
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.
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?”
Declarative and imperative UI approaches aren't mutually exclusive, and it's common for software to leverage both (e.g. SwiftUI and UIKit).
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 ..
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
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.
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.
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.
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.
SSAX is probably the best xml parser I have ever used.
Sadly it doesn't seem like they're using it anymore.
Nope, but they sure had to make 1/2 the content about "AI" (otherwise nobody would read it?).
Apparently this lives on in Apache Royale [2]
Using XML for an user interface description language is quite common, from XUL to XAML to JSX. In my experience, XML is well suited to this task.
1. https://en.wikipedia.org/wiki/MXML
2. https://apache.github.io/royale-docs/features/mxml
I could do stuff with ease that had seemed like magic and completely out of reach without C++ and complex pointer gymnastics. So thankful to the movement and I sincerely hope this project can bring that novice-first approach to web programming that does not compromise on responsiveness and smoothness, while making sane compromises, and doesn’t hold you back.
Even more exciting is this - https://docs.xmlui.com/mcp.
It can reduce the amount of code tools like Claude need to generate (fewer tokens need to be generated) for a usable high-functioning UX/dashboard. I am going to start using this today.
That being said Visual Basic also create some absolutely terrible programs.
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.
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
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/
[1]: https://github.com/marmelab/react-admin [2]: https://github.com/refinedev/refine
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?).
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
Edit: I don’t see a CSP on the dogfooded homepage so I would assume this is an issue.
Also, the Docs link to home.xmlui.com and don't resolve
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.
> 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(', ') : '' }; }); }
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...
[1] https://primereact.org/datatable/
see https://www-archive.mozilla.org/xpfe/xui.html
* Fun fact: XUL was conceived at Netscape. Mozilla adopted it for XPFE.
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.
https://pasteboard.co/Rpp35synt4CW.png
Am I missing a joke, or has something broken?
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.
So this goes from XML → React → XML (HTML)?
Are there any studies actually showing XML is easier to write that a scripting language? In my experience, XML is equally hard to write while being more limited.
https://xmlui.com
https://github.com/xmlui-org/xmlui
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.
This recent HN submission gives a pretty good idea: https://news.ycombinator.com/item?id=44621102
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.
Rather than try to understand, I decided he was into witchcraft.
“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.”
See https://spreadsheets-are-all-you-need.ai/index.html
The author of that website implemented GPT-2 inference on Excel
Plus, someone made a MOV only compiler, soon...
Calling user-defined functions (UDFs) from a worksheet is as simple as calling built-in functions: You enter the function via a cell formula.
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.
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.
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>
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.)
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.
Do folks understand why?
https://github.com/gnustep/libs-renaissance
https://github.com/apache/royale-asjs/blob/develop/examples/...
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
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."
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.
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! :-)
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.
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
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.
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.
"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.
Such a "could have been great" technology if it wasn't for Mozilla ...
May your translations live in "interesting" documents.
https://www-archive.mozilla.org/projects/intl/iuc15/paper/iu...
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.
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...)
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.
https://en.m.wikipedia.org/wiki/OpenLaszlo
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.
Why not web components?
But with another stack, I miss how good and easy it was to do great interfaces with Delphi in the good old time!
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.
[1] https://en.wikipedia.org/wiki/Jon_Udell