Theme 1 – XSLT praised as a powerful, declarative transformation tool
Many commenters lament the loss of XSLT, noting its usefulness for turning XML data into HTML, creating modular sites, and styling feeds.
- “Shame back in the XHTML days XSLT was a spec that could have made website modularity so much cleaner… It was really powerful in the days before javascript was usable without jQuery.” – Trustable8
- “I have been using it for 26 years… XSLT has a lot of features and power that newer templating languages lack.” – mcculley
- “You could do some awesome things with XML/XSL… RSS feeds or OPML collections of RSS feeds … presenting that data to humans as a web page.” – Telemakhos
Theme 2 – XSLT/XHTML criticized for complexity, poor specs, and fragile tooling
Several users point out that the specification was badly written, tooling was inadequate, and the strict XML parsing made documents break easily.
- “The XSLT 1.0 spec specifically was written pretty badly… I had a hard time at making sense of it.” – g‑b‑r
- “XSLT 1.0 has some really obvious missteps… nobody just implements XSLT 1.0.” – WCSTombs
- “The main one is that even a slightly broken XHTML document will fail to render. HTML is much more forgiving.” – smallerize
- “The XHTML/XML/XSLT tooling was bad, and XSLT was hard to reason about.” – ebiester
Theme 3 – Justifications for removing XSLT: security, maintenance burden, and better alternatives
The decision to drop XSLT is defended by citing reduced attack surface, lack of real‑world usage, and the availability of simpler options like CSS or JavaScript templating.
- “Reducing attack surface.” – bazoom42 (in response to why legacy code is dropped)
- “Microsoft Edge adopts nearly all of the Chromium project's changes… Removed features don't always follow the same timelines.” – zamadatix
- “Yes, because XSLT won't work in Chrome and Edge anymore.” – WJW
- “Microsoft hasn’t bothered to fix this in IIS, and likely never will.” – jiggawatts (on the practical abandonment of XSLT‑based reports)