[eviks]

Interesting project. Have you tested any non-XML markup languages for the user interface declaration so that metadata doesn't take as much space as data in

<Text>Hi {firstName} </Text>

and also requiring double the number brackets

There are modern cleaner markup alternatives like kdl

[zackbrown]

We chose an XML-like syntax because it's clear & explicit & established (HTML) — you can know where you are in a hierarchy clearly at any point thanks to closing tags. The major downside is verbosity, both for reading and for typing. Pax's closing tags compile away so they aren't transmitted across the network like they are for HTML.

We predict 95%+ of Pax will be written by machines, especially visual design tools and LLMs, so verbosity becomes less important (LLMs may even benefit from explicit closing tags.) We're innovating on multiple axes, including language, so we chose to make the syntax itself as boring and uninnovative as possible.

[eviks]

But clarify is exactly what's lacking because it's verbose, it obscures content at no benefit to simple matching bracket highlights

Also, will it be read 95% of the time by machines during design? That's not what the demo shows with the side-by-side xml and output, which I expect is a much more common workflow than 5%

The innovating part is what puzzled me and prompted this question - why cling to the old garbage when you're doing new design?

[zackbrown]

Point taken! And yes, especially for developers (our core target demographic,) you are right that hand-writing should account for >5% of code volume.

Syntax is fairly contentious. "One man's trash is another man's treasure," on your note of "old garbage." It's hard to please everyone, however:

We could offer syntax "skins," since the data storage mechanism is a layer separated from the AST (thus different ASTs/syntaxes could de/serialize from the same persisted data.) So folks who want closing tags can have them; folks who want a YAML-like format could have it; folks who want a KDL-like language could have it.

At the language level, Pax's distinguishing characteristic is that it's the union of an expression language and a markup language; this is the reason we couldn't use an off the shelf markup language / parser. But again, KDL or YAML could be extended with PAXEL to make pax-kdl and pax-yaml flavors alongside pax-xml.

We had to start somewhere, and starting as close as possible to the markup lingua franca (HTML) made sense to us. It'd be a dream for Pax to be loved / adopted enough that we or anyone else cares to make a syntax skin.

[eviks]

syntax flavours / "skins" sounds like a great idea if Pax isn't so tightly coupled with the current one

(HTML makes sense as the target to start with, but I'm not sure most people "speak" raw HTML, they'd design apps/pages in other languages)