13 ms·

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

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, with performance very much abstracted away. There are XSLT templates that worked fine for most documents, but then one document came in with a ~100 row table and it blew up. Turns out that the template that processed the table is O(N^2) or worse, without any obvious way to optimize it (it might even have an XPath on each row that itself is O(N) or worse). I don't exactly know how it manifested, but as I recall the document was processed by XSLT for more than 7 minutes. JS might have other problems, but not being able to resolve algorithmic complexity issues is not one of them.

woodpanel 1y ago
Same here. A couple of blue chip websites I‘ve seen that could be completely taken down just by requesting the sitemap (more than once per minute). PS: That being said it is an implantation issue. But it may speak for itself that 100% of the XSLT projects I‘ve seen had it.
bux93 1y ago
Are you using the commercial version of Saxon? It's not expensive, and IMHO worth it for the features it supports (including the newer standards) and the performance. If I remember correctly (it was a long time ago) it does some clever optimizations.
- badmintonbaseba 1y ago
  We didn't use Saxon, I don't work there anymore. We also supported client-side (browser) XSLT processing, as well as server-side. It might have helped on the server side, maybe could even resolve some algorithmic complexities with some memoization (possibly trading off memory consumption). But in the end the core problem is XSLT, the language. Despite being a complete programming language, your options are very limited for resolving performance issues when working within the language.
  - halffullbrain 1y ago
    O(n^2) issues can typically be solved using keyed lookups, but I agree that the base processing speed is slow and the language really is too obscure to provide good DX. I worked with a guy who knew all about complexity analysis, but was quick to assert that "n is always small". That didn't hold - but he'd left the team by the time this became apparent.
- rjsw 1y ago
  The final free version of Saxon is a lot faster than earlier ones too. My guess is that it compiles the XSLT in some way for the JVM to use.
mark_and_sweep 1y ago
From my experience, most simple websites are fine with XSLT 1.0 and don't experience any performance problems.
- badmintonbaseba 1y ago
  Sure, performance might never become a problem, it is relatively rare. But when it does there is very little you can do about it.
nolok 1y ago
It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them, doesn't matter if XSLT or SOAP or even XHTML in a way ... Those were defined as machine language meant for machine talking to machine, and invariably something go south and it's not really made for us to intervene in the middle; it can be done but it's way more work than it should be; especially since they clearly never based it on the idea that those machine will sometime speak "wrong", or a different "dialect". It looks great, then you design your stuff and it goes great, then you deploy to the real world and everything catches on fire instantly and everytime you stop one another one starts.
- diggan 1y ago
  > It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them Generally speaking I feel like this is true for a lot of stuff in programming circles, XML included. New technology appears, some people play around with it. Others come up with using it for something else. Give it some time, and eventually people start putting it everywhere. Soon "X is not for Y" blogposts appear, and usage finally starts to decrease as people rediscover "use the right tool for the right problem". Wait yet some more time, and a new technology appears, and the same cycle begins again. Seen it with so many things by now that I think "we'll" (the software community) forever be stuck in this cycle and the only way to win is to explicitly jump out of the cycle and watch it from afar, pick up the pieces that actually make sense to continue using and ignore the rest.
  - colonwqbang 1y ago
    There have been many such cycles, but the XML hysteria of the 00s is the worst I can think of. It lasted a long time and the square peg XML was shoved into so many round holes.
    - 0x445442 1y ago
      IDK, the XML hysteria is similar by comparison to the dynamic and functional languages hysterias. And it pales in comparison to the micro services, SPA and the current AI hysterias.
