Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XMLUI

blog.jonudell.net

Post reply on HN
Print view View original

131–140 of 345 posts

Re: XMLUI

#131

Post by judell »

cheschire wrote: post #3

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

I wrestled with how much history to bring into this because I want to look forward not back. The purpose of the announcement is to encourage people to try the tool and find out for themselves if it is a productive way to build the user interfaces they need.

Re: XMLUI

#132

Post by BrenBarn »

junon wrote: post #30
thisislife2 wrote: post #23

Seems like we keep reinventing the wheel - the previous version of of HTML, XHTML ( eXtensible HyperText Markup Language ) is a direct subset of XML. Also, related - Mozilla Firefox used to have something called XUL ( XML User Interface Language - https://en.wikipedia.org/wiki/XUL - using which you could build complete desktop web applications with the Firefox / Gecko web engine (something that is now popular with th…

XUL felt magical when it came out. Was kind of sad when it got sunset or whatever happened to it. Felt like it could have been something great.

I think it was a big missed opportunity. The frustrating thing about web UIs is that they don't obey my system-level display preferences (for stuff like fonts and colors). XUL was an approach that did that. Whether it's XML or something else is not the big issue, it's more a question of how to use a declarative style to specify a UI in a way that blends with the user's display preferences.

Re: XMLUI

#133

Post by fzaninotto »

This looks similar to React application frameworks like react-admin [1] or Refine [2]:

    const App = () => (
      
         
      
    )
    
    const PostList = () => (
      
        
          
          
          
        
      
    );
The article mentions XML, but the true revolution is JSX itself, which lets you describe any piece of logic as a React element. This opens the possibility to create DSL for everything, just like in Python.

[1]: https://github.com/marmelab/react-admin [2]: https://github.com/refinedev/refine

Re: XMLUI

#134

Post by judell »

eyelidlessness wrote: post #88
thisislife2 wrote: post #23

Seems like we keep reinventing the wheel - the previous version of of HTML, XHTML ( eXtensible HyperText Markup Language ) is a direct subset of XML. Also, related - Mozilla Firefox used to have something called XUL ( XML User Interface Language - https://en.wikipedia.org/wiki/XUL - using which you could build complete desktop web applications with the Firefox / Gecko web engine (something that is now popular with th…

I don’t think this is a reinvention of XHTML. It’s definitely closer in spirit to XUL, but seems different enough still that I wouldn’t call it reinvention. What seems particularly novel about this is that it’s taken the compositional approach of modern UI component libraries, and distilled it down to units of composition that can express a lot of behavior and logic declaratively . At least at a glance, that’s an imp…

I am not sure about prior art but the ability to mix built-in and user-defined components, and fluidly refactor the mixture, feels very powerful to me.

Re: XMLUI

#135

Post by MomsAVoxell »

fxtentacle wrote: post #48

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 have switched to JUCE as a total cross-platform GUI/high-performance general application development environment, having used it for 7 years in the audio realm I have attained that state, whatever it is, where I realize I can just use it for everything and it’ll be perfectly fine.

Doesn’t take too much CMake wrangling either, and once you’ve got at least one half-decent, clonable JUCE -> CI pipeline working, the horizon gets wider and wider ..

That said, I have to admit that I think more and more about how fun it’d be to just put all JUCE GUI code in a Lazarus’ish front-end, using LUA for that part, and having a decent half Lua/half C++ monstrosity for doing things ..

Re: XMLUI

#136

Post by edoceo »

mrweasel wrote: post #99

Using VB as a reference seems incorrect. Much of the appeal of Visual Basic, and Delphi, was the UI builder. Just click a button to create new project and you already had a window ready to go. Drag and drop in components, click buttons and what-not to wire up functionality. The barrier to entire was so incredibly low, having to edit XML files feels miles away from that ease of use. That being said Visual Basic also c…

VB didn't create those terrible programs, I did.

Re: XMLUI

#137

Post by toyg »

danielvaughn wrote: post #54
A4ET8a8uTh0_v2 wrote: post #34

Earlier quoted context omitted.

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…

You're basically correct, but this isn't due to a philosophical choice. Simply speaking, XSLT stopped evolving before Ajax really got popular, and it was eventually purged from most browsers altogether on security grounds. So nobody really tried to build XSLT engines that could address modern use-cases.

Somewhat ironically, the semantic web was initially supposed to be built on browsers making calls for XML data (the X in Ajax) to then be displayed via XSLT. This model failed to gain adoption mostly because, let's be honest, XSLT is just blooming hard.

Re: XMLUI

#138

Post by willseth »

danielvaughn wrote: post #54
A4ET8a8uTh0_v2 wrote: post #34

Earlier quoted context omitted.

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…

Recreating whole documents is how XSLT has been commonly used, but that’s an implementation detail, and you can nearly as easily write XSLT to produce components. You can output XHTML components and update the vdom - kind of an abstraction leak but not a bad tradeoff if you want to reuse the rendering XSLT. Alternatively, XSLT 3.0 can produce (and consume!) JSON, so you can use it as way to bridge XML into a traditional React app or to simply process JSON.

Re: XMLUI

#139

Post by david927 »

rossant wrote: post #125
thisislife2 wrote: post #23

Seems like we keep reinventing the wheel - the previous version of of HTML, XHTML ( eXtensible HyperText Markup Language ) is a direct subset of XML. Also, related - Mozilla Firefox used to have something called XUL ( XML User Interface Language - https://en.wikipedia.org/wiki/XUL - using which you could build complete desktop web applications with the Firefox / Gecko web engine (something that is now popular with th…

Reminds me of XAML and WPF.

I agree and that was a huge failure.

One of the big reasons VB died, people will tell you, was the language. And that's true. But what they don't mention is that the other reason was the components. I'm not sure this is replicating a success story but rather failing to learn from what was not a success story.

Re: XMLUI

#140

Post by CamperBob2 »

DonHopkins wrote: post #94
cxr wrote: post #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…

Great points! I love Nic Barker's frantic hand gestures while he explains how React works in that video. "Oh gosh, you don't want the hear this! Ha ha *grin*!": https://youtu.be/8ZlN07IvoPI?t=2654 There was an interesting hn discussion about immediate mode a few years ago: Immediate mode GUI https://news.ycombinator.com/item?id=19744513 http://behindthepixels.io/IMGUI/ I wrote up some of my own opinions: https://news…

Well, yeah, obviously, somebody has to retain some state at some point. The nice thing about a good IMGUI is that it's easy to integrate with your own state-maintenance logic. It's all about separation of concerns.

In practice, every time I've built an IMGUI, it's always turned into some kind of hybrid immediate/retained-mode approach. There's nothing desirable about forcing the business logic to remember the state of a button on the screen, after all. It comes down to how easy it is to build and maintain the mixed-paradigm model that everybody inevitably ends up with anyway.

In the case of the last framework I put together, individual buttons can be treated as true immediate-mode controls, where hit-testing, labeling, and other interaction with the program takes place at render time, while button groups retain the necessary state to lay themselves out, handle mutual exclusion, and so forth. Nothing keeps the app from maintaining its own list of buttons and calling it a group or whatever, but if I don't need to do that myself I can let the GUI do it.

Post reply on HN