[HN Gopher] XMLUI
___________________________________________________________________
XMLUI
Author : mpweiher
Score : 395 points
Date : 2025-07-20 14:03 UTC (8 hours ago)
(HTM) web link (blog.jonudell.net)
(TXT) w3m dump (blog.jonudell.net)
| mattlondon wrote:
| XML?
|
| Why not web components?
| skrebbel wrote:
| Focus, I'd assume.
| cheschire wrote:
| 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
| danielvaughn wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| willseth wrote:
| 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.
| sheepscreek wrote:
| 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 wrote:
| 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 wrote:
| if the target audience is 'citizen developer', aka Visual Basic
| (classic), I am not sure introducing XSLT is such a good idea.
| majewsky wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Not sure what you mean by licensing failure or "one liner".
| Browsers are natively limited to XSLT 1.0 not because of
| licensing, but because they simply didn't want to implement
| the newer versions. However Saxon offers free XSLT 3.0
| processors for JS, C, Java, and .NET, so there's not really
| a limitation to doing modern XSLT development.
| Quarrelsome wrote:
| Licensing is just another aspect of friction,
| contributing to everyone sticking on 1.0 and making it
| annoying for anyone trying to move forward with XSLT. One
| liner is a lack of procedural logic in its
| implementation. Its fine for 1-1 mapping but as it gets
| used in more complicated scenarios it can be hard to
| developers to architect a solution because there's no
| space to breathe.
| leptons wrote:
| >No mention of XSLT?
|
| Nope, but they sure had to make 1/2 the content about "AI"
| (otherwise nobody would read it?).
| HellsMaddy wrote:
| My first exposure to XSLT was sketchers.com:
| https://thedailywtf.com/articles/Sketchy-Skecherscom
|
| Sadly it doesn't seem like they're using it anymore.
| judell wrote:
| 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 wrote:
| 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.
| rand0m4r wrote:
| it reminded me of Adobe Flex (probably without its "bad" parts) -
| nice work, congrats to the developers.
| ryandv wrote:
| See also XAML:
| https://en.wikipedia.org/wiki/Extensible_Application_Markup_...
| vjvjvjvjghv wrote:
| XAML is an example for how not to do it.
| dlachausse wrote:
| OpenLaszlo was even more similar to this...
|
| https://en.m.wikipedia.org/wiki/OpenLaszlo
| yoz-y wrote:
| 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 wrote:
| 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 wrote:
| Spreadsheet is a form of programming, so you can build
| anything there.
| kibibu wrote:
| Not a common opinion, but one I happen to share.
| layer8 wrote:
| Spreadsheets traditionally don't support iteration (loops)
| or recursion. In Excel you had to go the VBA route for
| actual programming.
| airstrike wrote:
| In my hands they do
| johnisgood wrote:
| That is the spirit.
| accrual wrote:
| In the distant future: $ ./myapp.xlsx
| --port 8080 My App listening on port 8080
| Loaded 1337 rows
| mryall wrote:
| The future is now with Microsoft Excel Web Services,
| which is part of SharePoint.
|
| https://learn.microsoft.com/en-us/sharepoint/dev/general-
| dev...
| aruggirello wrote:
| In other hands, I have seen Excel spreadsheet hundred-
| products pricelists become a freaking tangle of merged
| cells, multiple rows for products, spelling mistakes,
| multiple spaces everywhere, and price cells hand-
| formatted. And I had to export the contents to machine
| readable .csv...
| cluckindan wrote:
| Let's see an HTTP server in an Excel sheet.
| airstrike wrote:
| 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
| shortstuffsushi wrote:
| Maybe just me but seeing side by side "spreadsheets are
| all you need" and ".ai" seem to be somewhat uh...
| competing claims.
| airstrike wrote:
| It's a play on "Attention is all you need", the seminal
| AI paper.
|
| The author of that website implemented GPT-2 inference on
| Excel
| oblio wrote:
| Fairly sure Excel can get access to the entire .NET
| runtime.
|
| Plus, someone made a MOV only compiler, soon...
| homarp wrote:
| https://learn.microsoft.com/en-us/office/client-
| developer/ex...
|
| Calling user-defined functions (UDFs) from a worksheet is
| as simple as calling built-in functions: You enter the
| function via a cell formula.
| Someone wrote:
| I didn't check their claim, but
| https://github.com/michaelneu/webxcel:
|
| _"Webxcel creates a full-fledged RESTful web backend
| from your Microsoft Excel workbooks. It is written in
| 100% plain Visual Basic macros and comes with a lot of
| handy tools to help you build the next big thing."_
| cluckindan wrote:
| Ha! Sure beats the pure bash HTTP server. ;-)
| djha-skin wrote:
| In 2010 I was working for a student computer support shop. We
| had web developers building our own ticketing system. In
| those days, I was told that everything in the UI was just
| tables. It was the only way they could get enough control on
| UI elements before div tags became widely spread.
| rzzzt wrote:
| Also 1x1 pixel spacer GIFs.
| aruggirello wrote:
| IE6 forced us to do crazy stupid stuff, like
| <div> </div> - and don't even start talking about
| <!-- ie "preprocessor like directives" -->
| accrual wrote:
| I still love using tables in 2025 for webapps designed to
| run on old browsers. It's easy to render data into them
| (it's just headers, rows, columns) and they automatically
| have a cool, functional look (IMO).
| im3w1l wrote:
| Html tables are very different from excel tables.
| Fundamentally html tables were used because rows are a good
| way to split up the page vertically (you could have one row
| for the header, one for the content one for the footer).
| And columns are good for splitting it up horizontally (you
| could have one column for the side panel, and one for the
| content, and the last one for an obnoxious blinking ad).
| toolslive wrote:
| IIRC, for a long time in the late 90s, Fedex was glued
| together with spreadsheets.
| nosioptar wrote:
| I took a graphics programming class where one dude did a
| bunch 3d rendering stuff in excel.
|
| Rather than try to understand, I decided he was into
| witchcraft.
| yoz-y wrote:
| If we somehow manage to solve the two main spreadsheet
| downsides (imo): testing and change/version control, then
| spreadsheets would be a terrific programming paradigm.
|
| As it is now I find it very powerful and empowering, but also
| scary.
| efitz wrote:
| 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.
| djha-skin wrote:
| I don't agree. Rather than breaking down, abstractions in UI
| have stabilized and centralized. Everyone uses React.
| majewsky wrote:
| React is not an abstraction, it's a framework. The core
| abstraction is "a component takes data only from its
| parent, and only passes data back up through provided
| callbacks". The exact spot where this abstraction breaks
| down is whenever you need to use a hook.
| altairprime wrote:
| Eventually; but having something less complex than a general-
| purpose programming language to build prototypes and v1.0
| products to test business-purpose fit is really important, too.
| Lets users have ideas and build them and try them out without
| having to engage a programmer. Hella valuable for workflow-
| process design, too. Best to have that one programmer on tap
| who can fix problems and recognize when it's too unwieldy, of
| course.
| WillAdams wrote:
| Impressive that they note:
|
| https://docs.xmlui.com/
|
| >This site is an XMLUI(tm) 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?).
| binarymax wrote:
| It's painfully slow (on a newish mobile). While the concept is
| great for dynamic data, static docs are a terrible use case.
| Animux wrote:
| XMLUI reminds me of XUL (XML User Interface Language)
| vibbix wrote:
| 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). XML UI's are fairly underrated imo.
| LudwigNagasena wrote:
| So it's like JSX but with implicit imports and stringly-typed
| props?
| danielvaughn wrote:
| 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 wrote:
| While flexbox is more powerful, those semantics would require
| prior knowledge of other CSS attributes and to develop an
| intuitive understanding of them.
| sheepscreek wrote:
| 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.
|
| 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 wrote:
| We would love to know how that goes.
| eviks wrote:
| > 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 wrote:
| how do u like jsx then?
| llbbdd wrote:
| JSX has all the tooling available.
| derelicta wrote:
| 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 wrote:
| 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 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 ).
| junon wrote:
| 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 wrote:
| 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 wrote:
| 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/iu...
| BrenBarn wrote:
| 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.
| eyelidlessness wrote:
| 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 impressive feat. Not necessarily in terms its
| technical capabilities (though that seems impressive too), but
| in terms of how it simplifies modeling interactive and data-
| driven UI.
| j1elo wrote:
| Speaking of expressing a UI declaratively, and composition
| with web components... as a former Qt/QML dev, I always felt
| like Web innovations of the last decade are just rehashes of
| the inspirations and ideas behind what Qt's QML started
| offering already since 2010.
|
| Things like CSS Grid, which was a great and celebrated new
| toy in 2017, but as foreigner from the Web world, I still
| remember how I read those news and didn't know if they were
| kidding.
|
| To the standards body that may concern: just copy QML and
| standardize it already! :-)
| DonHopkins wrote:
| XULRunner's initial release was in 2006.
|
| OpenLaszlo was released in 2001.
|
| Garnet was released in the early 90's.
|
| Ivan Sutherland's Sketchpad (aka Robot Draftsman) was
| created in 1963, and inspired the Visual Geometry Project
| in the mid 1980's and The Geometer's Sketchpad in 1995
|
| https://news.ycombinator.com/item?id=44627569
|
| https://en.wikipedia.org/wiki/XULRunner
|
| https://en.wikipedia.org/wiki/OpenLaszlo
|
| https://en.wikipedia.org/wiki/The_Geometer%27s_Sketchpad
|
| https://en.wikipedia.org/wiki/Sketchpad
| JodieBenitez wrote:
| Laszlo... I remember this one, dipped my toes in it, like
| many, many other GUI tools. I've been using the same
| backend framework for 20 years with no need to change but
| I can't decide which frontend GUI library I should invest
| my time for the future. It all looks like constant
| rehashing of the same ideas but with limited lifespan.
| cyberax wrote:
| There was also HTMLayout released around 2003.
| gmueckl wrote:
| QML copies many core ideas from JavaFX (released 2008) and
| Microsoft's WPF (released 2006).
|
| Microsoft's XAML for declarative UIs is the most
| reused/reimplemted approach among this bunch. Its variants
| are in WPF, Silverlight, WinUI, Avalon and Uno.
| judell wrote:
| 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.
| cryptonector wrote:
| What we've been seeing for a while is that the rate of wheel
| reinvention has skyrocketed. Just look at the PostgreSQL
| ecosystem and you'll see many libraries for each feature you
| might be interested in.
| larodi wrote:
| What is that gets reinvented in Postgres sorry I can't get
| it? Can u please care to explain?
| refulgentis wrote:
| I'm curious, not talking down: would you be interested in
| sharing your age and/or years of experience coding, and if
| you're feeling very generous, the languages youve written
| code in for more than 2+ years?
|
| I'm 37, 17 years full-time-ish, VB6, ObjC, Java, Dart.
|
| I'm asking, I guess, because I feel like I've seen these
| concepts before in pre-iOS ObjC, and Java, and IIRC a good
| chunk of the late 90s and early 00s was obsessed with doing
| this stuff in XML.
|
| I barely remember, in my hobbled, probably incorrect,
| perception the ideas are old enough to that I am a bit
| flummoxed at how to interlocute with the idea that they're
| novel breakthroughs.
|
| I'm ashamed to admit I thought the page was parodying this
| concept from back then of anything + XML = awesome. Im
| admitting it to give a concrete sense of how my subconscious
| processed this as settled territory.
| deanebarker wrote:
| I thought of XUL right away too.
| rossant wrote:
| Reminds me of XAML and WPF.
| david927 wrote:
| 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.
| gmueckl wrote:
| I am not sure whether calling WPF a huge failure is
| justified. It works extremely well when everything is
| adaptable to its MVC-adjcent MVVM design pattern. In this
| case it's almost child's play to build rich and conplex
| GUIs that keep in sync with internal state.
|
| Microsoft dropped the ball when they rewrote WPF in
| incompatible forms for the web (Silverlight) and Windows
| Phone (WinUI) shortly after releasing WPF itself. That
| ruined developer trust for their GUI library longevity.
| mikeschinkel wrote:
| I ran a very successful company (successful for a time)
| that sold Visual Basic developer tools via a printed mail-
| order catalog named VBxtras.
|
| Two things killed Visual Basic:
|
| 1. The web. Visual Basic was first and foremost a Windows
| desktop app development tool, and their UI-first model of
| app development did not translate well to the web, or at
| least the attempts to translate to the web did not
| resonate.
|
| 2. Microsoft. Rather than continue the simplicity Visual
| Basic offered, Microsoft "improved" it by releasing VB.NET
| which abandoned the core simplicity that made Visual Basic
| so wildly popular among "Occupational Programmers," as
| Kathleen Dollard[1] and I lamented back in the day. The
| upshot was that former Visual Basic programmers fell into
| two (2) camps; they either:
|
| A.) Abandoned VB for something else, or nothing at all,
| because they did not want to have to become a professional
| programmer, OR
|
| B.) Switched to C# because if they were going to learn how
| to be a "real" programmer they might as learn C# and not
| C#'s disfavored sibling VB.NET.
|
| I blogged about occupational programmers several times back
| then:
| https://mikeschinkel.com/tags/occupationalprogrammers/
|
| BTW, the company that has developed XMLUI was one of our
| better vendors of VBX components for Visual Basic. They
| have since renamed to /n software, but at first they were
| named IP*Works (I think I stylized that name correctly per
| how they did at the time.)
|
| [1] Ironically Kathleen is now leads the .NET Core CLI at
| Microsoft, and is also lead over VB, I think:
| https://devblogs.microsoft.com/dotnet/author/kathleen-a-
| doll...)
| jefftk wrote:
| XHTML was not a previous version of HTML; it was a failed
| successor.
|
| HTML was originally conceived as a subset of SGML, but browsers
| tried to be as forgiving as possible of malformed markup and
| HTML-in-practice drove standards folks nuts. XHTML was intended
| to fix this by making a pure-XML representation of HTML, which
| would be unambiguous and fast to parse, but its very strict
| error handling made it extremely difficult to adopt. It turns
| out people would generally rather have a slightly wrong page
| than one that just said "XML Parsing Error".
|
| WHATWG broke with W3C in 2005 to standardize HTML-in-practice
| into HTML5, giving up on XML compatibility and strict parsing.
| robin_reala wrote:
| It's not failed: it's the only language used in the ePub
| standard. Though this might change with ePub 3.3 which is
| considering adding HTML support.
| jefftk wrote:
| Its design goal was to supplant HTML as the language of the
| web, and regularize communication between browsers and
| servers. At this it has failed.
| dragonwriter wrote:
| > It's not failed: it's the only language used in the ePub
| standard.
|
| "XHTML" can refer to both a failed series of standards
| intended to replace HTML (XHTML 1.0, XHMTL 1.1, and XHMTL
| 2.0) and the XML syntax of HTML that is part of the HTML
| living standard, which itself resulted from the failure of
| the XHMTL series of standards. EPUB 3's "XHTML" is the
| latter, not the former.
| rwmj wrote:
| I remember trying to write a cross-platform interface for some
| software in XUL, around 2003. I even bought two (physical!)
| books on the subject. It was totally impossible! The libraries
| were ever-changing and you needed the entire Mozilla CVS tree
| checked out to compile anything and just getting that to
| compile was endless complexity. I gave up and used an early
| port of Gtk to Windows.
|
| Such a "could have been great" technology if it wasn't for
| Mozilla ...
| ttul wrote:
| I spent an unhealthy number of hours working in XUL in
| 2000-2001 working on the Komodo editor, which, bizarrely, used
| Firefox as its GUI platform. XUL was neat, but oh god so
| complicated. XML was the new hotness around the peak of the
| DotCOM era and Mozilla's use of XML for a GUI framework fit the
| zeitgeist.
| art0rz wrote:
| Komodo was my favorite editor. There weren't many editors at
| that point in time that had great Perl support.
| hdjrudni wrote:
| Don't forget XSLT. Worked directly in the browser. I only found
| out because the battle.net StarCraft page was made using it and
| I just happened to find it while poking around.
| righthand wrote:
| 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 wrote:
| 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 wrote:
| I read that as Haskell and I definitely think HaskellUI would
| solve all problems. /j
| zigzag312 wrote:
| > 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 wrote:
| reminds me of Macromedia MXML (used in Flash, Coldfusion and
| Flex)!
|
| https://github.com/apache/royale-asjs/blob/develop/examples/...
| DonHopkins wrote:
| 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://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
|
| 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_...
|
| 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
|
| 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://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
|
| http://www.cs.cmu.edu/afs/cs/project/garnet/www/garnet-home....
|
| https://en.wikipedia.org/wiki/Sketchpad
|
| http://math.coe.uga.edu/TME/Issues/v10n2/4scher.pdf
|
| 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...
|
| >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.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
| thrownaway561 wrote:
| I was thinking the same thing. Programmed ColdFusion for over a
| decade and loved the language, however I moved onto .NET, the
| PHP and now Rails. ColdFusion was a wonderful language, but the
| frameworks weren't there and the market share wasn't there
| either. Ironically enough, one of my clients still uses it for
| their application and we actually began talks about moving them
| over to Rails.
| guestbest wrote:
| Reminds me of renaissance for openstep.
|
| https://github.com/gnustep/libs-renaissance
| lukev wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mikestew wrote:
| _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
| toyg wrote:
| Let's be honest, XUL was a pain for a number of mozilla-
| specific choices (rdf...). A lighter, better XUL would be
| absolutely fine.
| api wrote:
| 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 wrote:
| Great point!
| thom wrote:
| 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 wrote:
| 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 wrote:
| "Since 1995 nearly all of my professional work has been enabled
| by, and published on, the web." https://jonudell.net
| greatgib wrote:
| 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 wrote:
| 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.
| fghorow wrote:
| Ummm, errr. Jon Udell[1] was a columnist for Byte (RIP)
| magazine. He has been around a looooooong time.
|
| [1] https://en.wikipedia.org/wiki/Jon_Udell
| tbeseda wrote:
| 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
| efitz wrote:
| This seems like a neat idea that is 20 years too late.
| fxtentacle wrote:
| 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 wrote:
| 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 wrote:
| 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?"
| MomsAVoxell wrote:
| 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 ..
| b_e_n_t_o_n wrote:
| I've never used JUCE before but I agree that the imperative
| approach, while often larger in implementation, is usually very
| explicit about what is happening and allows full control.
| Declarative approaches always need escape hatches, and those
| escape hatches are usually tricky to open and pass through.
| cxr wrote:
| > 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'etre 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.P 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.P 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>
| DonHopkins wrote:
| 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.ycombinator.com/item?id=19745034
|
| >DonHopkins on April 25, 2019 | parent | context | favorite |
| on: Immediate Mode GUI
|
| >Immediate mode GUI's don't let you apply useful object
| oriented programming techniques like subclassing and prefabs
| (persistence) to implement and configure custom components.
|
| >Properly object oriented retained mode GUIs let you subclass
| components to implement custom views and event handling, and
| develop and publish reusable prefabs and libraries of pre-
| configured, stylized, specialized component. [...]
|
| >I don't know what you mean about easily composing immediate
| mode API's, or agree that different immediate mode APIs don't
| need to know about each other. They depend on a lot of behind-
| the-scenes implicit hidden state (practically a hidden shadow-
| DOM-like retained mode), so I suspect in many cases they'd walk
| all over each other (especially text editors dealing with input
| focus and keyboard navigation). Unity3D has two immediate mode
| APIs, one for the editor and one for runtime, and they sure
| don't mix. [...]
|
| >How would you write a functional extension for Unity3D's old
| immediate mode GUI that let you embed an ACE code editor in a
| Unity WebGL app? What would the API and state management even
| look like? How could you make it platform independent?
|
| >And even if you solved all of those problems with an immediate
| mode API, by its very nature it still wouldn't enable you to
| build GUIs in the interface editor or store them in prefabs,
| and you'd still have to recompile you app (which can take half
| an hour with Unity) every time you wanted to tweak the user
| interface (which is why I like programming Unity apps in
| JavaScript as much as possible). [...]
|
| >Embedding object oriented "retained mode" widgets with
| different APIs inside of each other is old hat and common for
| backwards compatibility. Whenever you write a new GUI toolkit,
| embedding widgets from the last toolkit is one of the first
| things you do (including recursively embedding widgets from the
| toolkit-before-last).
|
| >Concrete example: Microsoft lets you embed old fashioned OLE
| controls in Windows Forms / Presentation Foundation
| applications, which might be implemented in MFC themselves. And
| MFC is all about embedding old Win32 widgets implemented in C,
| and newer OLE components implemented in Visual Basic or
| whatever, in venerable C++ MFC user interfaces. Say what you
| want about how much Win32/MFC/OLE/WF/WPF sucks, and I'll
| wholeheartedly agree, but if you're running Windows, you
| probably have widgets on your screen using several different
| retained mode APIs embedded more than two levels deep right
| now. [...]
|
| >The problem with immediate mode that is you have to come up
| with somewhere to store and retrieve any values or state
| required on a case-by-case basis (including the edited value
| itself, and other view state like scrollbar state for text
| editors, etc), and that tightly couples your component function
| with whatever's using it, so they're not very reusable or
| simple. With OOP, the object has its own place to store that
| stuff, which is cleanly decoupled from whatever's using the
| component.
|
| >Then there's the issue of event handlers. Some user interface
| components just aren't so simple that they only have one
| true/false return value like buttons. Text editors can notify
| on value change, end edit, select, deselect, etc. And Unity's
| retained mode GUI supports persistent event handlers that let
| designers hook up events with methods of objects with
| parameters, without writing or recompiling any code.
|
| >And there's also a lot more to layout that you can easily
| express with an immediate mode GUI. Sometimes you have to
| measure a bunch of things and align them in various ways, like
| grids or flex layouts, and adapt to the screen size and other
| constraints (i.e. responsive design), and that's really hard to
| do with immediate mode, while retain mode has a rich set of
| layout components you can use and extend. And there's nothing
| like XCode's layout constraints for immediate mode. [...]
|
| >A perfect example is TextMesh Pro's text editor. It has so
| many different (and useful) features and parameters and
| callbacks and ways to configure it, and it keeps so much state
| in order to redisplay efficiently with the fewest number of
| draw calls and reformatting, that it would be extremely
| impractical and inefficient and unwieldy for it to use an
| immediate mode API. Especially with C# positional arguments
| instead of Pythonic or Lisp-like optional unordered keyword
| arguments.
|
| >When you encapsulate your immediate mode layout in a class, or
| write an engine that interprets (i.e. JSON) data to drive the
| immediate mode API, or use reflection in your wrapper functions
| to dispatch event callbacks and bind your widget data to your
| model data, you're just rolling your own informally-specified,
| bug-ridden, slow implementation of half of retained mode. (See
| Greenspun's tenth rule.)
| CamperBob2 wrote:
| 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.
| DrStartup wrote:
| XUL! why not just use htmx and the platform?
| cluckindan wrote:
| 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.
| general1726 wrote:
| 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 wrote:
| Maybe I just didn't understand it but to me WPF felt like it
| was designed by an insane person.
| franze wrote:
| Those who do not understand (or remember) XUL are forced to
| reinvent it.
|
| see https://www-archive.mozilla.org/xpfe/xui.html
| cbsmith wrote:
| Pretty sure Jon Udell remembers XUL.
| judell wrote:
| I do indeed.
| CharlesW wrote:
| 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.
| djha-skin wrote:
| 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/
|
| 2: https://polymer-library.polymer-
| project.org/1.0/docs/about_1...
| mattmcknight wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Hah, that is awesome. How does Qt fare these days in the non-
| Linux world though?
| hermitcrab wrote:
| 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 wrote:
| 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).
| mentos wrote:
| I believe the Blizzard game launcher uses QT?
|
| Blizzard to me has always had the best execution of UI in their
| software/games.
|
| Curious if there are any Qt projects you'd single out as being
| great?
| mnafees wrote:
| I didn't know Blizzard uses Qt! In terms of some good Qt
| apps, VirtualBox remains my favorite.
| n3storm wrote:
| And wxwidgets and glade files...
| zkxjzmswkwl wrote:
| So Winforms for React.
| doug_durham wrote:
| The ergonomics makes my eyes bleed. I think we can do better.
| tomsonj wrote:
| android layout xml is great, glad to see more broad attempts
| cubefox wrote:
| Unfortunately this doesn't provide a comparison to similar
| solutions, like XUL or htmx.
| zamalek wrote:
| 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.
| theknarf wrote:
| So you built a worse alternative to React, on top of React?
| stillpointlab wrote:
| 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
|
| 2. https://apache.github.io/royale-docs/features/mxml
| sirjaz wrote:
| This reminds me of xaml with css thrown in. It is almost like
| this validates Microsoft's blazor plans with C#
| Neywiny wrote:
| 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.
| mrweasel wrote:
| 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 wrote:
| 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 wrote:
| > 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/
| hn8726 wrote:
| > 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
| mike_hearn wrote:
| That's just Android though. A good example of doing this
| well is JavaFX with Scene Builder. The XML corresponds to
| the UI tree 1:1 and the designer makes XML that looks hand
| written (or vice-versa). FXML is also a pretty intuitive
| schema and there's a dialect of CSS intended for UI that I
| find more intuitive than web CSS.
| pdntspa wrote:
| Lazarus is pretty much an exact implementation of Visual
| Basic, just mapped to FreePascal instead of VB
| homarp wrote:
| an exact implementation of Delphi, I would say.
| gmueckl wrote:
| Lazarus is a very faithful clone of Delphi, which is the
| Pascal-based main competitor of VB of the time.
| optymizer wrote:
| > but the experience was pretty good.
|
| Our experiences do not match. I used Borland Delphi to build
| business apps 20 years ago just using the UI builder. I've
| been using Android Studio to build apps at FAANGs for 10
| years now and I cannot remember the last time the Design tab
| was useful - it was always faster and more reliable to just
| edit the XML file.
|
| Yes, Delphi didn't do resizing windows and crashed half the
| time, but I was pretty happy with the WYSIWYG / UI building
| functionality for production apps.
|
| Android Studio's UI builder is nowhere near that level of
| usefulness. I have a hard time believing anyone is using the
| UI builder in Android Studio for anything other than
| tutorials or entry level Android apps. It doesn't render the
| layout properly 90% of the time, or just renders some
| placeholders with no content and calls it a day.
|
| For a modern IDE, Android Studio is somewhere between just OK
| and bad, mostly because it has features the other IDEs didn't
| at the time, but the dev experience is behind Turbo Pascal in
| the 90s on MS DOS. The editor is laggy. The debugger is slow
| and hangs often. The list goes on, but I'll stop the rant
| here.
| edoceo wrote:
| VB didn't create those terrible programs, I did.
| rao-v wrote:
| 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 wrote:
| 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 wrote:
| 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 you can create a true domain-
| specific markup language, which will always be more clean and
| compact than a generic one.
| cgannett wrote:
| 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 wrote:
| 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 wrote:
| 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."
| cluckindan wrote:
| 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 wrote:
| Just ship https://github.com/NeilFraser/JS-Interpreter and
| you're good to go! /s
| btown wrote:
| As a follow-up: Angular actually did this!
| https://docs.angularjs.org/guide/expression
|
| > AngularJS does not use JavaScript's eval() to evaluate
| expressions. Instead AngularJS's $parse service processes
| these expressions.
| lstroud wrote:
| 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.
| ta8645 wrote:
| Direct links to their web landing page, and Github code:
|
| https://xmlui.com
|
| https://github.com/xmlui-org/xmlui
| fzaninotto wrote:
| 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 [2]:
| https://github.com/refinedev/refine
| citizenkeen wrote:
| Is this supposed to be unreadable raw code or is the site
| overloaded?
| hoistbypetard wrote:
| When I click the link, I just get a bunch of JSON...
|
| https://pasteboard.co/Rpp35synt4CW.png
|
| Am I missing a joke, or has something broken?
| pdntspa wrote:
| Yet another implementation of data binding
| max-privatevoid wrote:
| Surely this has to be a joke. If I wanted to write web stuff in
| XML, I would just write HTML.
| bjoli wrote:
| I will be that guy: HTML is not XML. People wanted to write
| malformed html so xhtml never went anywhere.
| lutusp wrote:
| 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."
| tacker2000 wrote:
| 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/
| boomskats wrote:
| 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-r...
| wiso wrote:
| Looks like XAML
| https://en.wikipedia.org/wiki/Extensible_Application_Markup_...
| spankalee wrote:
| 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/
|
| 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 wrote:
| 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 wrote:
| Your idea sounds interesting but your site is unreadable on
| mobile (Android+Firefox).
| bloqs wrote:
| 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 wrote:
| I think this could catch on, very much like C++ caught on. It's
| very powerful to be backwards compatible.
| _micheee wrote:
| This reminds me of XForms and its fully declarative approach. It
| allowed you to add interactivity to your HTML without writing
| code.
| nzoschke wrote:
| 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.
| Gluber wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| dharmatech wrote:
| Alan Kay in 1997:
|
| > I really would like you to contrast that with what you have
| to do with HTML on the Internet. Think about it. HTML on the
| Internet has gone back to the dark ages because it presupposes
| that there should be a browser that should understand its
| formats. This has to be one of the worst ideas since MS-DOS.
| [Laughter] This is really a shame. It's maybe what happens when
| physicists decide to play with computers, I'm not sure.
| [Laughter] In fact, we can see what's happend to the Internet
| now, is that it is gradually getting--There are two wars going
| on. There's a set of browser wars which are 100 percent
| irrelevant. They're basically an attempt, either at
| demonstrating a non-understanding of how to build complex
| systems, or an even cruder attempt simply to gather territory.
| I suspect Microsoft is in the latter camp here. You don't need
| a browser, if you followed what this Staff Sergeant in the Air
| Force knew how to do in 1961. You just read it in. It should
| travel with all the things that it needs, and you don't need
| anything more complex than something like X Windows. Hopefully
| better. But basically, you want to be able to distribute all of
| the knowledge of all the things that are there, and in fact,
| the Internet is starting to move in that direction as people
| discover ever more complex HTML formats, ever more intractable.
| This is one of these mistakes that has been recapitulated every
| generation. It's just simply not the way to do it.
| MrJohz wrote:
| And yet in the nearly thirty years since he said that, the
| browser has come to dominate how people interact with UIs.
| Both in terms of sheer popularity (not only do we have
| complex applications on the web, but we also package complex
| applications with browsers as desktop applications) as well
| as influence (SwiftUI, Flutter, and Jetpack Compose all
| borrow heavily from frameworks developed primarily for the
| web).
|
| I think a lot of this has to do with the idea that Kay is
| criticising here: HTML as a mechanism for building
| applications has been so successful because it needs to be
| interpreted by a browser. That provides a tremendous level of
| sandboxing that makes it a lot easier to trust whatever
| website you're loading than the application you're
| installing. It also provides a grab-bag of useful controls
| and elements, while still being completely flexible with
| creating new ones without needing to resort to OOP
| inheritance chains or raw graphics drawing APIs. This is all
| to say nothing of accessibility, which is practically built
| into the browser.
| criticalfault wrote:
| Bye bye ad blocks?
| esprehn wrote:
| This was tried with Polymer way back in 2014 too, ex. making
| network requests with <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
|
| 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.
| wiremine wrote:
| 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 wrote:
| 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 wrote:
| 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?
| optymizer wrote:
| What's old is new again. It's Adobe Flex for the kids. I like it.
| 20after4 wrote:
| This combined with something like Datasette1 would be a really
| nice toolbox for quickly developing simple database applications.
|
| 1. https://datasette.io/
| shireboy wrote:
| 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 wrote:
| https://xkcd.com/927/
___________________________________________________________________
(page generated 2025-07-20 23:00 UTC)