Live data from Hacker News

XMLUI

blog.jonudell.net

301–310 of 345 posts

Re: XMLUI

#301
post #288

Earlier quoted context omitted.

AFAIK Mozilla still uses XUL to draw their browser UI.

It’s a mixture of XUL and HTML nowadays. The reason is, most of the things that were only available in XUL are now possible in HTML, and it’s eaaier to find developers who know HTML.

> and it’s eaaier to find developers who know HTML

Rather: find developers who have a shallow knowledge of HTML.

I do claim that it takes much less time as a developer to get to a decent level of XUL knowledge than to get to a decent devel of HTML knowledge.

Re: XMLUI

#302

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. Somethin…

> 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/

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).

Re: XMLUI

#303

XUL! why not just use htmx and the platform?

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.

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/

Re: XMLUI

#304

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 d…

React itself was class based in the beginning, and that would have probably been a better model in the long run - it was a lot more code for sure, but less complexity.

Re: XMLUI

#306
post #275

So instead of ’const tubeStations = useDatasource()’ we now type ’ ’ and anything beyond this basic example is left as exercise for the reader. Doesn’t seem like a big improvement? In fact the opposite. Sure, React’s stateful hooks mixing in a semi-declarative mode of programming in otherwise imperative code isn’t exactly intuitive, but the flexibility and familiarity you get from having full JavaScript at your finge…

[deleted]

Re: XMLUI

#307
post #172

Earlier quoted context omitted.

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.

What is that gets reinvented in Postgres sorry I can’t get it? Can u please care to explain?

Not in PG but in its ecosystem. Just look at any "awesome PostgreSQL" listings, like:

  https://github.com/pg-tr/awesome-postgres
  https://github.com/dhamaniasad/awesome-postgres

Re: XMLUI

#308
post #275

So instead of ’const tubeStations = useDatasource()’ we now type ’ ’ and anything beyond this basic example is left as exercise for the reader. Doesn’t seem like a big improvement? In fact the opposite. Sure, React’s stateful hooks mixing in a semi-declarative mode of programming in otherwise imperative code isn’t exactly intuitive, but the flexibility and familiarity you get from having full JavaScript at your finge…

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/8aedb9c6d3a1b0bfaba9cc55...

Re: XMLUI

#309
post #250

Earlier quoted context omitted.

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.

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 au…

I think Angular "won" a lot of users because it confused a lot of people by calling its templates .html files that designers could work in them without needing to know how to program. Then once they were in those HTML files they were trapped by all the nonstandard attributes. It was a fascinating bait-and-switch to watch middle management get trapped in, I saw it play out a couple times in slightly different but ultimately the same way.

With React those sorts of "I'm only comfortable with HTML" (or "I'm only comfortable with Figma but it gives me HTML") designers often know that they don't like JS and don't want to work in JSX files directly. If middle managers are looking for "efficiency and synergy" the "my designers won't work directly in React" problem looks a lot like a "let's use Angular for everything because I'm told it is 'just' HTML" solution, with the trap being set that Angular's template language is complex and confusing and still a template language despite being in files labeled .html. Then once trapped the sunk cost fallacy strikes hard because "everyone already knows Angular" (despite no one actually "knowing" Angular, they know HTML and fight the template language to get something that sort of works some of the time).

At least Vue tends to prefer .vue for its single-file components. It's not directly the same bait-and-switch.

Re: XMLUI

#310

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 e…

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.

It is implemented using React.

> XMLUI wraps React and CSS and provides a suite of components that you compose with XML markup.

Post reply on HN