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 "…
XMLUI
41–50 of 345 posts
Re: XMLUI
#42But with another stack, I miss how good and easy it was to do great interfaces with Delphi in the good old time!
Re: XMLUI
#43Seems 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.
Re: XMLUI
#44The 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
#45Also, the Docs link to home.xmlui.com and don't resolve
Re: XMLUI
#46Oh 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.
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
#47Re: XMLUI
#48I 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
#49As 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.
Re: XMLUI
#50I 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.
This recent HN submission gives a pretty good idea: https://news.ycombinator.com/item?id=44621102