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.
XUL was deeply unpleasant to use and maintain, and I do not miss it at all. We eventually ended up rewriting it as a standard webapp. It made the writers a bit slower, but they adapted eventually.
I think it's safer to say: It's almost all HTML these days. XUL is very much deprecated.
As we killed XBL, our XUL components because web components. https://briangrinstead.com/blog/firefox-webcomponents/
Rather: find developers who have a shallow knowledge of HTML.
I do claim that it takes much less time as a developer to get to a decent level of XUL knowledge than to get to a decent devel of HTML knowledge.
At the time I thought it was inflexible to style and felt very non-native.
To be fair, it had its moment, moreso in desktop applications than on the web. I seem to remember a lot of installers being developed in Flex. The iPhone showed up just in time to kill it before it ever got its footing on the web.
Both have their worts, but I'm perpetually puzzled by how angular ever made sense as ergonomic. I suppose people like Vue so there's still some insistence on augmenting templates with programming constructs. Seems inevitable that templates will want more and more powerful constructs... and boom.
With React those sorts of "I'm only comfortable with HTML" (or "I'm only comfortable with Figma but it gives me HTML") designers often know that they don't like JS and don't want to work in JSX files directly. If middle managers are looking for "efficiency and synergy" the "my designers won't work directly in React" problem looks a lot like a "let's use Angular for everything because I'm told it is 'just' HTML" solution, with the trap being set that Angular's template language is complex and confusing and still a template language despite being in files labeled .html. Then once trapped the sunk cost fallacy strikes hard because "everyone already knows Angular" (despite no one actually "knowing" Angular, they know HTML and fight the template language to get something that sort of works some of the time).
At least Vue tends to prefer .vue for its single-file components. It's not directly the same bait-and-switch.
> 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!
Glancing over the markup, none of this seems too alien to React.
This all seems not too dissimilar to the generic pages-as-JSON DSL that every CMS/developer reinvents every other project.
> XMLUI wraps React and CSS and provides a suite of components that you compose with XML markup.
What are some GUI-enabled devices you wish you were able to address, but which cannot run Firefox, Safari, or a Chromium derivative?
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).
Examples: Autodesk Maya, 3DS Max, Mudbox Foundry Nuke, Mari, Katana SideFX Houdini Substance Painter, Designer
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?
To be human is to be multitudes.
- G. W. F. Hegel
"Do I contradict myself? Very well, then I contradict myself."
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?”
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 ..
Declarative and imperative UI approaches aren't mutually exclusive, and it's common for software to leverage both (e.g. SwiftUI and UIKit).
It never really clicked with me and I had a hard time really aligning things, with their Flexbox thing etc, how you set graphic values outside vs inside component classes, being sometimes confused how paint() vs resized() affect things etc.
Probably operator error but in the end I was happy to ditch it for the new WebView option in JUCE 8.
Yes, coming from the web, JUCE' Flexbox and paint()/resize() semantics are going to be 'weird' - but thats the point. You have the power to decide when/how to update your GUI, frame by frame - and for high performance GUI's, this is vital.
These days it has to be said: you can get a LOT of your JUCE GUI work done for you by an LLM with great results.
My project is not a typical audio plugin so it's also why I was not benefiting as much about the graphic API as others may do.
But I'm not sure how the WebView is an abomination, it's actually a quite small API that works ... and is totally optional and didn't replace the original graphic API.
Sure, its optional, I suppose that is a benefit.
It also involves a custom C++ module system and build strategy that is hard to make fast and generally is impossible to use JUCE as a library, so you wind up recompiling it as a dependency an excessive number of times (which adds up in CI).
By comparison, I feel class component's promoted 'mile high' components where everything was inside of the class, which has many enormous drawbacks, one of the biggest being maintainability.
To this today though, I feel most people don't understand the simple rule of UI is the last mile concern. Developers still cram way too much into components rather than separating layers of concerns
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.
And given Jon Udell has written about XSLT before[0], I'm sure this was an intentional decision. Not sure I understand it though.
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.
And what specifically do you mean when you say everything has to be processed as a one liner? I’ve never used an XSLT processor where that was true.
That it is a fiercely declarative language makes it hard to integrate. Often developers are placed within an architecture that gives them limited options and only being able to use XSLT while trying to integrate other network calls or services is non-trivial and a complete headfuck sometimes, compared with more general purpose languages like python or javascript.
Hard to integrate in what way? XSLT is a language focused on several things that it’s very good at but it’s not intended to replace Python or be a general purpose language. Yet there are many common data related tasks where a messy and hard to maintain pile of imperative code can be replaced with a simple XSLT.
Not everyone gets to pick and choose how they use XSLT. Place I used to work, the services team used to have a sign:
> [X] Days since last custom report
They hated it and I can't blame them, making a series of soap calls, consuming the most degenerate api ever written and generating a document for the customer was a pain. Bear in mind this was an enterprisey "do everything system", oversold by sales and the services team had to use XSLT to bridge the gap between customer expectation and what the salesman sold them.
What they needed was a host for a general purpose language, what they got was XSLT.
> but it's not unlike how you have to change your thinking for functional programming generally
I'd write lisp any day of the week over XSLT. I don't think XSLT deserves a place alongside other functional languages because its bound so tightly to xml. Sure, one can argue it has its place when processing XML but I'd pick a general purpose language and process XML with that over XSLT every time.
XSLT was held back by licensing, its why everything supports 1.0 and barely anything supports 2.0. If 2.0 was released for free then everything would use 2.0.
https://www.npmjs.com/package/saxon-js https://github.com/Saxonica/Saxon-HE
for reference: I'm not talking about today, I'm talking about that point in time where (for example) .NET could have adopted XSLT 2.0 but chose not to.
That said, it is emphatically not true that XSLT 2+ was somehow license-restricted. I worked at a company that used XSLT 2.0 and XQuery for code generation back in 2006, and we used the free edition with Saxon with no issues - paid versions had some optimizations and features like static type checking which we simply didn't need.
For the most part, XSLT 1.0 was "good enough" for most cases when XML was still the primary interchange format, and later JSON took over so there was less incentive for framework providers to spend resources on keeping up-to-date with the standard. Especially since XSLT 2.0 was such a massive leap in many ways, including a different data model that made many existing XSLT 1.0 processors incompatible in ways that required a massive redesign.
I 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.
Nor did the spec itself stop evolving. The problem is that the browsers have deprecated the technology before XSLT 2+ could be adopted.
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?).
I could do stuff with ease that had seemed like magic and completely out of reach without C++ and complex pointer gymnastics. So thankful to the movement and I sincerely hope this project can bring that novice-first approach to web programming that does not compromise on responsiveness and smoothness, while making sane compromises, and doesn’t hold you back.
Even more exciting is this - https://docs.xmlui.com/mcp.
It can reduce the amount of code tools like Claude need to generate (fewer tokens need to be generated) for a usable high-functioning UX/dashboard. I am going to start using this today.
But then it showed XML code (which of course I saw coming, given the title) and I was immediately reminded of WPF with its XAML, which was a nightmare for me. The excitement was instantly replaced with great disappointment :(
I'll readily admit that I haven't tried it so I don't know how much like WPF/XAML it'll be, but it's pretty clear it won't be like Visual Basic or Delphi.
I 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.
>This site is an XMLUI™ app.
but like pretty much every such system, it is assumed that one knows react and so forth, and how to manage a deployment --- if they really want to be compared to VisualBasic, what is the equivalent to:
- buy VB - install VB - launch VB - develop app - test/compile - distribute .exe
Probably I'm not the target audience, but if they had a "Minimal Working Example" of not just how to code, but also how to deploy an app (can it be run locally, say if I wanted something to keep track of my 3D printers and CNC machines?).
Edit: I don’t see a CSP on the dogfooded homepage so I would assume this is an issue.
> AngularJS does not use JavaScript's eval() to evaluate expressions. Instead AngularJS's $parse service processes these expressions.
For Angular as in ”Angular 2” docs, see https://angular.dev/guide/templates/expression-syntax
It's been a while since I played with it but I remember thinking it was well thought out & being surprised that it wasn't more widely adopted.
[0]: https://rjsf-team.github.io/react-jsonschema-form/docs/api-r...
That being said Visual Basic also create some absolutely terrible programs.
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
Good apps were using semantically correct design layouts but there were, and still are, tons of bad apps out there, just like there were a ton of VB6 applications.
There is also Lazarus[1], which uses Pascal but feels closer to what I remember of the VB6 experience.
Our experiences do not match. I used Borland Delphi to build business apps 20 years ago just using the UI builder. I've been using Android Studio to build apps at FAANGs for 10 years now and I cannot remember the last time the Design tab was useful - it was always faster and more reliable to just edit the XML file.
Yes, Delphi didn't do resizing windows and crashed half the time, but I was pretty happy with the WYSIWYG / UI building functionality for production apps.
Android Studio's UI builder is nowhere near that level of usefulness. I have a hard time believing anyone is using the UI builder in Android Studio for anything other than tutorials or entry level Android apps. It doesn't render the layout properly 90% of the time, or just renders some placeholders with no content and calls it a day.
For a modern IDE, Android Studio is somewhere between just OK and bad, mostly because it has features the other IDEs didn't at the time, but the dev experience is behind Turbo Pascal in the 90s on MS DOS. The editor is laggy. The debugger is slow and hangs often. The list goes on, but I'll stop the rant here.
Drop an AbsoluteLayout into a design and you can drag, drop, and resize buttons to your hearts' content. You'd have the same problem with VB6 where your buttons would fall off the screen if someone ran your application at a lower resolution than you designed it for, but that was never a problem for the desktop designer.
For the same reason dumping buttons on an arbitrary coordinate and resizing by eye is no longer acceptable on desktop, that same ease of design died out in Android for any serious application developer. It stuck around a while longer on desktop, unfortunately, but modern frameworks pretty much all use declarative layouts these days.
const App = () => (
<Admin dataProvider={dataProvider}>
<Resource name="posts" list={PostList} />
</Admin>
)
const PostList = () => (
<List>
<DataTable>
<DataTable.Col source="date" />
<DataTable.Col source="title />
<DataTable.Col source="author" />
</DataTable>
</List>
);
[1]: https://github.com/marmelab/react-admin [2]: https://github.com/refinedev/refine
Also, the Docs link to home.xmlui.com and don't resolve
Thanks for the 404 heads-up.
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
And you know what? It worked great. WPF with XAML - from 2006 originally! - is still, to this day, by far the easiest way to write a desktop Windows app with adaptive layout etc.
* Fun fact: XUL was conceived at Netscape. Mozilla adopted it for XPFE.
If you believe XUL was developed for anything other than Mozilla's XPFE, you have been mislead.
Also, would you please provide names for those many pre-XUL XML-based UI languages I'm genuinely curious. Other than the web itself, HTML+JS+CSS, I'm at a loss for what those many XML-based UI markup languages you're referring to could possibly be. As a Mozilla participant at Netscape, and someone with hours of discussion with Hyatt over those early years, and a (very small) contributor to XPFE as early as Dave's XUL menus first draft, I'd be real interested to learn about prior art. Did we somehow miss all of those per-existing examples?
AOL acquired Netscape in 1999, then became the first company to ship XUL as part of Netscape 6 in 2000. https://en.wikipedia.org/wiki/Netscape_6#:~:text=With%20publ... AOL abandoned XUL to the Mozilla open source community not long after, when they disbanded the Netscape team in 2003.²
> Also, would you please provide names for those many pre-XUL XML-based UI languages I'm genuinely curious.
WML, XFDL, and Glade XML all shipped in 1998, two years before Netscape 6. Adobe's XFA also shipped before Netscape 6.
¹ https://www-archive.mozilla.org/xpfe/whoswho ² at the time meaning, "the software suite formerly known as Netscape Communicator" ³ https://www.mentalfloss.com/article/502789/day-2003-netscape...
Doesn’t seem like a big improvement? In fact the opposite. Sure, React’s stateful hooks mixing in a semi-declarative mode of programming in otherwise imperative code isn’t exactly intuitive, but the flexibility and familiarity you get from having full JavaScript at your fingertips is worth everything. Hands up anyone who want to learn how to make a for-loop with filter+map in xml syntax. Didn’t think so.
If you want to fix react what you should do instead is keep jsx and give stateful hooks a dedicated section that can’t be mixed up in rendering code.
https://gist.github.com/ricardobeat/8aedb9c6d3a1b0bfaba9cc55...
The demo app shows a bunch of patterns. https://docs.xmlui.org/tutorial-01
> 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(', ') : '' }; }); }
Example:
<FML version="1.0" title="Counter-Page">
<HEADER height="46" color="blue">
<CENTER>
<TEXT value="FML Demo Home Page" size="20" color="white"/>
</CENTER>
</HEADER>
<CENTER>
<COL center="true">
<TEXT value="You have pushed the button this many times:" color="#7c7c7c"/>
<TEXT id="clicknumber" value="0" style="h3" color="#7c7c7c"/>
</COL>
</CENTER>
<POS bottom="10" right="10">
<BTN onclick="clicknumber.set({clicknumber} + 1);" width="40" height="40" radius="50" color="blue" type="elevated">
<ICON icon="add" color="white"/>
</BTN>
</POS>
</FML>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...
Using this approach (pre QT designer working this way), we were able to give the UX team the ability to move widget around in the installer, colour things, add images.. it actually worked incredibly well, to everyone's shock. I still remember the nightmare of dynamic signal and slot lookups.
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.
So appreciate a lot new developments in the really-easy-to-use open source and text tools that also enable more involved use case!
Admittedly I also have not tried to learn React or other frameworks (most times I got stuck on backend basics).
It would be awesome if (almost) anyone could easily type out a website using simple and open source tools (specially with a little more involved functionality than just static content, or more free looks), and it just worked (with minimal coding required for the backend -- that's what's great about plain html imo, it's just a few files that contain your whole website). I mean, meanwhile it's great that something like hosted blogs exist of course.
I might be completely off the mark here (edit while writing the comment, considering you mention static HTML I probably am, going to leave the comment anyway for others to see), but considering you seem to think that you need React (or any javascript for that matter) to me seems to hint at a practical knowledge gap about HTML and webpages in general.
Which, is more common these days exactly because modern libraries effectively abstract it away to the point where people only see HTML when looking at the DOM representation in the browser devtools.
> It would be awesome if (almost) anyone could easily type out a website using simple and open source tools (specially with a little more involved functionality than just static content, or more free looks),
It is interesting to me how we effectively regressed here. At least as far as common knowledge goes. You can still go to a basic shared webhosting provider, get a domain, some storage, mysql/mariadb datbase, php and do all of that with relatively little effort. Of course, PHP isn't considered to be relevant anymore which is entirely fair. But it is by far the most straightforward way to get a website going with an actual backend that doesn't require you to do cloud wrangling and all that.
I really like OpenSCAD for instance, which despite being a little difficult to do complex stuff with, is quite easy to learn (and you can indeed do complex things with a little methodology). Like, everything about the web seems a little obtuse to me. One day I'll learn a little more to hopefully make more educated comments :)
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.
I think a lot of this has to do with the idea that Kay is criticising here: HTML as a mechanism for building applications has been so successful because it needs to be interpreted by a browser. That provides a tremendous level of sandboxing that makes it a lot easier to trust whatever website you're loading than the application you're installing. It also provides a grab-bag of useful controls and elements, while still being completely flexible with creating new ones without needing to resort to OOP inheritance chains or raw graphics drawing APIs. This is all to say nothing of accessibility, which is practically built into the browser.
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.
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 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
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:
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.
It wasn’t also easy to make a living fixing bad VB apps (or going back to Delphi).
I’m not saying that components are a bad idea, but the 90s implementations didn’t quite realize the dream.
The goal is admirable, but the execution and implementation is, in a word, absurd. From the XMLUI website:
> XMLUI provides the glue that binds the React ecosystem into a declarative model.
This negates the raison d'être of React, which is to bring the development style of immediate mode UIs to the browser—that's the fundamental driving factor behind the creation of React. Components are incidental. (Web browsers in fact do components just fine, with native support for custom elements and shadow DOM—which, along with flexbox, is a descendant of XUL, the other 90s-era technology that worked the way the XMLUI authors lament isn't around.)
The purpose of React was to bring the development style of "immediate mode" UIs to the browser[1], which for better or worse inherently has a "retained" model of the UI that developers writing in-browser apps would have to deal with. So now with XMLUI, you have React trying to paper over the fundamental nature of the DOM to make it feel like it's immediate mode instead (and all the fakery involved with that), and you have XMLUI choosing to build upon React and do these retained objects instead—aligning with how the browser actually does things underneath React!
The "The Backstory" section on the XMLUI landing page is worth a look and really drives the point home (along with Jon's admission in his blog post that he's never been a React developer):
> It began with a relatively small effort to add web-based admin interfaces to some of the company’s products. This resulted in the core engineering team — experienced backend developers whose interactions with UI technology were limited to old-school battleship-gray Visual Basic, Delphi, or .Net/Winform — being surprised by the complexity of modern web development.¶ Calls for simplicity and easy/intuitive tool support were met mostly with blank stares from the React guys on the other side – and the designer, UX guy, and JavaScript folks on the server side of things.¶ But the /n software team refused to take no for an answer, and more than two years of work from a team of Javascript/React wizards resulted in the new semantic layer that is XMLUI.
"Simplicity" this is not. Ditch React. You don't need it. You're actively working against it. (And worse, it looks you've put yourself at the whims of hired "experts" who exemplify the stereotype of the React-only programmer who never learned the fundamentals, and in this case can't even spot that you're asking them to undo React.)
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.
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 do this for custom software I build for clients, mostly on the backend though[1]. Started it two years ago, have rapid velocity and, without AI generally take 30 to 60 minutes to implement a new feature that touches backend persistence and front end UI.
‐----------
[1] I did a show HN on a tiny front end component that gets the most use, recently, I think. ISTR most people in the comments said they they preferred React, a few said it was not novel enough to be a paper (they are correct. It isn't). You can see it here: https://github.com/lelanthran/ZjsComponent/
I'm not really in the mood to open up the whole stack I use yet, I still make money bu having a low effort way to build web apps, and due to the way it works it requires a fraction of the tokens required when actually using AI assist (output for the last time I implemented a backend call from scratch was 10 lines, most of which were comments).
Blazor is pretty productive if you're looking for a mature component based XML (Razor) syntax but again, there is no Visual design element to throw thing together.
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.
$ ./myapp.xlsx --port 8080
My App listening on port 8080
Loaded 1337 rowshttps://learn.microsoft.com/en-us/sharepoint/dev/general-dev...
“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.”
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.
We were pretty far past the era of falling back to tables by that point.
As it is now I find it very powerful and empowering, but also scary.
Rather than try to understand, I decided he was into witchcraft.
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.
Our hope is that by building up a set of these patterns, and making them available to agents via MCP, it will be as easy as possible to get things right.
https://pasteboard.co/Rpp35synt4CW.png
Am I missing a joke, or has something broken?
- Components for data fetching
- IDs for bindings
Two seemingly simple details that lead to less code.
Do folks understand why?
* difficulty in mapping complex UI layouts to XML (VB was quite literally WYSIWYG and mind-blowing for its time)
* Verbose to specify (esp. multilevel nesting, complex navigation etc..)
* Cannot make sense of the XML content vs all the nested tags
* Keep switching between how the UI looks and the XML
... all generally point to the difficulty of separation of configuration and behavior.
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
XUL was born in 1998 and the spec was finalized in 2001.
But XULRunner only really existed to serve Mozilla's Firefox web browser, and anyone using it for their own applications, like TomTom Home or Songbird, was on their own without any support.
Mozilla didn't take our XULRunner PRs seriously, or put much more than promises and lip service into XULRunner supporting other applications than Firefox.
https://en.wikipedia.org/wiki/TomTom#Support_applications
https://en.wikipedia.org/wiki/Songbird_(software)
If Mozilla was actually serious about supporting XULRunner for anything but Firefox, then it might have taken the place of Electron a lot earlier that Electron's release in 2013. That was a huge missed opportunity and tragedy of broken promises and wasted effort.
https://news.ycombinator.com/item?id=7601083
>I first looked at Red Swoosh and its Firefox extension, FoxTorrent. It would have been ideal, since we using the xulrunner platform for TomTom Home, but Akamai acquired Red Swoosh, and it vanished without a trace. [...]
https://news.ycombinator.com/item?id=20140349
>One way to get Akamai to unilaterally lower their bandwidth prices is to threaten to use BitTorrent instead. [...]
>TomTom had an "iTunes-like" desktop content management and device control desktop app called TomTom Home, which was implemented in xulrunner (the underlying framework of Firefox and Thunderbird, kind of a predecessor to Electron for writing cross platform desktop apps in JavaScript with C++ XP/COM plugins).
>The first thing I tried was to make an XP/COM plugin out of the LibTorrent library. That worked ok, but the idea of increasing the size and complexity of what was already essentially a web browser with a whole bunch more complex code that does lots of memory allocation and networking all the time, didn't seem like a good design. This was long before Firefox supported multiple processes, so the same app handing bittorrent would bloat the app and degrade the user interface responsiveness.
>However RedSwoosh, FoxTorrent and BitTorrent DNA all ran in separate processes that just handled all the BitTorrent stuff, and that you could talk to via https (to stream the file with a special url, and retrieve progress telemetry on another url). And it's incredibly easy to integrate xulrunner or any web browser with those servers via http, so no C++ XP/COM plugin required.
>Another issue is that you don't want every application to have its own BitTorrent client built in, or you will trash the network and disk, since otherwise they would compete for resources. It needs to be a centralized a system service, shared by any app that needs it.
>BitTorrent DNA worked nicely that way. And it could fall back to the CDN to download at full speed if there weren't enough seeders.
Also unfortunately, XULRunner was in no shape to run on mobile or embedded devices, so we ended up running WebKit on the TomTom embedded Linux devices, instead of trying to shoehorn Mozilla into small mobile devices.
https://news.ycombinator.com/item?id=34227548
>Both Chrome and Safari were based on WebKit (which itself started as a fork of KDE's KHTML and KJS libraries), which a lot of other vendors use too.
>Although Chrome eventually diverged years later with the development of Blink, Chrome was the result of a multi-company, industry-wide unification strategy on WebKit, the core of Safari. [...]
>Mozilla was in no shape to run on mobile or embedded devices (and still isn't afaik), while WebKit ran quite nicely on mobile and embedded devices, thank you. And as we all know, Android is as important to Google as iOS is to Apple.
>So there was really no chance of either of them (or any other of the many companies interested in mobile and embedded devices, like TomTom for example) ever building on top of Mozilla/xulrunner.
https://github.com/pg-tr/awesome-postgres
https://github.com/dhamaniasad/awesome-postgresI'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.
Perhaps more pertinent to the topic, in my last job I implemented the bulk of an XForms implementation. Pertinent because XForms has a lot of conceptual overlap with what I’ve seen in XMLUI so far.
I think it’s worth clarifying my point above with that context: it isn’t the concept that I find novel, at all. It’s the sheer depth and breadth of declarative expressiveness that I see in the examples. Maybe the best way I can put it is that what seems novel to me is how much novelty it appears to enable, before breaking through the abstraction to give it more capabilities.
The one theme for all platforms that was initially envisioned by Netscape kinda sucked ("Blue" for anyone that might remember.) And when Ben Goodger began his native-looking theme for Windows (pretty sure he started with preferences, maybe even before he got hired,) Dave got to work on Windows OS style queries and hooking OS style into XUL so the Mozilla suite's emerging new default theme could reflect those in its widgets. That work was ongoing even after most of the rest of XUL had been settled and I think Dave was still working on that even at Apple, right up until Mozilla decided Firefox would also ship on Mac and Linux and not just Windows* (as the several of us working on it has envisioned.) Once Firefox was running on Mac, Dave was precluded from continuing because of his Safari work. (He'd gotten permission to keep at when it was not directly competing with his Apple work.)
* Firefox was, for about its first year, meant to be Windows only. Ben Goodger had recently built a .Net wrapper for Gecko called Manticore, and there was Hyatt's Chimera for Mac, and Marco's Galeon for Linux, so the thinking was the major platforms would be covered with great standalone Gecko based browsers (no mail, HTML authoring, chat, etc.) But then Ben abandoned Manticore. Dave was convinced that XUL could actually kick ass on Windows (though also certain it could not on Mac) and so Ben started mozilla/browser to be the standalone Gecko browser for Windows. Ben also quickly abandoned that project and Blake Ross, an intern I'd recruited to Mozilla the year before, picked it up. He and I conspired on it with several others joining the effort during the end times at Netscape. Bryan Ryner stepped up to make it work on Linux, for example. staff@mozilla.org, well 5 of us I think, were sitting at a picnic table outside of Netscape's Bldg 21 when we decided that after Netscape wound down, we'd transition from the Suite to standalone browser and email (then called Phoenix and Minotaur). Cross platform would thus become a requirement. We weren't going to drop Seamonkey without replacements for it on Mac, Windows, and Linux. It took a while to get the Mac version up and running and as soon as that happened, Hyatt had to bail. About a year later, we released Firefox 1.0.
May your translations live in "interesting" documents.
https://www-archive.mozilla.org/projects/intl/iuc15/paper/iu...
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 ...
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.
Much like WinForms, there are still many internal line-of-business apps written in it decades ago that are just happily chugging along, ignoring all the post-Silverlight churn in Microsoft dev story.
I bought a massive 1000+ page book, "Pro WPF in C# 2010," one day. I also had to buy "Home Maintenance For Dummies" the same day. The bookstore cashier laughed at me.
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.
XUL from Mozilla, Silverlight and WPF from Microsoft, Glade for GTK and many others.
You define the widgets using markup then implement the behavior in some other language.
Then came Electron, Tauri and others that piggybacked on HTML and CSS.
VB is drag and drop. Put a button here, some label there. Double click here to add an event. Write a tiny bit of code in an editor that has autocomplete and boom.
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."
So his UI has 2 widgets: text input field and scrolled list. /s
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.