undefined | Better HN

0 pointssam_lowry_9mo ago0 comments

Keys were a thing in XSLT 1.x already.

XSLT 2+ was more about side effects.

I never really grokked later XSLT and XPath standards though.

XSLT 1.0 had a steep learning curve, but it was elegant in a way poetry is elegant because of extra restrictions imposed on it compared to prose. You really had to stretch your mind to do useful stuff with it. Anyone remembers Muenchian grouping? It was gorgeous.

Newer standards lost elegance and kept the ugly syntax.

No wonder they lost mindshare.

0 comments

jerf9mo ago

"Newer standards lost elegance and kept the ugly syntax."

My biggest problem with XSLT is that I've never encountered a problem that I wouldn't rather solve with an XPath library and literally any other general purpose programming language.

When XSLT was the only thing with XPath you could rely on, maybe it had an edge, but once everyone has an XPath library what's left is a very quirky and restrictive language that I really don't like. And I speak Haskell, so the critic reaching for the reply button can take a pass on the "Oh you must not like functional programming" routine... no, Haskell is included in that set of "literally any other general purpose programming language" above.

yoz9mo ago

Serious question: would it be worth the effort to treat XSLT as a compilation target for a friendlier language, either extant or new?

There's clearly value in XSLT's near-universal support as a web-native system. It provides templating out of the box without invoking JavaScript, and there's demand for that[1]. But it still lacks decent in-browser debugging which JS has in spades.

[1] https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...

bokchoi9mo ago

I just posted this in another comment: https://github.com/Juniper/libslax/wiki/Intro

1 more reply

jerf9mo ago

It would at least be an interesting project. If someone put the elbow grease into it it is distinctly possible that an XSLT stylesheet could be not just converted to JS (which is obviously true and just a matter of effort), but converted to something that is at least on the edge of human usable and editable, and some light refactoring away from being decent code.

smrtinsert9mo ago

Pretty true. I created a simplified XPath layer to a stax parser back in the day and it was a break through in xml usability.

bokchoi9mo ago

I haven't tried it yet, but I came across this alternate syntax for XSLT which is much more friendly:

https://github.com/Juniper/libslax/wiki/Intro

It looks like it was developed by Juniper and has shipped in their routers?

j / k navigate · click thread line to collapse

0 pointssam_lowry_9mo ago0 comments

Keys were a thing in XSLT 1.x already.

XSLT 2+ was more about side effects.

I never really grokked later XSLT and XPath standards though.

Newer standards lost elegance and kept the ugly syntax.

No wonder they lost mindshare.

0 comments

jerf9mo ago

"Newer standards lost elegance and kept the ugly syntax."

My biggest problem with XSLT is that I've never encountered a problem that I wouldn't rather solve with an XPath library and literally any other general purpose programming language.

yoz9mo ago

Serious question: would it be worth the effort to treat XSLT as a compilation target for a friendlier language, either extant or new?

[1] https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...

bokchoi9mo ago

I just posted this in another comment: https://github.com/Juniper/libslax/wiki/Intro

1 more reply

jerf9mo ago

smrtinsert9mo ago

Pretty true. I created a simplified XPath layer to a stax parser back in the day and it was a break through in xml usability.

bokchoi9mo ago

I haven't tried it yet, but I came across this alternate syntax for XSLT which is much more friendly:

https://github.com/Juniper/libslax/wiki/Intro

It looks like it was developed by Juniper and has shipped in their routers?

j / k navigate · click thread line to collapse