24 ms·

XMLUI

• mattlondon 1y ago
  XML? Why not web components?
  • skrebbel 1y ago
    Focus, I'd assume.
  • deleted 1y ago
    [deleted]
• hulitu 1y ago
  > XMLUI So his UI has 2 widgets: text input field and scrolled list. /s
• cheschire 1y ago
  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 https://www.xml.com/pub/a/2003/08/13/udell.html
  • danielvaughn 1y ago
    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.
    • A4ET8a8uTh0_v2 1y ago
      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 a little deeper ) that XLST would likely be helpful.
      • danielvaughn 1y ago
        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.
        • toyg 1y ago
          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.
          • int_19h 1y ago
            I don't think it was ever "purged" - I mean, which modern browser doesn't handle XSLT 1.0? Nor did the spec itself stop evolving. The problem is that the browsers have deprecated the technology before XSLT 2+ could be adopted.
            • toyg 1y ago
              > which modern browser doesn't handle XSLT 1.0? I know it depends of the definition of "modern browser", but I'm fairly sure that MSIE and pre-chrome Edge had lost support for it at some point, since MSXML stopped being shipped with them. I honestly don't know what the current state of the art is, but Firefox doesn't do native XSLT anymore afaik (yes, you can do it in JS, but it's an extra step).
  • sheepscreek 1y ago
    The performance of available XSLT translation engines would be a big consideration for me, especially in a hot-reload context to support fast iterations.
    • thechao 1y ago
      That was my first thought: no XSLT 3 engine that I know of keeps an in-memory object that supports iterative retemplating on diff changes to the source. I think the closest to this is in the functional communities and their lenses. Given how "far" XSLT can reach through a document via Xpath, I don't think it's an easy-to-solve problem.
  • homarp 1y ago
    if the target audience is 'citizen developer', aka Visual Basic (classic), I am not sure introducing XSLT is such a good idea.
  • majewsky 1y ago
    Every time I've seen XSLT deployed, it was "that one hairball that no one besides the original author dares to touch". I'm not sure what it is about the technology, but it seems to either inevitably desolve into a complex mess or attract complexity fetishists. Either way, not something that would be an obvious choice for what OP is going for.
    • Quarrelsome 1y ago
      its because it demands to everything to be effectively processed in a one liner and is locked into its early version due to a licensing failure (I've yet to work in an org that pays up). So if you work in XSLT, then you're stuck in 1999. IMHO the pattern to improve XSLT is to call out into more useful languages like javascript, which ofc somewhat defeats the point of using it, but it is a useful pattern to slowly move away from it, when encountering it in legacy projects.
      • lolive 1y ago
        Reinventing XML traversal/transformation in JavaScript will lead really fast into abstracting away the recursive tree traversal, then mapping node marchers to functions. Which is 99% what XSLT provides off the shelf.
        • Quarrelsome 1y ago
          many developers just want to have some space to do some extra logic and XSLT doesn't really accommodate for that. You have to deal with the input and create the output without pausing for breath. While this is fine in simple use-cases where the mapping is 1-1 but when the mapping gets more complicated then it becomes difficult to maintain.
          • willseth 1y ago
            That’s simply not true. Certainly it can be hard to wrap your head around architecting complex logic in XSLT 1.0, but it's not unlike how you have to change your thinking for functional programming generally. More ergonomic imperative logic and several other features in XSLT 2.0 made it a much more developer friendly language.
  • leptons 1y ago
    >No mention of XSLT? Nope, but they sure had to make 1/2 the content about "AI" (otherwise nobody would read it?).
  • HellsMaddy 1y ago
    My first exposure to XSLT was sketchers.com: https://thedailywtf.com/articles/Sketchy-Skecherscom https://thedailywtf.com/articles/Sketchy-Skecherscom Sadly it doesn't seem like they're using it anymore.
    • donkeybeer 1y ago
      The example looks very minimal and neat by modern standards, shows how much messier modern websites are, I had to even think where is the "wtf".
  • judell 1y ago
    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.
  • bjoli 1y ago
    When I discovered oleh kiselyov's SXML/SSAX. It is such a amazing way to work with xml that I simply stopped doing xslt all together. SSAX is probably the best xml parser I have ever used.
  • shanghaikid 1y ago
    I remember Blizzard games' website were built by XSLT before, those websites were impressive.
  • stmw 1y ago
    To use XSLT effectively, you need an intuitive understanding of functional programming, a good grip on low-level HTML5/CSS details, and an engine that can run it quickly and correctly. The first of these is very rare, especially among business programmers. It is about as far away from the "Visual Basic-inspired" design goals of XMLUI as possible. Yes, both involve XML but that's where the similar ends.
• rand0m4r 1y ago
  it reminded me of Adobe Flex (probably without its "bad" parts) - nice work, congrats to the developers.
• ryandv 1y ago
  See also XAML: https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language https://en.wikipedia.org/wiki/Extensible_Application_Markup_...
  • vjvjvjvjghv 1y ago
    XAML is an example for how not to do it.
  • _mlbt 1y ago
    OpenLaszlo was even more similar to this… https://en.m.wikipedia.org/wiki/OpenLaszlo https://en.m.wikipedia.org/wiki/OpenLaszlo
• yoz-y 1y ago
  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.
  • criddell 1y ago
    I've also seen examples that are pushed way further than I thought possible. I'm thinking about some of the things people do in Excel.
    • airstrike 1y ago
      Spreadsheet is a form of programming, so you can build anything there.
      • cluckindan 1y ago
        Let’s see an HTTP server in an Excel sheet.
        • airstrike 1y ago
          That's a disingenuous take. You could write one, but it won't be allowed to connect to anything other than itself because Excel doesn't give it the network stack or IO it needs. Unless you use VBA, of course. See https://spreadsheets-are-all-you-need.ai/index.html https://spreadsheets-are-all-you-need.ai/index.html
          • shortstuffsushi 1y ago
            Maybe just me but seeing side by side "spreadsheets are all you need" and ".ai" seem to be somewhat uh... competing claims.
            • airstrike 1y ago
• WillAdams 1y ago
  Impressive that they note: https://docs.xmlui.com/ 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 "Minimal Working Example" of not just how to code, but also how to deploy an app (can it be run locally, say if I wanted something to keep track of my 3D printers and CNC machines?).
  • 38 1y ago
    [dead]
  • binarymax 1y ago
    It’s painfully slow (on a newish mobile). While the concept is great for dynamic data, static docs are a terrible use case.
• Animux 1y ago
  XMLUI reminds me of XUL (XML User Interface Language)
• vibbix 1y ago
  I spent a summer working on XAML UI's for an internship, and recently dove back in as a side project to update some Windows specific apps that rely on WinForms(https://github.com/hass-agent/hass.agent https://github.com/hass-agent/hass.agent). XML UI's are fairly underrated imo.
• LudwigNagasena 1y ago
  So it’s like JSX but with implicit imports and stringly-typed props?
• danielvaughn 1y ago
  Crazy, I just spent the past month designing an XML syntax for defining components. Weird coincidence. One issue I see in their choices is the HStack approach. What’s great about flexbox in CSS is that the flex direction can change dynamically. Admittedly I haven’t read the full docs for XMLUI, but binding the direction to the markup likely means you can’t do that.
  • sheepscreek 1y ago
    While flexbox is more powerful, those semantics would require prior knowledge of other CSS attributes and to develop an intuitive understanding of them.
• sheepscreek 1y ago
  I am super excited about the stuff we cannot see - I have a feeling the quality of engineering here is going to be solid + backed by consideration for the WYSIWYG programmers. Developing in Visual Basic is how programming became accessible for me as a kid. I could do stuff with ease that had seemed like magic and completely out of reach without C++ and complex pointer gymnastics. So thankful to the movement and I sincerely hope this project can bring that novice-first approach to web programming that does not compromise on responsiveness and smoothness, while making sane compromises, and doesn’t hold you back. Even more exciting is this - https://docs.xmlui.com/mcp https://docs.xmlui.com/mcp. It can reduce the amount of code tools like Claude need to generate (fewer tokens need to be generated) for a usable high-functioning UX/dashboard. I am going to start using this today.
  • judell 1y ago
    We would love to know how that goes.
• eviks 1y ago
  > 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 close an XML tag! And you didn't even have to know all the types to type in because you had a visible list of UI elements you could pick from
  • gryzzly 1y ago
    how do u like jsx then?
    • llbbdd 1y ago
      JSX has all the tooling available.
  • judell 1y ago
    The VSCode extension can help with some of that: https://docs.xmlui.org/vscode https://docs.xmlui.org/vscode
• derelicta 1y ago
  I knew folks were missing the Delphi-VCL and VB-WinForm experience. In a way, Flutter with Dart feels a bit like an attempt at bridging this gap between React-style web programming and those drag and drop UI and data builders.
• thisislife2 1y ago
  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 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 the Chromium Embedded Framework). (After Mozilla abandoned the XUL codebase, it has been forked and is now maintained as the Unified XUL Platform (UXP) implementation - https://forum.palemoon.org/viewtopic.php?f=46&t=30840 https://forum.palemoon.org/viewtopic.php?f=46&t=30840 ).
  • junon 1y ago
    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.
    • nailer 1y ago
      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.
      • DonHopkins 1y ago
        Using XML external entity references for i18n was certainly an "interesting" idea. May your translations live in "interesting" documents. https://www-archive.mozilla.org/projects/intl/iuc15/paper/iuc15xul.doc https://www-archive.mozilla.org/projects/intl/iuc15/paper/iu...
    • BrenBarn 1y ago
      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.
• righthand 1y ago
  Cool looking but it uses JSON? Weird choice to slap another data scheme on-top of your data scheme. I will stick with XSLT for the time being as it is pure XML. > return { name: stop.commonName, zone: getProp('Zone'), wifi: getProp('WiFi'), toilets: getProp('Toilets'), // A comma-separated list of line names that serve this stop lines: stop.lines ? stop.lines.map(line => line.name).join(', ') : '' }; }); }
• silverlight 1y ago
  Recently used a lot of HaxeUI for a game and it felt similar to this. A lot of components included out of the box that “just work” with some basic styling. And you can use CSS styling on top to further customize as needed. Works across a lot of different platforms as well.
  • hollander 1y ago
    I read that as Haskell and I definitely think HaskellUI would solve all problems. /j
• zigzag312 1y ago
  > XMLUI wraps React and CSS and provides a suite of components that you compose with XML markup. So this goes from XML → React → XML (HTML)? Are there any studies actually showing XML is easier to write that a scripting language? In my experience, XML is equally hard to write while being more limited.
• agnokapathetic 1y ago
  reminds me of Macromedia MXML (used in Flash, Coldfusion and Flex)! https://github.com/apache/royale-asjs/blob/develop/examples/mxroyale/DataGridExample/src/main/royale/DataGridExample.mxml https://github.com/apache/royale-asjs/blob/develop/examples/...
  • DonHopkins 1y ago
    OpenLaszlo was an eariler, more powerful, more fun, open source alternative to FLEX. It's obsolete now that Flash is dead, but I really got in the "zone" with it. Residential, Commercial and Industrial zones: https://www.youtube.com/watch?v=8snnqQSI0GE https://www.youtube.com/watch?v=8snnqQSI0GE https://github.com/SimHacker/micropolis/tree/master/laszlo/micropolis/classes https://github.com/SimHacker/micropolis/tree/master/laszlo/m... Here's some stuff about OpenLaszlo and other related ui systems: https://news.ycombinator.com/item?id=21841054 https://news.ycombinator.com/item?id=21841054 DonHopkins on Dec 20, 2019 | parent [–] My remark was just an old Java joke I repurposed for Ant! "Java is a DSL for taking large XML files and converting them to stack traces." -Andrew Back https://www.reddit.com/r/programming/comments/eaqgk/java_is_a_dsl_for_taking_large_xml_files_and/ https://www.reddit.com/r/programming/comments/eaqgk/java_is_... But in all seriousness: OpenLaszlo used XML with embedded JavaScript in a way that let you extend XML by defining your own tags in XML+JavaScript. I've done a lot of work with it, and once you make your peace with XML (which seemed like a prudent thing to do at the time), it's a really productive enjoyable way to program! But that's more thanks to the design of OpenLaszlo itself, rather than XML. https://en.wikipedia.org/wiki/OpenLaszlo https://en.wikipedia.org/wiki/OpenLaszlo OpenLaszlo (which was released in 2001) inspired Adobe Flex (which was released in 2004), but Flex missed the point of several of the most important aspects of OpenLaszlo (first and foremost being cross platform and not locking you into Flash, which was the entire point of Flex, but also the declarative constraints and "Instance First Development" and the "Instance Substitution Principal", as defined by Oliver Steele). https://en.wikipedia.org/wiki/Apache_Flex https://en.wikipedia.org/wiki/Apache_Flex https://web.archive.org/web/20190318072102/https://blog.osteele.com/2004/03/classes-and-prototypes/ https://web.archive.org/web/20190318072102/https://blog.oste... The mantle of constraint based programming (but not Instance First Development) has been recently taken up by "Reactive Programming" craze (which is great, but would be better with a more homoiconic language that supported Instance First Development and the Instance Substitution Principle, which are different but complementary features with a lot of synergy). The term "Reactive Programming" describes a popular old idea: what spreadsheets had been doing for decades. OpenLaszlo and Garnet (a research user interface system written by Brad Myers at CMU in Common Lisp) were exploring applying automatic constraints to user interface programming. Garnet started in the early 1990's. Before that, Ivan Sutherland's Sketchpad explored constraints in 1963, and inspired the Visual Geometry Project in the mid 1980's and The Geometer's Sketchpad in 1995. https://en.wikipedia.org/wiki/Reactive_programming https://en.wikipedia.org/wiki/Reactive_programming http://www.cs.cmu.edu/afs/cs/project/garnet/www/garnet-home.html http://www.cs.cmu.edu/afs/cs/project/garnet/www/garnet-home.... https://en.wikipedia.org/wiki/Sketchpad https://en.wikipedia.org/wiki/Sketchpad http://math.coe.uga.edu/TME/Issues/v10n2/4scher.pdf http://math.coe.uga.edu/TME/Issues/v10n2/4scher.pdf https://en.wikipedia.org/wiki/The_Geometer%27s_Sketchpad https://en.wikipedia.org/wiki/The_Geometer%27s_Sketchpad I've written more about OpenLaszlo and Garnet: What is OpenLaszlo, and what's it good for? https://web.archive.org/web/20160312145555/http://donhopkins.com/drupal/node/124 https://web.archive.org/web/20160312145555/http://donhopkins... >Declarative Programming: Declarative programming is an elegant way of writing code that describes what to do, instead of how to do it. OpenLaszlo supports declarative programming in many ways: using XML to declare JavaScript classes, create object instances, configure them with automatic constraints, and bind them to XML datasets. Declarative programming dovetails and synergizes with other important OpenLaszlo techniques including objects, prototypes, events, constraints, data binding and instance first development. Constraints and Prototypes in Garnet and Laszlo https://web.archive.org/web/20160405015129/http://www.donhopkins.com/drupal/node/69 https://web.archive.org/web/20160405015129/http://www.donhop... >Garnet is an advanced user interface development environment written in Common Lisp, developed by Brad Meyers (the author of the article). I worked for Brad on the Garnet project at the CMU CS department back in 1992-3. More about TCL/Tk, OpenLaszlo, Garnet, constraint programming, history of constraints: Coco KVO, Objective Smalltalk constraints, Sutherland, Sketchpad, Geometers Sketchpad, Knowledge Representation frames, push vs pull constraints, etc: https://news.ycombinator.com/item?id=17360883 https://news.ycombinator.com/item?id=17360883
• guestbest 1y ago
  Reminds me of renaissance for openstep. https://github.com/gnustep/libs-renaissance https://github.com/gnustep/libs-renaissance
• lukev 1y ago
  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.
  • vidarh 1y ago
    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.
• ako 1y ago
  This makes a lot of sense: with AIs generating a large amount of code, the challenge moves towards validation and testing. If you generate towards a higher level of abstraction, there's less code and less moving parts to be reviewed and validated. Think of it as low-code/DSLs for GenAI, still code, but with less technical details to review and test.
• elviejo 1y ago
  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.
  • toyg 1y ago
    Let's be honest, XUL was a pain for a number of mozilla-specific choices (rdf...). A lighter, better XUL would be absolutely fine.
    • elviejo 1y ago
      I think Flex was that better XUL
  • mikestew 1y ago
    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 https://news.ycombinator.com/item?id=44621102
• api 1y ago
  There was so much work done in the 80s and 90s on RAD — rapid application development — that was all thrown in the trash when the web hit. 20+ years later we’ve managed to finally build up the right combination of hacks to make the web a passable application platform but it still feels like you’re forcing it. Because you are. The web was not designed to be an app platform and it shows. Still.
  • dxroshan 1y ago
    Great point!
• thom 1y ago
  Just like there's a massive community of Microsoft-adjacent technologists who still think C++ can do new and exciting things, there's a similar community who think XML components with declarative databindings are also going to make a comeback. I think (with some nostalgia and sadness) both of these ideas have been soundly thrashed in the marketplace of ideas.
• greatgib 1y ago
  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!
  • spenrose 1y ago
    "Since 1995 nearly all of my professional work has been enabled by, and published on, the web." https://jonudell.net https://jonudell.net
    • greatgib 1y ago
      I stand corrected: The Microsoft era (2007-2014) In Jan 2007 I joined Microsoft as an evangelist. Exactly at the time that Microsoft pushed for the XAML crap... So indeed not reinvented the wheel, just not having giving it up despite the complete failure of it.
      • cjbgkagh 1y ago
        I like XAML, the whole point of it is tooling support which was undermined when the tools were so buggy for so long. Now that many of the bugs have been fixed and computers are much faster it’s become a really productive UI paradigm for me. I’ll eventually switch over to Avalonia for better performance and cross platform support.
        • greatgib 1y ago
          You do Windows GUI development?
          • cjbgkagh 1y ago
            Yes, among many other things. Applied Researcher so full stack and constant greenfield. I also worked at DevDiv MS during the Foundation series era so I know why many of the issues with WPF are there, basically political infighting and penny pinching. It didn’t help that Gates quit and Balmer took over. Patterns and Practices didn’t properly understand WPF so they gave bad official advice on how to solve problems, it didn’t help that this was near peak Object Oriented mania and language features like generics were still new so there was a lot of unnecessary boilerplate. Code generation did help with this. WPF has a very high skill threshold for making custom controls that are not just compositions of existing controls, open sourcing WPF has helped a lot with this. WPF is a flawed implementation of a really good idea, and if you can work around the flaws like I do then it’s actually really great. I totally understand why other people don’t like it. I know it’ll sounds like I’m a snobbish hipster but the vast majority of people never get to the skill level required to properly use these tools. And while React starts out easier it doesn’t stay that way.
• tbeseda 1y ago
  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
  • judell 1y ago
    We will soon have a way for standalone apps to shed unused dependencies, just as the build for the docs site does. Thanks for the 404 heads-up.
• efitz 1y ago
  This seems like a neat idea that is 20 years too late.
• fxtentacle 1y ago
  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.
  • CharlesW 1y ago
    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).
  • righthand 1y ago
    I haven’t tried JUCE yet but I miss the days where everything was a C++ class in Qt. Everyone clamours for a templating language but: class MyButton extends QObject { … $button = new Button(); $button->color = “blue”; $icon = new Svg(); $layout = new QtHorizontal(); $layout->push($icon, $button); $this->layout = $layout; … } This to me is much more readable than fiddling with stacked, embedded, and nested mustache/XML syntax split across files. Templating languages only really guarantee one unique thing about understanding the code: “Is my module embedded under the correct parent module?”
  • 1y ago
• cxr 1y ago
  > 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 https://www.youtube.com/watch?v=8ZlN07IvoPI&t=2131s>
  • DonHopkins 1y ago
• DrStartup 1y ago
  XUL! why not just use htmx and the platform?
  • cluckindan 1y ago
    Because using htmx is asking to get defaced via XSS, or worse. Security is an afterthought for the project, which is evident from the placement of the related documentation.
    • rockwotj 1y ago
      How is this better?
      • cluckindan 1y ago
        It probably isn’t.
    • recursivedoubts 1y ago
      security rules for htmx are no different than any other hypermedia approach: you need to escape all user content https://htmx.org/essays/web-security-basics-with-htmx/ https://htmx.org/essays/web-security-basics-with-htmx/
• general1726 1y ago
  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.
  • waltbosz 1y ago
    Maybe I just didn't understand it but to me WPF felt like it was designed by an insane person.
• franze 1y ago
  Those who do not understand (or remember) XUL are forced to reinvent it. see https://www-archive.mozilla.org/xpfe/xui.html https://www-archive.mozilla.org/xpfe/xui.html
  • int_19h 1y ago
    Using XML to declaratively define UI trees is an idea so obvious that many developers back in late 90s - early 00s had their own bespoke frameworks for that. And you know what? It worked great. WPF with XAML - from 2006 originally! - is still, to this day, by far the easiest way to write a desktop Windows app with adaptive layout etc.
  • cbsmith 1y ago
    Pretty sure Jon Udell remembers XUL.
    • judell 1y ago
      I do indeed.
      • cbsmith 1y ago
        /me feigns shock
  • CharlesW 1y ago
    If XMLUI is a reinvention of XUL, then XUL* is just a reinvention of the many XML-based UI markup languages before it. * Fun fact: XUL was conceived at Netscape. Mozilla adopted it for XPFE.
    • asadotzler 1y ago
      XUL was conceived by Dave Hyatt FOR Mozilla AT Netscape. Netscape was going to end development of not-Windows Mozilla because maintaining 3 front-end teams was more than the Netscape/Mozilla leadership believed it had resources for and XPFE was the solution. If you believe XUL was developed for anything other than Mozilla's XPFE, you have been mislead. Also, would you please provide names for those many pre-XUL XML-based UI languages I'm genuinely curious. Other than the web itself, HTML+JS+CSS, I'm at a loss for what those many XML-based UI markup languages you're referring to could possibly be. As a Mozilla participant at Netscape, and someone with hours of discussion with Hyatt over those early years, and a (very small) contributor to XPFE as early as Dave's XUL menus first draft, I'd be real interested to learn about prior art. Did we somehow miss all of those per-existing examples?
• djha-skin 1y ago
  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/ https://google.github.io/paper-gui/ 2: https://polymer-library.polymer-project.org/1.0/docs/about_10 https://polymer-library.polymer-project.org/1.0/docs/about_1...
• mattmcknight 1y ago
  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.
• mnafees 1y ago
  I wrote Qt C++ for 7 years as an open source contributor to KDE. This reminds me of QtWidgets’ .ui files—custom XML files following a specific schema. Later, Qt introduced QML, which I personally found unintuitive, and over time I lost interest in Qt altogether. That said, I still think XML for UI definitions makes sense, and it’s understandable that some larger environments continue to use it.
  • hermitcrab 1y ago
    Some of us are still programming in Qt using just C++ and .ui files. Never bothered to switch to QML. I wasn't convinced there were enough advantages to make it worth the effort.
    • mnafees 1y ago
      Hah, that is awesome. How does Qt fare these days in the non-Linux world though?
      • hermitcrab 1y ago
        Good on Windows. Pretty good on Mac, but never quite looks 100%. Not sure how well Qt is going to cope with macOS 26 style transparency though.
      • dekhn 1y ago
        This weekend I asked Gemini Pro to create a Python Qt app (a serial file sender- something you'd use to send g-code files to a CNC machine or laser cutter). I did most of the dev on Windows but the app will run exactly the same on all 3 main platforms. Eventually I asked Gemini to extract the UI to its own .ui file, which it did. The resulting app worked better than the previous one I had coded myself (handling some various race conditions and other challenging issues much more quickly than me). If I wanted, I coudl ask gemini to port the app to C++. (Gemini isn't the point here- that's just speeding up what I would have done on my own).
      • mroche 1y ago
        Nearly every widely-used commercial or in-house tool in the VFX and Animation sector of M&E are Qt based. The main difference compared to tradition desktop developers is the general attitude of design; the industry takes the stance of providing the same application experience across platforms, rather than trying to adhere to each platforms' UI/UX guidelines. Examples: Autodesk Maya, 3DS Max, Mudbox Foundry Nuke, Mari, Katana SideFX Houdini Substance Painter, Designer
• zkxjzmswkwl 1y ago
  So Winforms for React.
• tempu68653 1y ago
  [dead]
• emorning3 1y ago
  [dead]
• doug_durham 1y ago
  The ergonomics makes my eyes bleed. I think we can do better.
• tomsonj 1y ago
  android layout xml is great, glad to see more broad attempts
• cubefox 1y ago
  Unfortunately this doesn't provide a comparison to similar solutions, like XUL or htmx.
• zamalek 1y ago
  XAML (at least the tighter-scoped Silverlight incarnation of it) was an absolute joy to use - if you used it correctly. It was an absolute monster if you used it in the most obvious (and incorrect) way. That's probably the reason other than HTML5 that it fell off: good tools steer novices into the pit of success, and XAML really didn't do that at all.
  • sedatk 1y ago
    I'm sure Microsoft hopping from one XAML implementation to an entirely new one every five years didn't help either.
• theknarf 1y ago
  So you built a worse alternative to React, on top of React?
• stillpointlab 1y ago
  This looks (at a glance) similar in many ways to Adobe's defunct MXML [1] which was the backbone of the Flex platform built on Flash. Apparently this lives on in Apache Royale [2] Using XML for an user interface description language is quite common, from XUL to XAML to JSX. In my experience, XML is well suited to this task. 1. https://en.wikipedia.org/wiki/MXML https://en.wikipedia.org/wiki/MXML 2. https://apache.github.io/royale-docs/features/mxml https://apache.github.io/royale-docs/features/mxml
• sirjaz 1y ago
  This reminds me of xaml with css thrown in. It is almost like this validates Microsoft's blazor plans with C#
• emorning3 1y ago
  [dead]
• Neywiny 1y ago
  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.
  • judell 1y ago
    Here's the How To for that: https://docs.xmlui.org/howto#set-the-initial-value-of-a-select-from-fetched-data https://docs.xmlui.org/howto#set-the-initial-value-of-a-sele... 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.
    • Neywiny 1y ago
      No offense, but you failed here. What if nothing gets returned? Now you're basically just writing code. Debatably even that example you're just writing code. An onLoad callback with array indexing and child access? This is just JavaScript wrapped in XML.
• mrweasel 1y ago
  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 create some absolutely terrible programs.
  • jeroenhd 1y ago
    Before Compose took over as the new direction for Android app development, the Android Studio designer IDE had a very VB6-style designer where you could drag and drop components, while the underlying UI files were all XML based. The callback generation wasn't as easy as with VB, and different phone sizes meant you had to deal with resizing (which VB applications usually just didn't bother with), but the experience was pretty good. These days you've got Gambas for a free and open source VB, including the terrible language, but in my experience the looks are a bit off when you design on one desktop environment and run the application on another.
    • sp0rk 1y ago
      > These days you've got Gambas for a free and open source VB, including the terrible language, but in my experience the looks are a bit off when you design on one desktop environment and run the application on another. There is also Lazarus[1], which uses Pascal but feels closer to what I remember of the VB6 experience. 1: https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
    • hn8726 1y ago
      > Before Compose took over as the new direction for Android app development, the Android Studio designer IDE had a very VB6-style designer where you could drag and drop components, while the underlying UI files were all XML based. It's important to note that pretty much nobody used the visual designer though. The resulting xml was pretty terrible, writing the UIs manually (in xmls, while looking at preview) was infinitely better
• rao-v 1y ago
  I kind of want Python to have a desktop / web neutral library that does this and always am annoyed to learn it does not exist. Do folks understand why?
• jeroenhd 1y ago
  XML UI is all over the place. I'm working with some legacy code using JSF with some extensions and it's pretty much everything described here. There's a Java server involved so it doesn't work with saved pages (but it automatically takes care of any backend calls, so unless you want an offline-first app that can be a benefit actually). I'm pretty sure ASP.NET, or whatever Microsoft calls it these days, works very similarly. The frontend pendulum keeps swinging back and forth between serverside rendering and clientside rendering so maybe in a few years we can reinvent ASP/JSF and call it revolutionary again.
• jug 1y ago
  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 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 you can create a true domain-specific markup language, which will always be more clean and compact than a generic one.
  • judell 1y ago
    We are aiming for people who not only don't want (or are not able) to learn/write React, but also CSS.
• cgannett 1y ago
  I am simultaneously in the seemingly opposite camps of "haha we reinvent HTML lol" and "Actually this sounds immediately useful to me". To be human is to be multitudes.
  • judell 1y ago
    Beautifully said. All that matters in the end: will it be immediately useful to people like you who imagine that it might be?
  • b_e_n_t_o_n 1y ago
    Thank you putting me onto this concept. I had not heard of Walt Whitman or his work before. "Do I contradict myself? Very well, then I contradict myself."
  • rcbdev 1y ago
    "Only that, which carries contradiction within itself, is alive." - G. W. F. Hegel
• cluckindan 1y ago
  If this doesn’t use a compiler, the ”when” feature looks like it will require 'unsafe-eval' and potentially 'unsafe-inline' to be enabled in content security policy, which will disable browser XSS protections. Not optimal for an easy-to-use component system intended for display of remote data. Edit: I don’t see a CSP on the dogfooded homepage so I would assume this is an issue.
  • btown 1y ago
    Just ship https://github.com/NeilFraser/JS-Interpreter https://github.com/NeilFraser/JS-Interpreter and you’re good to go! /s
    • btown 1y ago
      As a follow-up: Angular actually did this! https://docs.angularjs.org/guide/expression https://docs.angularjs.org/guide/expression > AngularJS does not use JavaScript's eval() to evaluate expressions. Instead AngularJS's $parse service processes these expressions.
      • cluckindan 1y ago
        Note that those are the AngularJS aka ”Angular 1” docs. For Angular as in ”Angular 2” docs, see https://angular.dev/guide/templates/expression-syntax https://angular.dev/guide/templates/expression-syntax
    • cluckindan 1y ago
      Looks like they actually went this route, but implemented it from scratch.
  • dotneteer 1y ago
    XMLUI does not execute JavaScript with "eval" or anything that would not comply with CSP. It runs interpreted JavaScript asynchronously in a sandbox and does not allow use of "eval" (and another dozen low-level functions, such as setTimeout).
• lstroud 1y ago
  My recollection of XUL was that it was great when it worked, but horrific to debug. It wasn’t also easy to make a living fixing bad VB apps (or going back to Delphi). I’m not saying that components are a bad idea, but the 90s implementations didn’t quite realize the dream.
  • asadotzler 1y ago
    It was pretty easy to debug most of it with Dom Inspector and Venkman, themselves written in XUL. Even the XBL bindings and other sometimes challenging bits, were directly inspectable and editable. As a minor contributor to Mozilla's early XUL work and later Firefox's XUL work, mostly stripping XUL overlays and reducing clutter in the Firefox case, it seemed pretty straight forward to me.
• ta8645 1y ago
  Direct links to their web landing page, and Github code: https://xmlui.com https://xmlui.com https://github.com/xmlui-org/xmlui https://github.com/xmlui-org/xmlui
• fzaninotto 1y ago
  This looks similar to React application frameworks like react-admin [1] or Refine [2]: const App = () => ( <Admin dataProvider={dataProvider}> <Resource name="posts" list={PostList} /> </Admin> ) const PostList = () => ( <List> <DataTable> <DataTable.Col source="date" /> <DataTable.Col source="title /> <DataTable.Col source="author" /> </DataTable> </List> ); 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 https://github.com/marmelab/react-admin [2]: https://github.com/refinedev/refine https://github.com/refinedev/refine
• citizenkeen 1y ago
  Is this supposed to be unreadable raw code or is the site overloaded?
• hoistbypetard 1y ago
  When I click the link, I just get a bunch of JSON... https://pasteboard.co/Rpp35synt4CW.png https://pasteboard.co/Rpp35synt4CW.png Am I missing a joke, or has something broken?
• pdntspa 1y ago
  Yet another implementation of data binding
• max-privatevoid 1y ago
  Surely this has to be a joke. If I wanted to write web stuff in XML, I would just write HTML.
  • bjoli 1y ago
    I will be that guy: HTML is not XML. People wanted to write malformed html so xhtml never went anywhere.
• lutusp 1y ago
  Eventually people will separate interface from implementation, not unlike the now-disparaged OO programming paradigm. But not yet. This article discusses something well-known among insiders -- interface schemes frequently expire along with their hosting language, because they're not a recognizable, separate entity. After AI entirely takes over programming, interfaces will become more portable and platform-agnostic than they are now. "AI, write me a word processor." "What language?" "I don't care ... do you?" Alternative reply: "COBOL, just because I know you can."
• LePetitPrince 1y ago
  [dead]
• tacker2000 1y ago
  This stuff is not new, many React libraries have been doing since years, eg. the DataTable component of Primereact [1] [1] https://primereact.org/datatable/ https://primereact.org/datatable/
• boomskats 1y ago
  I like what RJSF did with uiSchema[0] for their presentation layer (to supplement the jsonSchema model definitions). It's been a while since I played with it but I remember thinking it was well thought out & being surprised that it wasn't more widely adopted. [0]: https://rjsf-team.github.io/react-jsonschema-form/docs/api-reference/uiSchema/ https://rjsf-team.github.io/react-jsonschema-form/docs/api-r...
• wiso 1y ago
  Looks like XAML https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language https://en.wikipedia.org/wiki/Extensible_Application_Markup_...
• spankalee 1y ago
  I'm trying to build something very much like this, except that it's based on standard HTML, web components, and signals - it's called Heximal: https://heximal.dev/ https://heximal.dev/ I think HTML with expressions, templates, reactivity, and components is a really great substrate for these very modular, declarative apps and pages. And a lot of the things added on top of HTML could conceivably be standardized.
  • cheshire_cat 1y ago
    I can't fully see the text on mobile, the beginning is cut off and zooming out doesn't help. Just so you know. :)
  • mtlynch 1y ago
    Your idea sounds interesting but your site is unreadable on mobile (Android+Firefox).
  • bloqs 1y ago
    Hi, cant read your site? other comments arent loading on my HN app so not sure if other people have same issue. Mobile firefox
  • actionfromafar 1y ago
    I think this could catch on, very much like C++ caught on. It’s very powerful to be backwards compatible.
  • phatskat 1y ago
    Gonna echo what someone else said, I can’t seem to fit the whole page text on my phone in portrait orientation.
  • ishi 1y ago
    This sounds exactly like Zope's DTML template language, from 25 years ago. https://zope.readthedocs.io/en/latest/zopebook/AppendixA.html https://zope.readthedocs.io/en/latest/zopebook/AppendixA.htm...
• deleted 1y ago
  [deleted]
• _micheee 1y ago
  This reminds me of XForms and its fully declarative approach. It allowed you to add interactivity to your HTML without writing code.
• nzoschke 1y ago
  Looks neat! As humans augmented with agents write more code, solutions that require less context shifting to get stuff done will win. A common web stack may include API handlers, OpenAPI spec, generated TypeScript definitions, generated TypeScript client, React logic and effects code, TSX code, HTML, and CSS. This generally needs filesystem watchers, code generators, transpilers, compilers to get stuff done. Something that can go from a backend handlers straight to terse markup for reactive UI would be a massive simplification to all this, and a big productivity boost.
  • lelanthran 1y ago
    > Something that can go from a backend handlers straight to terse markup for reactive UI would be a massive simplification to all this, and a big productivity boost. I do this for custom software I build for clients, mostly on the backend though[1]. Started it two years ago, have rapid velocity and, without AI generally take 30 to 60 minutes to implement a new feature that touches backend persistence and front end UI. ‐---------- [1] I did a show HN on a tiny front end component that gets the most use, recently, I think. ISTR most people in the comments said they they preferred React, a few said it was not novel enough to be a paper (they are correct. It isn't). You can see it here: https://github.com/lelanthran/ZjsComponent/ https://github.com/lelanthran/ZjsComponent/ I'm not really in the mood to open up the whole stack I use yet, I still make money bu having a low effort way to build web apps, and due to the way it works it requires a fraction of the tokens required when actually using AI assist (output for the last time I implemented a backend call from scratch was 10 lines, most of which were comments).
• Gluber 1y ago
  The browser platform with HTML/CSS is fundamently legacy over legacy and broken for most application styles ( not general pages ), and incurs insane development costs for even simple things ( been there done that for close to 17 years ) The current best option IMO is: Open Full Browser window size canvas (with webgl, webgpu backend graphics ) and draw everyhing yourself ( meaning with something else than the browser layout engine, lots of options available, Flutter, Avalonia etc... ) and deploy with your favourite programming language through WASM. In fact a next generation browser should bascially be this, with the legacy browser functionality implemented as a WASM module that draws to this single canvas... The browser would become small and much easiert to secure ( only input, audio and general WASI style apis missing and to secure )
  • koito17 1y ago
    > Full Browser window size cancas ... and draw everything yourself This was already tried to some extent with Flash. Many sites were a single Flash module (or multiple). Implementing accessibility then required maintaining an invisible DOM representation of the Flash canvas. I personally don't want to return to the era where login and register buttons were dedicated Flash modules (MegaUpload did this back in ~2009) and many sites were an 800x600 image using the <area> tag for hitpoints. Even Flutter has a DOM target because painting to a full <canvas> violates at the very least the operating system's text rendering, scrolling, and accessibility.
    • Gluber 1y ago
      I agree with you that these things are important. However they are ( in implementation terms ) rather small issues, and determining i rather pay 4-8x more in development and maintenance costs just for this, while you can go the other way and make those features a bit hardware to implement seems like a not so good business case to me. e.g we are using Avalonia. Of course everything is drawn in a scalable way, with responsive design etc... Accessibility is built in of course ( with integration with the relevant browser apis ) screenreaders work perfectly as do other accessibility features ) Its not the hap hazard way that flash did this (before there were relevant standards for these features anyways ) Invoking a brower api / interop is easy, the difference is we do not need to compromise our productivity for small things.
• esprehn 1y ago
  This was tried with Polymer way back in 2014 too, ex. making network requests with <iron-ajax> - https://github.com/PolymerElements/iron-ajax https://github.com/PolymerElements/iron-ajax There was also Adobe Flex of the similar era that exists these days as Apache Royale: https://apache.github.io/royale-docs/features/mxml https://apache.github.io/royale-docs/features/mxml There was also XAML and inside Microsoft they made NetUI and FlexUI to make Office 2007+ too. It all seems great on paper, but in practice the markup abstraction turned out to be worse than code first solutions like JSX even for novices.
  • int_19h 1y ago
    XAML is still very much a thing on Microsoft platforms, and contrary to your assertion, it still works very well. I would even go so far as to say that WPF (the original XAML-based framework) is still the best UI framework around if cross-platform is not a requirement.
  • colordrops 1y ago
    And coldfusion shudder
  • hahn-kev 1y ago
    It's funny because it reminds me of Angular in that it's very markdown heavy with the code behind in another file. So they wrapped React to make angular.
    • apsurd 1y ago
      angular was dead on arrival - to me - because it seems nuts to bolt on full programming language constructs into html attributes. In the same way React easily won because it chose the exact opposite: put the UI constructs inside the full programming language. Both have their worts, but I'm perpetually puzzled by how angular ever made sense as ergonomic. I suppose people like Vue so there's still some insistence on augmenting templates with programming constructs. Seems inevitable that templates will want more and more powerful constructs... and boom.
• wiremine 1y ago
  Jon has been around for a long time, and I've been a long-time fan. He's a bit of an elder: he's seen a lot of things, and he's worth listening to. > I’m a fan of web components but it’s the React flavor that dominate and they are not accessible to the kind of developer who could productively use Visual Basic components back in the day. I think this is the most important statement in the piece. The rest of the post explains the technical details, but this explains _why_ this exists. This is a bold statement, but I don't think he's wrong. Now, is XMLUI the _right_ set of abstractions to help these developers? We'll have to wait an see. But I love to see the attempt!
  • 1oooqooq 1y ago
    code currently only works on JS evergreen browsers. i guess like VB only worked with windows and if shipped with the right DLLs.
    • nine_k 1y ago
      Windows is a narrower platform than evergreen JS-enabled browsers, and the relevance of Windows as a platform is only going to go down. So the choice of the platform is right. What are some GUI-enabled devices you wish you were able to address, but which cannot run Firefox, Safari, or a Chromium derivative?
    • lmz 1y ago
      So, exactly like VB? (From memory it required a msvbvm DLL).
      • schnable 1y ago
        VBRUN300.DLL
  • madeofpalk 1y ago
    The funny thing about this - and I don't know whether this is as good or a bad thing - is that you could probably almost implement this XMLUI entirely in React/JSX. Glancing over the markup, none of this seems too alien to React. This all seems not too dissimilar to the generic pages-as-JSON DSL that every CMS/developer reinvents every other project.
• optymizer 1y ago
  What's old is new again. It's Adobe Flex for the kids. I like it.
• 20after4 1y ago
  This combined with something like Datasette¹ would be a really nice toolbox for quickly developing simple database applications. 1. https://datasette.io/ https://datasette.io/
• shireboy 1y ago
  I dunno. I pretty much skipped over XAML, which is very similar for .NET desktop UI. Maybe this sticks better because it’s not MS? I certainly think current frameworks tend to be too much cruft for LOB/forms-on-data apps. But a special xml seems wrong to me.
• abujazar 1y ago
  https://xkcd.com/927/ https://xkcd.com/927/
• atum47 1y ago
  I've downloaded and printed the whole manual for action script 3 when I was an artist (I've always dabbled in programming), apparently you could create pretty robust web apps with XML. Never had the time to create one myself and as3 was dead soon after that, I think jQuery killed it.
  • msgodel 1y ago
    It seems a little strange to accuse jquery. I think what actually "killed it" was modern HTML. Jquery was just an intermediate API that let you target modern browsers and IE without having duplicate/shim code to maintain yourself.
    • atum47 1y ago
      That's why I said "think"
• npalli 1y ago
  Surely, this has been tried many times - Microsoft with XAML for WPF, Silverlight (Flash killer), Forms, Adobe Flex (MXML), Google XML for Android, XUL etc. etc. All seem to suffer from the problems that Visual Basic did not have and becomes obvious when you go beyond some simple forms. OP seems to a long timer in this space so surprising shrug * difficulty in mapping complex UI layouts to XML (VB was quite literally WYSIWYG and mind-blowing for its time) * Verbose to specify (esp. multilevel nesting, complex navigation etc..) * Cannot make sense of the XML content vs all the nested tags * Keep switching between how the UI looks and the XML ... all generally point to the difficulty of separation of configuration and behavior.
• webprofusion 1y ago
  Close but no cigar, if you're trying to achieve VB like hunt and peck productivity then XML doesn't cut it any more now than it has in the last 30 years or so. Blazor is pretty productive if you're looking for a mature component based XML (Razor) syntax but again, there is no Visual design element to throw thing together.
• d--b 1y ago
  It’s a stretch to believe that VB users are going to happily use XML for UI. VB is drag and drop. Put a button here, some label there. Double click here to add an event. Write a tiny bit of code in an editor that has autocomplete and boom.
• 29athrowaway 1y ago
  Many projects have tried this approach over the years (which means it is not a bad idea). XUL from Mozilla, Silverlight and WPF from Microsoft, Glade for GTK and many others. You define the widgets using markup then implement the behavior in some other language. Then came Electron, Tauri and others that piggybacked on HTML and CSS.
• gnramires 1y ago
  I confess I have failed multiple times to build simple web pages (like a blog and homepage, admittedly after not too much effort), while I've made multiple fairly complex javascript animations using canvas and p5.js library. And I've made a few websites as a kid! (I'm not sure using free WYSIWYG or HTML directly). So appreciate a lot new developments in the really-easy-to-use open source and text tools that also enable more involved use case! Admittedly I also have not tried to learn React or other frameworks (most times I got stuck on backend basics). It would be awesome if (almost) anyone could easily type out a website using simple and open source tools (specially with a little more involved functionality than just static content, or more free looks), and it just worked (with minimal coding required for the backend -- that's what's great about plain html imo, it's just a few files that contain your whole website). I mean, meanwhile it's great that something like hosted blogs exist of course.
  • creesch 1y ago
    To be frank, this would likely not help you. A simple web page is effectively simpler XML as the HTML elements that are already there are quite enough. I might be completely off the mark here (edit while writing the comment, considering you mention static HTML I probably am, going to leave the comment anyway for others to see), but considering you seem to think that you need React (or any javascript for that matter) to me seems to hint at a practical knowledge gap about HTML and webpages in general. Which, is more common these days exactly because modern libraries effectively abstract it away to the point where people only see HTML when looking at the DOM representation in the browser devtools. > It would be awesome if (almost) anyone could easily type out a website using simple and open source tools (specially with a little more involved functionality than just static content, or more free looks), It is interesting to me how we effectively regressed here. At least as far as common knowledge goes. You can still go to a basic shared webhosting provider, get a domain, some storage, mysql/mariadb datbase, php and do all of that with relatively little effort. Of course, PHP isn't considered to be relevant anymore which is entirely fair. But it is by far the most straightforward way to get a website going with an actual backend that doesn't require you to do cloud wrangling and all that.
    • 1y ago
• deleted 1y ago
  [deleted]
• getflourish 1y ago
  What makes this different from React (which it is built on)? - Components for data fetching - IDs for bindings Two seemingly simple details that lead to less code.
• gverrilla 1y ago
  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.
  • judell 1y ago
    We hope the landing page conveys that message! https://www.xmlui.org/ https://www.xmlui.org/
• Too 1y ago
  So instead of ’const tubeStations = useDatasource()’ we now type ’<DataSource id=”tubeStations” />’ 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 fingertips is worth everything. Hands up anyone who want to learn how to make a for-loop with filter+map in xml syntax. Didn’t think so. If you want to fix react what you should do instead is keep jsx and give stateful hooks a dedicated section that can’t be mixed up in rendering code.
  • deleted 1y ago
    [deleted]
  • ricardobeat 1y ago
    You're forgetting the state management required to link the components. Here's a take (by Claude) on what it would look like, even if you ignore the entire `useDataSource` implementation it's an entirely different beast: https://gist.github.com/ricardobeat/8aedb9c6d3a1b0bfaba9cc55d9393e48 https://gist.github.com/ricardobeat/8aedb9c6d3a1b0bfaba9cc55...
  • judell 1y ago
    > exercise for the reader The demo app shows a bunch of patterns. https://docs.xmlui.org/tutorial-01 https://docs.xmlui.org/tutorial-01
• lf-non 1y ago
  I understand the motivation for this, but don't understand why this can't just be a collection of web components.
• Timwi 1y ago
  When it started talking about mimicking the experience of Visual Basic, I was excited, because I have fond memories of that (and Borland Delphi after it) and its ability to let me design a window/dialog layout in a WYSIWYG manner, But then it showed XML code (which of course I saw coming, given the title) and I was immediately reminded of WPF with its XAML, which was a nightmare for me. The excitement was instantly replaced with great disappointment :( I'll readily admit that I haven't tried it so I don't know how much like WPF/XAML it'll be, but it's pretty clear it won't be like Visual Basic or Delphi.
• atbpaca 1y ago
  To develop an app, today, one needs to know 3 programming languages: HTML + Javascript + CSS. XMLUI would downsize this requirement to 2, so a little better IMHO.
• cik 1y ago
  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 platforms (Windows, at the time was problematic). Using this approach (pre QT designer working this way), we were able to give the UX team the ability to move widget around in the installer, colour things, add images.. it actually worked incredibly well, to everyone's shock. I still remember the nightmare of dynamic signal and slot lookups.
  • g8oz 1y ago
    Was NSIS too limited for your use case?
• childintime 1y ago
  Related: Flutter based fml.dev. Example: <FML version="1.0" title="Counter-Page"> <HEADER height="46" color="blue"> <CENTER> <TEXT value="FML Demo Home Page" size="20" color="white"/> </CENTER> </HEADER> <CENTER> <COL center="true"> <TEXT value="You have pushed the button this many times:" color="#7c7c7c"/> <TEXT id="clicknumber" value="0" style="h3" color="#7c7c7c"/> </COL> </CENTER> <POS bottom="10" right="10"> <BTN onclick="clicknumber.set({clicknumber} + 1);" width="40" height="40" radius="50" color="blue" type="elevated"> <ICON icon="add" color="white"/> </BTN> </POS> </FML>
• jdthedisciple 1y ago
  so basically Windows Presentation Foundation (WPF) ... ?