agumonkey 1y ago
It's odd cause xslt was clearly made in an era where expecting long source xml to be processed was the norm, and nested loops would blow up obviously..
- j16sdiz 1y ago
  It was in the era when everything walk on the DOM tree, not streams. Streaming is not supported until later version.
  - agumonkey 1y ago
    Hmm my memory is fuzzy but I remember seeing backend processing of xml files a lot around 2005.
    - reactordev 1y ago
      But they worked on the xml body as a whole, in memory, which is where all the headaches started. Then we introduced WSDLs on top, and then we figured out streaming.
    - count 1y ago
      Yeah, I was using Novell DirXML to do XSLT processing of inbound/outbound data in 2000 (https://support.novell.com/techcenter/articles/ana20000701.html https://support.novell.com/techcenter/articles/ana20000701.h...) for directory services stuff. It was full XML body (albeit small document sizes, as they were usually user or identity style manifests from HR systems), no streaming as we know it today.
      - agumonkey 1y ago
        Ok, I never heard of the pre and post xml streaming era.. I got taught.
nithril 1y ago
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.
- sam_lowry_ 1y ago
  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.
  - jerf 1y 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.
    - yoz 1y 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-dom-templating-api/ https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...
bambax 1y ago
> XSLT 1.0 is still dominant How, where? In 2013 I was still working a lot with XSLT and 1.0 was completely dead everywhere one looked. Saxon was free for XSLT 2 and was excellent. I used to do transformation of both huge documents, and large number of small documents, with zero performance problems.
- PantaloonFlames 1y ago
  I recently had the occasion to work with a client that was heavily invested in XML processing for a set of integrations. They’re migrating / modernizing but they’re so heavily invested in XSL that they don’t want to migrate away from it. So I conducted some perf tests and, the performance I found for xslt in .NET (“core”) was slightly to significantly better than the performance of Java (current) and Saxon. But they were both fast. In the early days the xsl was all interpreted. And was slow. From ~2004 or so, all the xslt engines came to be jit compiled. XSL benchmarks used to be a thing, but rapidly declined in value from then onward because the perf differences just stopped mattering.
- pmarreck 1y ago
  Probably corps. I was working at Factset in the early 2000's when there was a big push for it and I imagine the same thing was reflected across every Microsoft shop across corporate America at the time, which (at the time) Microsoft was winning big marketshare in. (I bet there are still a ton of internal web apps that only work with IE... sigh) Obviously, that means there's a lot of legacy processes likely still using it. The easiest way to improve the situation seems to be to upgrade to a newer version of XSLT.
- int_19h 1y ago
  In the browsers.
ChrisMarshallNY 1y ago
> Even though there are newer XSLT standards, XSLT 1.0 is still dominant. I'm pretty sure that's because implementing XSLT 2.0 needs a proprietary library (Saxon XSLT[0]). It was certainly the case in the oughts, when I was working with XSLT (I still wake up screaming). XSLT 1.0 was pretty much worthless. I found that I needed XSLT 2.0, to get what I wanted. I think they are up to XSLT 3.0. [0] https://en.wikipedia.org/wiki/Saxon_XSLT https://en.wikipedia.org/wiki/Saxon_XSLT
- dragonwriter 1y ago
  Are you saying it is specified that you literally cannot implement it other than on top of, or by mimicing bug-for-bug, that library (the way it was impossible to implement WebQSL without a particular version of SQLite) or is Saxon XSLT just the only existing implementation of the spec?
  - ChrisMarshallNY 1y ago
    Support required support from libxml/libxsl. That tops out at 1.0. I guess you could implement your own, as it’s an open standard, but I don’t think anyone ever bothered to. I think the guy behind Saxon may be one of the XSLT authors.
    - int_19h 1y ago
      The author of Saxon is on the W3C committee for XPath, XSLT, and XQuery. That said, Saxon does (or at least did) have an open source version. It doesn't have all the features, e.g. no schema validation or query optimization, but all within the boundaries of the spec. The bigger problem there is that Saxon is written in Java, and browsers understandably don't want to take a dependency on that just for XSLT 2+.
larodi 1y ago
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.
- j45 1y ago
  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?
  - larodi 1y ago
    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.
    - masklinn 1y ago
      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.

woodpanel 1y ago

Same here. A couple of blue chip websites I‘ve seen that could be completely taken down just by requesting the sitemap (more than once per minute). PS: That being said it is an implantation issue. But it may speak for itself that 100% of the XSLT projects I‘ve seen had it.

bux93 1y ago

Are you using the commercial version of Saxon? It's not expensive, and IMHO worth it for the features it supports (including the newer standards) and the performance. If I remember correctly (it was a long time ago) it does some clever optimizations.

badmintonbaseba 1y ago
We didn't use Saxon, I don't work there anymore. We also supported client-side (browser) XSLT processing, as well as server-side. It might have helped on the server side, maybe could even resolve some algorithmic complexities with some memoization (possibly trading off memory consumption). But in the end the core problem is XSLT, the language. Despite being a complete programming language, your options are very limited for resolving performance issues when working within the language.
- halffullbrain 1y ago
  O(n^2) issues can typically be solved using keyed lookups, but I agree that the base processing speed is slow and the language really is too obscure to provide good DX. I worked with a guy who knew all about complexity analysis, but was quick to assert that "n is always small". That didn't hold - but he'd left the team by the time this became apparent.
rjsw 1y ago
The final free version of Saxon is a lot faster than earlier ones too. My guess is that it compiles the XSLT in some way for the JVM to use.

mark_and_sweep 1y ago

From my experience, most simple websites are fine with XSLT 1.0 and don't experience any performance problems.

badmintonbaseba 1y ago
Sure, performance might never become a problem, it is relatively rare. But when it does there is very little you can do about it.

nolok 1y ago

It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them, doesn't matter if XSLT or SOAP or even XHTML in a way ... Those were defined as machine language meant for machine talking to machine, and invariably something go south and it's not really made for us to intervene in the middle; it can be done but it's way more work than it should be; especially since they clearly never based it on the idea that those machine will sometime speak "wrong", or a different "dialect". It looks great, then you design your stuff and it goes great, then you deploy to the real world and everything catches on fire instantly and everytime you stop one another one starts.

diggan 1y ago
> It's generally speaking part of the problem with the entire "XML as a savior" mindset of that earlier era and a big reason of why we left them Generally speaking I feel like this is true for a lot of stuff in programming circles, XML included. New technology appears, some people play around with it. Others come up with using it for something else. Give it some time, and eventually people start putting it everywhere. Soon "X is not for Y" blogposts appear, and usage finally starts to decrease as people rediscover "use the right tool for the right problem". Wait yet some more time, and a new technology appears, and the same cycle begins again. Seen it with so many things by now that I think "we'll" (the software community) forever be stuck in this cycle and the only way to win is to explicitly jump out of the cycle and watch it from afar, pick up the pieces that actually make sense to continue using and ignore the rest.
- colonwqbang 1y ago
  There have been many such cycles, but the XML hysteria of the 00s is the worst I can think of. It lasted a long time and the square peg XML was shoved into so many round holes.
  - 0x445442 1y ago
    IDK, the XML hysteria is similar by comparison to the dynamic and functional languages hysterias. And it pales in comparison to the micro services, SPA and the current AI hysterias.

agumonkey 1y ago

It's odd cause xslt was clearly made in an era where expecting long source xml to be processed was the norm, and nested loops would blow up obviously..

j16sdiz 1y ago
It was in the era when everything walk on the DOM tree, not streams. Streaming is not supported until later version.
- agumonkey 1y ago
  Hmm my memory is fuzzy but I remember seeing backend processing of xml files a lot around 2005.
  - reactordev 1y ago
    But they worked on the xml body as a whole, in memory, which is where all the headaches started. Then we introduced WSDLs on top, and then we figured out streaming.
  - count 1y ago
    Yeah, I was using Novell DirXML to do XSLT processing of inbound/outbound data in 2000 (https://support.novell.com/techcenter/articles/ana20000701.html https://support.novell.com/techcenter/articles/ana20000701.h...) for directory services stuff. It was full XML body (albeit small document sizes, as they were usually user or identity style manifests from HR systems), no streaming as we know it today.
    - agumonkey 1y ago
      Ok, I never heard of the pre and post xml streaming era.. I got taught.

nithril 1y ago

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.

sam_lowry_ 1y ago
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.
- jerf 1y 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.
  - yoz 1y 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-dom-templating-api/ https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...

bambax 1y ago

> XSLT 1.0 is still dominant How, where? In 2013 I was still working a lot with XSLT and 1.0 was completely dead everywhere one looked. Saxon was free for XSLT 2 and was excellent. I used to do transformation of both huge documents, and large number of small documents, with zero performance problems.

PantaloonFlames 1y ago
I recently had the occasion to work with a client that was heavily invested in XML processing for a set of integrations. They’re migrating / modernizing but they’re so heavily invested in XSL that they don’t want to migrate away from it. So I conducted some perf tests and, the performance I found for xslt in .NET (“core”) was slightly to significantly better than the performance of Java (current) and Saxon. But they were both fast. In the early days the xsl was all interpreted. And was slow. From ~2004 or so, all the xslt engines came to be jit compiled. XSL benchmarks used to be a thing, but rapidly declined in value from then onward because the perf differences just stopped mattering.
pmarreck 1y ago
Probably corps. I was working at Factset in the early 2000's when there was a big push for it and I imagine the same thing was reflected across every Microsoft shop across corporate America at the time, which (at the time) Microsoft was winning big marketshare in. (I bet there are still a ton of internal web apps that only work with IE... sigh) Obviously, that means there's a lot of legacy processes likely still using it. The easiest way to improve the situation seems to be to upgrade to a newer version of XSLT.
int_19h 1y ago
In the browsers.

ChrisMarshallNY 1y ago

> Even though there are newer XSLT standards, XSLT 1.0 is still dominant. I'm pretty sure that's because implementing XSLT 2.0 needs a proprietary library (Saxon XSLT[0]). It was certainly the case in the oughts, when I was working with XSLT (I still wake up screaming). XSLT 1.0 was pretty much worthless. I found that I needed XSLT 2.0, to get what I wanted. I think they are up to XSLT 3.0. [0] https://en.wikipedia.org/wiki/Saxon_XSLT https://en.wikipedia.org/wiki/Saxon_XSLT

dragonwriter 1y ago
Are you saying it is specified that you literally cannot implement it other than on top of, or by mimicing bug-for-bug, that library (the way it was impossible to implement WebQSL without a particular version of SQLite) or is Saxon XSLT just the only existing implementation of the spec?
- ChrisMarshallNY 1y ago
  Support required support from libxml/libxsl. That tops out at 1.0. I guess you could implement your own, as it’s an open standard, but I don’t think anyone ever bothered to. I think the guy behind Saxon may be one of the XSLT authors.
  - int_19h 1y ago
    The author of Saxon is on the W3C committee for XPath, XSLT, and XQuery. That said, Saxon does (or at least did) have an open source version. It doesn't have all the features, e.g. no schema validation or query optimization, but all within the boundaries of the spec. The bigger problem there is that Saxon is written in Java, and browsers understandably don't want to take a dependency on that just for XSLT 2+.

larodi 1y ago

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.

j45 1y ago
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?
- larodi 1y ago
  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.
  - masklinn 1y ago
    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.