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
Thanks for the 404 heads-up.
311–320 of 345 posts
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
Thanks for the 404 heads-up.
> The project we’re announcing today, XMLUI, brings the VB model to the modern web 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 clo…
So instead of ’const tubeStations = useDatasource()’ we now type ’ ’ and anything beyond this basic example is left as exercise for the reader. 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 finge…
The demo app shows a bunch of patterns. https://docs.xmlui.org/tutorial-01
Web standards are so powerful today with all the browser native form components etc, so I think one should just exploit that one and use XSLT ( https://caniuse.com/?search=xslt ) if you want to create an own "UI markup language". It'll render straight to everything that your browser supports, which is a lot. Then just use CSS to style it however you wish if you want to. What's nice about this approach is also that yo…
Almost immediately is the reason I don't like using this stuff. A hardcoded default value. There are so many things these UI generators can almost do but don't, and a default value for a dynamic selection is often one of the trickier ones to get right.
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.
Earlier quoted context omitted.
You keep making assertions and generalizations without backing them up with anything concrete while simultaneously moving goalposts. In the cases where you do, you’re just wrong: XSLT is not held back by licensing, it doesn’t “require one liners”, and it has supported JSON since 3.0, which has been around for almost a decade.
why the fuck would you want to use it with json. 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
I may be wrong because my domain knowledge is limited, but it seems to me this should marketed to novices and non-programmers instead of your typical hn crowd. As a novice frontend "builder", it sounds this was made for people like me, but not this blog post - give me examples, whys and limits - tell me I won't even need to learn how React works.
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
In 2004, we used this approach to drive QT to dynamically generate a UI for a (in retrospect) needlessly complex software installer. InstallShield use to make these horrifically difficult to maintain installers, combined with how visuals were stored in the MSI files. So, we then interpreted the XML back down to InstallShield dialogs, widgets, and their components. We extended the same to running pure QT on other plat…