Live data from Hacker News

XMLUI

blog.jonudell.net

41–50 of 345 posts

Re: XMLUI

#41

Impressive that they note: https://docs.xmlui.com/ >This site is an XMLUI™ app. but like pretty much every such system, it is assumed that one knows react and so forth, and how to manage a deployment --- if they really want to be compared to VisualBasic, what is the equivalent to: - buy VB - install VB - launch VB - develop app - test/compile - distribute .exe Probably I'm not the target audience, but if they had a "…

It’s painfully slow (on a newish mobile). While the concept is great for dynamic data, static docs are a terrible use case.

Re: XMLUI

#42
The author is probably too young to have experienced the crap of XML based interface. Like XUL and co.

But with another stack, I miss how good and easy it was to do great interfaces with Delphi in the good old time!

Re: XMLUI

#43
post #30

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 read this article originally as being a look back at some tech that somebody had made 20 years ago, that had a lot of interesting ideas, rather than someone suggesting yet another XML based UI mechanism.

Re: XMLUI

#44

The author is probably too young to have experienced the crap of XML based interface. Like XUL and co. But with another stack, I miss how good and easy it was to do great interfaces with Delphi in the good old time!

"Since 1995 nearly all of my professional work has been enabled by, and published on, the web." https://jonudell.net

Re: XMLUI

#45
I don't mind XML but the release is 4.23 MB. Minified. There are 90 dependencies (931 fully resolved).

Also, the Docs link to home.xmlui.com and don't resolve

Re: XMLUI

#46
post #33

Oh this brings me back. My first real coding job in 2003 was with a startup building dynamic user interfaces with XML, rendered with XSLT from the underlying data. It wasn't perfect, but it did feel correct , in the sense that a UX should be ultimately a pure function of data. Which is an idea that has never gone away.

2005-2007 I worked on a webapp where the app layer rendered to XML, and then optionally server-side applied an XSLT transform to generate either HTML, RSS, or Atom, but you could also request the raw XML (and browsers could apply the XSLT client side, but for debugging/testing it was great to be able to then also see the underlying XML.

It had some benefits in terms of enforcing strict separation as well, but it was also painful to deal with the many deficiencies of XSLT (e.g. try reformatting dates...) that meant the XML ended up having annoying redundant values where it was easier to provide multiple versions of the same value than doing the conversions in XSLT.

These days I'm doing something similar by having apps return JSON and having the I built dynamically from the JSON with javascript, and I like that better than the XML => XSLT as much as "in principle" I agree with you that the pure approach of XSLT feels "correct". It's just too painful to apply as-is.

Re: XMLUI

#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 drawing library will use Metal/OpenGL/DirectX as needed.

I find it refreshing that everything is imperative. You can put a breakpoint anywhere and you'll see when it gets called, with which parameters, by whom. You can also export intermediate rendering states to imdraw. Plus it's almost pixel-perfect (except for font antialiasing) on all platforms.

The XML variant being peddled here is, in my opinion, exactly what I usually try to avoid: framework-dependent magic. I'm 100% sure that 3 framework upgrades down the line, the layout will be slightly off. Because it was never you owning the layout, it was always you begging the framework for its consideration. The only thing that somewhat mitigates this issue with Electron is that it uses "old" technology. CSS isn't going to change much by itself anymore.

Re: XMLUI

#49
post #8

As a programmer I found that all no-or-less-code approaches break up sooner than one would expect. Eventually I chosen to always use the programming language itself for data fetching, looping and leave the templating (lit html in my case) to just passing in the data structures.

All abstractions break down. The more the e difference in in expressivity or complexity between the abstraction and whatever it abstracts, the faster it breaks down.

Re: XMLUI

#50
post #36

I applaud the idea of bringing back the Visual Basic model to the web. Again I don't expect people under 45 to remember how easy it was to develop a user interface that reacted to user actions. I just don't see the need to create a new language to do it. Firefox had XUL. And macromedia had Flex. Flex was amazing it had an XML version and an OOP one.. that where two views of exactly the same language.

Again I don't expect people under 45 to remember how easy it was to develop a user interface that reacted to user actions.

This recent HN submission gives a pretty good idea: https://news.ycombinator.com/item?id=44621102

Post reply on HN