Live data from Hacker News

XMLUI

blog.jonudell.net

51–60 of 345 posts

Re: XMLUI

#51
> 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>

Re: XMLUI

#53
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.

Re: XMLUI

#54

Earlier quoted context omitted.

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…

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.

Re: XMLUI

#56

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 d…

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).

Re: XMLUI

#57
post #40

Earlier quoted context omitted.

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

Re: XMLUI

#58
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...

Re: XMLUI

#59

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

if the target audience is 'citizen developer', aka Visual Basic (classic), I am not sure introducing XSLT is such a good idea.

Re: XMLUI

#60
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.
Post reply on HN