Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XMLUI

blog.jonudell.net

Post reply on HN
Print view View original

171–180 of 345 posts

Re: XMLUI

#171

Post by jefftk »

robin_reala wrote: post #158
jefftk wrote: post #156

Earlier quoted context omitted.

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

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.

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.

Re: XMLUI

#172

Post by larodi »

cryptonector wrote: post #149
eyelidlessness wrote: post #88

Earlier quoted context omitted.

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

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?

Re: XMLUI

#173

Post by boomskats »

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

Re: XMLUI

#175

Post by spankalee »

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.

Re: XMLUI

#176

Post by btown »

cluckindan wrote: post #107

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.

Just ship https://github.com/NeilFraser/JS-Interpreter and you’re good to go! /s

Re: XMLUI

#177

Post by Quarrelsome »

willseth wrote: post #128
Quarrelsome wrote: post #85

Earlier quoted context omitted.

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

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.

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.

Re: XMLUI

#178

Post by Quarrelsome »

lolive wrote: post #122
Quarrelsome wrote: post #85

Earlier quoted context omitted.

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

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.

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.

Re: XMLUI

#179

Post by dragonwriter »

robin_reala wrote: post #158
jefftk wrote: post #156

Earlier quoted context omitted.

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

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.

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

Re: XMLUI

#180

Post by mnafees »

hermitcrab wrote: post #92
mnafees wrote: post #64

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.

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.

Hah, that is awesome. How does Qt fare these days in the non-Linux world though?
Post reply on HN