5 ms·

In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Actually, you c

In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does. I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived and XSLT has dwindled. This is why XSLT has got to go: https://www.offensivecon.org/speakers/2025/ivan-fratric.html https://www.offensivecon.org/speakers/2025/ivan-fratric.html

ndriscoll 11mo ago
> JavaScript is better than XSLT in every way Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. It gives a very low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. You link a template just like you link a CSS file to reuse styles. Obvious. The equivalent Javascript functionality's documentation[0] starts going on about classes and callbacks and shadow DOM, which is by contrast not at all approachable for someone who just wants to make a web page. Obviously Javascript is necessary if you want to make a web application, but those are incredibly rare, and it's expected that you'll need a programmer if you need to make an application. Part of the death of the open web is that the companies that control the web's direction don't care about empowering individuals to do simple things in a simple way without their involvement. Since there's no simple, open way to make your own page that people can subscribe to (RSS support having been removed from browsers instead of expanded upon for e.g. a live home page), everyone needs to be on e.g. Facebook. It's the same with how they make it a pain to just copy your music onto your phone or backup your photos off of it, but instead you can pay them monthly for streaming and cloud storage. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_components https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
- dfabulich 11mo ago
  XSL is a Turing-complete functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function. Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad. The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements. XSL's "escape hatch" is to allow arbitrary Turing-complete transformations, with <xsl:variable>, <xsl:for-each>, and <xsl:if>. This makes easy transformations easy and hard transformations possible. XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled. > It gives a low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. JavaScript is a much better low-effort high-power on-ramp to templated web pages with no build steps or server software. JavaScript is the natural fit for adding custom HTML elements (web components). Seriously, XSLT is worse than JavaScript in every way, even at the stuff that XSLT is best at. Performance/bloat? Worse. Security? MUCH worse. Learnability / language design? Unimaginably worse. EDIT: You edited your post, but the Custom Element API is for interactive client-side components. If you just want to transform some HTML on the page into other HTML as the page loads, you can use querySelectorAll, the jQuery way.
  - James_K 11mo ago
    > Security? MUCH worse. This is patently false. It is much better for security if you use one of the many memory-safe implementations of it. This is like saying “SSL is insecure because I use an implementation with bugs”. No, the technology is fine. It's your buggy implementation that's the problem.
    - ndriscoll 11mo ago
      XSLT used as a pre-processor is obviously also a fundamentally better model for security because... it's used as a preprocessor. It cannot spy on you and exfiltrate information after page load because it's not running anymore (so you can't do voyeuristic stuff like capture user mouse movements or watch where they scroll on the page). It also doesn't really have the massive surface Javascript does for extracting information from the user's computer. It wasn't designed for that; it was designed to transform documents.
Pet_Ant 11mo ago
JavaScript is ever evolving and it means you need to stick to one of the two browsers (WebKit or Firefox) and keep upgrading. XSLT hasn't changed in years. It's an actual standard instead of an evolving one. I know that other independent browsers that I used to use back in the day just gave up because the pace of divergence pushed by the major implementations meant that it wasn't feasible to keep up independently. I still miss Konqueror.
- pitaj 11mo ago
  JavaScript is backwards compatible. You can use an older standard supported by everything if you wish.
  - Pet_Ant 11mo ago
    Really? Because I have an old iPad (4th gen?) that no longer works on many sites. If it was backwards compatible they'd still function.
    - O4epegb 11mo ago
      You are confusing backwards and forwards compatibility. Those sites may have added features that your iPad does not support, which is why it broke, if they have not added those, it might still work. However JS is not 100% backwards compatible either, it is in many cases, largely backwards compatible, but there are rare cases of bug fixes, or deprecated APIs that might be removed and break old code, but this is not even JS itself, it's more like web/engine standards.
    - demurgos 11mo ago
      You are talking about forward compatibility. JS is backwards compatible: new engines support code using old features. JS is not forward compatible: old engines don't support code using new features. Regarding your iPad woes, the problem is not the engine but websites breaking compat with it. The distinction matters as it means that once a website is published it will keep working. The only way to break an existing website is to publish a new version usually. The XSLT situation is note-worthy as it's an exception to this rule.
ErroneousBosh 11mo ago
> In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Wow. I can see the proposed scrapping of XSLT being a huge problem for all of the seven people who do this.
skobes 11mo ago
Your link is just the abstract, I had to hunt for the full talk: https://www.youtube.com/watch?v=U1kc7fcF5Ao https://www.youtube.com/watch?v=U1kc7fcF5Ao But it is quite interesting and especially learning about the security problems of the document() function (described @ 19:40-25:38) made me feel more convinced that removing XSLT is a good decision.
kuschku 11mo ago
> Actually, you can make an RSS feed user-browsable by using JavaScript instead Say I have an XML document that uses XSLT, how do I modify it to apply your suggestion? I've previously suggested the XML stylesheet tag should allow <?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?> which would then allow the script to use the service-worker APIs to intercept and transform the request. But with the implementation available today, I see no way to provide a first-class XSLT-like experience with JS.
- dfabulich 11mo ago
  For RSS/Atom, you put this in the XML, right inside the document element (the <feed> element or the <rss> element): <script src="https://example.org/script.js" xmlns="http://www.w3.org/1999/xhtml"></script> You can also put CSS in there, like this: <style xmlns="http://www.w3.org/1999/xhtml"> * { color: red; } </style> Or like this: <link href="https://example.org/style.css" rel="stylesheet" xmlns="http://www.w3.org/1999/xhtml"/>
  - kuschku 11mo ago
    How's the support for the first option? If that reliably works, I'm gonna stop being angry, as it solved all my needs (and would allow polyfilling xslt anyway) On second thought, that wouldn't allow me to modify the DOM before it's being parsed, I'd have to wipe the DOM and polyfill the entire page load, right?
    - dfabulich 11mo ago
      It works great in Chrome, Safari, and Firefox. https://github.com/dfabulich/style-xml-feeds-without-xslt https://github.com/dfabulich/style-xml-feeds-without-xslt Google has recommended a polyfill for XSLT ever since they announced their plan to remove it. https://developer.chrome.com/docs/web-platform/deprecating-xslt#polyfill https://developer.chrome.com/docs/web-platform/deprecating-x...
LtWorf 11mo ago
No you can't, since opening an RSS feed won't run a javascript.
- dfabulich 11mo ago
  https://github.com/dfabulich/style-xml-feeds-without-xslt https://github.com/dfabulich/style-xml-feeds-without-xslt
  - LtWorf 11mo ago
    You mean if instead of generating a feed you rewrite your server to generate a webpage then it will be a webpage? What will feed readers do with it?
throw_m239339 11mo ago
> by using JavaScript instead I think you're entirely missing the point of RSS by saying that. RSS doesn't and should require NOT Javascript. Now feeds could somehow be written in some bastard HTML5 directly, but please don't bring Javascript in that debate. XSLT allows to transform a XML document into an HTML presentation, without the need for javascript, that's its purpose.

ndriscoll 11mo ago

> JavaScript is better than XSLT in every way Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. It gives a very low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. You link a template just like you link a CSS file to reuse styles. Obvious. The equivalent Javascript functionality's documentation[0] starts going on about classes and callbacks and shadow DOM, which is by contrast not at all approachable for someone who just wants to make a web page. Obviously Javascript is necessary if you want to make a web application, but those are incredibly rare, and it's expected that you'll need a programmer if you need to make an application. Part of the death of the open web is that the companies that control the web's direction don't care about empowering individuals to do simple things in a simple way without their involvement. Since there's no simple, open way to make your own page that people can subscribe to (RSS support having been removed from browsers instead of expanded upon for e.g. a live home page), everyone needs to be on e.g. Facebook. It's the same with how they make it a pain to just copy your music onto your phone or backup your photos off of it, but instead you can pay them monthly for streaming and cloud storage. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_components https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

dfabulich 11mo ago
XSL is a Turing-complete functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function. Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad. The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements. XSL's "escape hatch" is to allow arbitrary Turing-complete transformations, with <xsl:variable>, <xsl:for-each>, and <xsl:if>. This makes easy transformations easy and hard transformations possible. XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled. > It gives a low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. JavaScript is a much better low-effort high-power on-ramp to templated web pages with no build steps or server software. JavaScript is the natural fit for adding custom HTML elements (web components). Seriously, XSLT is worse than JavaScript in every way, even at the stuff that XSLT is best at. Performance/bloat? Worse. Security? MUCH worse. Learnability / language design? Unimaginably worse. EDIT: You edited your post, but the Custom Element API is for interactive client-side components. If you just want to transform some HTML on the page into other HTML as the page loads, you can use querySelectorAll, the jQuery way.
- James_K 11mo ago
  > Security? MUCH worse. This is patently false. It is much better for security if you use one of the many memory-safe implementations of it. This is like saying “SSL is insecure because I use an implementation with bugs”. No, the technology is fine. It's your buggy implementation that's the problem.
  - ndriscoll 11mo ago
    XSLT used as a pre-processor is obviously also a fundamentally better model for security because... it's used as a preprocessor. It cannot spy on you and exfiltrate information after page load because it's not running anymore (so you can't do voyeuristic stuff like capture user mouse movements or watch where they scroll on the page). It also doesn't really have the massive surface Javascript does for extracting information from the user's computer. It wasn't designed for that; it was designed to transform documents.

Pet_Ant 11mo ago

JavaScript is ever evolving and it means you need to stick to one of the two browsers (WebKit or Firefox) and keep upgrading. XSLT hasn't changed in years. It's an actual standard instead of an evolving one. I know that other independent browsers that I used to use back in the day just gave up because the pace of divergence pushed by the major implementations meant that it wasn't feasible to keep up independently. I still miss Konqueror.

pitaj 11mo ago
JavaScript is backwards compatible. You can use an older standard supported by everything if you wish.
- Pet_Ant 11mo ago
  Really? Because I have an old iPad (4th gen?) that no longer works on many sites. If it was backwards compatible they'd still function.
  - O4epegb 11mo ago
    You are confusing backwards and forwards compatibility. Those sites may have added features that your iPad does not support, which is why it broke, if they have not added those, it might still work. However JS is not 100% backwards compatible either, it is in many cases, largely backwards compatible, but there are rare cases of bug fixes, or deprecated APIs that might be removed and break old code, but this is not even JS itself, it's more like web/engine standards.
  - demurgos 11mo ago
    You are talking about forward compatibility. JS is backwards compatible: new engines support code using old features. JS is not forward compatible: old engines don't support code using new features. Regarding your iPad woes, the problem is not the engine but websites breaking compat with it. The distinction matters as it means that once a website is published it will keep working. The only way to break an existing website is to publish a new version usually. The XSLT situation is note-worthy as it's an exception to this rule.

ErroneousBosh 11mo ago

> In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Wow. I can see the proposed scrapping of XSLT being a huge problem for all of the seven people who do this.

skobes 11mo ago

Your link is just the abstract, I had to hunt for the full talk: https://www.youtube.com/watch?v=U1kc7fcF5Ao https://www.youtube.com/watch?v=U1kc7fcF5Ao But it is quite interesting and especially learning about the security problems of the document() function (described @ 19:40-25:38) made me feel more convinced that removing XSLT is a good decision.

kuschku 11mo ago

> Actually, you can make an RSS feed user-browsable by using JavaScript instead Say I have an XML document that uses XSLT, how do I modify it to apply your suggestion? I've previously suggested the XML stylesheet tag should allow <?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?> which would then allow the script to use the service-worker APIs to intercept and transform the request. But with the implementation available today, I see no way to provide a first-class XSLT-like experience with JS.

dfabulich 11mo ago
For RSS/Atom, you put this in the XML, right inside the document element (the <feed> element or the <rss> element): <script src="https://example.org/script.js" xmlns="http://www.w3.org/1999/xhtml"></script> You can also put CSS in there, like this: <style xmlns="http://www.w3.org/1999/xhtml"> * { color: red; } </style> Or like this: <link href="https://example.org/style.css" rel="stylesheet" xmlns="http://www.w3.org/1999/xhtml"/>
- kuschku 11mo ago
  How's the support for the first option? If that reliably works, I'm gonna stop being angry, as it solved all my needs (and would allow polyfilling xslt anyway) On second thought, that wouldn't allow me to modify the DOM before it's being parsed, I'd have to wipe the DOM and polyfill the entire page load, right?
  - dfabulich 11mo ago
    It works great in Chrome, Safari, and Firefox. https://github.com/dfabulich/style-xml-feeds-without-xslt https://github.com/dfabulich/style-xml-feeds-without-xslt Google has recommended a polyfill for XSLT ever since they announced their plan to remove it. https://developer.chrome.com/docs/web-platform/deprecating-xslt#polyfill https://developer.chrome.com/docs/web-platform/deprecating-x...

LtWorf 11mo ago

No you can't, since opening an RSS feed won't run a javascript.

dfabulich 11mo ago
https://github.com/dfabulich/style-xml-feeds-without-xslt https://github.com/dfabulich/style-xml-feeds-without-xslt
- LtWorf 11mo ago
  You mean if instead of generating a feed you rewrite your server to generate a webpage then it will be a webpage? What will feed readers do with it?

throw_m239339 11mo ago

> by using JavaScript instead I think you're entirely missing the point of RSS by saying that. RSS doesn't and should require NOT Javascript. Now feeds could somehow be written in some bastard HTML5 directly, but please don't bring Javascript in that debate. XSLT allows to transform a XML document into an HTML presentation, without the need for javascript, that's its purpose.