Live data from Hacker News

XSLT – Native, zero-config build system for the Web

github.com

321–330 of 337 posts

Re: XSLT – Native, zero-config build system for the Web

#321

I have worked for a company that (probably still is) heavily invested in XSLT for XML templating. It's not good, and they would probably migrate from it if they could. 1. Even though there are newer XSLT standards, XSLT 1.0 is still dominant. It is quite limited and weird compared to the newer standards. 2. Resolving performance problems of XSLT templates is hell. XSLT is a Turing-complete functional-style language,…

XSLT/XPath have evolved since XSLT 1.0. Features are now available like key (index) to greatly speedup the processing. Good XSLT implementation like Saxon definitively helps as well on the perf aspect. When it comes to transform XML to something else, XSLT is quite handy by structuring the logic.

Just to add to this, we know have XXSLT which solves a lot of the original problems with XSLT.

Just to frame this people, imagine a JSON-based programming language for transforming JSON files into other JSON files and the program is also in JSON and turing complete. Now imagine it's not JSON but XML! Now any program can read it! Universal code, magic!

The idea behind XXSLT is now, we actually have a program whose job it is to specify a program. So we have a XML file which specifies a second XML file, which is the program, whose job it is to transform XML to XML. As we all know, layers of abstraction are always good, and common formats such as XML are especially good, so what we have now is the ability to generate a whole family and diverse ontology of programs, all of them XML, all of them by and for XML. Imagine the compiling with your favourite XML-based compilation chain!

Re: XSLT – Native, zero-config build system for the Web

#322

It's sad how the bloat of '00s enterprise XML made the tech seem outdated and drove everyone to 'cleaner' JSON, because things like XSLT and XPath were very mature and solved a lot of the problems we still struggle with in other formats. I'm probably guilty of some of the bad practice: I have fond memories of (ab)using XSLT includes back in the day with PHP stream wrappers to have stuff like ` ` This may be out-of-da…

Xpath would have been nice if you didnt have to pedantically namespace every bit of every query

Can confirm, Working programaticly with XML is not really that bad, there is a well formed query syntax(xpath), the dom api just works.

Until some joker decided to employ xml namespaces, then everything turns ugly real fast. I am not sure I can articulate why it is so unpleasant, something about how everything gets super verbose and api now needs all sorts of extra state.

Re: XSLT – Native, zero-config build system for the Web

#323
post #249

Earlier quoted context omitted.

- Browsers are XSLT (1.0) processors. - Xee: https://github.com/Paligo/xee - xrust: https://docs.rs/xrust/latest/xrust/xslt/ - XJSLT (compiles XSLT to JS): https://github.com/egh/xjslt Xee is WIP AFAIK and I don't know the maturity of xrust and XJSLT.

Yeah... I posted too quickly: I want XSLT 3. The 1 & 2 specs are good first attempts, but are very difficult to use, effectively. As another poster also commented: it'd be nice if the implementation wasn't tied to XML, as well! Also, I want a cookie & a pony.

I guess Xee is the most promising option then :-) But indeed not ready yet.

Re: XSLT – Native, zero-config build system for the Web

#324
post #17

Earlier quoted context omitted.

Was that before/after the LUA adoption?

Before. And after. XSLT controls the styling, Lua the running functions. When Lua adjusts a visible thing, it generates XSLT. "FrameXML" is a thin Lua wrapper around the base XSLT.

WoW...literally and figuratively! Thanks for background. That explains some error messages I got waaaaaay back in the day.

Re: XSLT – Native, zero-config build system for the Web

#325
post #311
post #267

Earlier quoted context omitted.

XSLt is not easy. It’s prologue on shrooms so to speak and it has a steep learning curve. Once mastered gives sudoku level satisfaction, but can hardly ever be a standard approach to built or templating as normally people need much less to achieve goals. Besides XML is not universally loved.

Universal love is one factor, best tool for a job may leave only a few choices including XML. It's not my first choice, but I won't rule it out because I know how relatively flexible and capable it can be. XSLT might just need a higher abstraction level on top of it?

Perhaps it rather needs a facelift and support for JSON. I would imagine one day something regex or jq-level concise emerges, something reasonably short and descriptive, to allow transforming arbitrary tree into another arbitrary tree.

The idea behind XSLT is genial, but the real essence of it is XPath which makes it possible. And we've seen XPath evolve into CSS Selectors, and being useful on its own.

So in essence there are two sides of the transformation:

  - selection - when you designate which parts of the tree match
  - transformation - when building the new three
And while there are established approaches to the first part, perhaps XSLT is the only one which fits the definition of 'generally accepted' when it comes to the transformation.

But one can argue the transformation is possible with jq, it is just that I definitely don't like its overly-engineered syntax. IMHO the champion of the transformation syntax is yet undecided, even though in 2025 XSLT is still more or less king. Which is fascinating as XML is long not a usual choice of preference.

Re: XSLT – Native, zero-config build system for the Web

#326
post #325
post #311

Earlier quoted context omitted.

Universal love is one factor, best tool for a job may leave only a few choices including XML. It's not my first choice, but I won't rule it out because I know how relatively flexible and capable it can be. XSLT might just need a higher abstraction level on top of it?

Perhaps it rather needs a facelift and support for JSON. I would imagine one day something regex or jq-level concise emerges, something reasonably short and descriptive, to allow transforming arbitrary tree into another arbitrary tree. The idea behind XSLT is genial, but the real essence of it is XPath which makes it possible. And we've seen XPath evolve into CSS Selectors, and being useful on its own. So in essence…

If XPath was the core nobody would need xslt, because pretty much every xml library can do XPath.

Don’t get me wrong, XPath is by far the best thing to come out of the xml ecosystem, but the actual idea at the core of xslt is the match/patch during traversal, and talking about it in terms of selection misses that boat entirely. Select / update is how you manipulate a tree with jQuery, or really the average xml library.

Re: XSLT – Native, zero-config build system for the Web

#327
post #201

XML needs a renaissance because it solves problems modern formats still fumble with. Robust schema validation, namespaces, mixed content, and powerful tooling like XPath/XSLT. It's verbose, yes. It's can be made to look like shit and make you wanna throw up, but also battle-tested and structured for complexity. We ditched it too soon chasing simplicity.

chasing convenience, not simplicity

Re: XSLT – Native, zero-config build system for the Web

#329
post #269

Earlier quoted context omitted.

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…

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

SLAX is great, unfortunately it was released a bit too late.

XML world is full of ugly standards and failed contenders. None remembers RelaxNG. But had reacher expressive power than XMLSchema and a human-readable syntax.

Re: XSLT – Native, zero-config build system for the Web

#330

To show how wild things got w/ XML and XSLT in the early 2000s, I worked for a company that built an ASIC to parse XML at wire speed and process XSLT natively in the chip - because the anticipated future of the internet was all XML/XSLT. Intel bought the company and the guts made their way into the SSE accelerators.

IBM is still selling hardware that roughly matches your description: DataPower Gateway.

I forgot all about that!
Post reply on HN