Why I like XSLT

&gt;Benefit #1: Portability<p>You know that a technology has got serious problems when the best thing you can say about it is &quot;well, it is at least preinstalled everywhere&quot;!<p>&gt;Benefit #2: Separation of concerns<p>If you want to put business logic in your XSLT, you can. It is a turing complete language (unlike, say, jinja2).<p>True, the language is so terrible that you will <i>probably</i> do everything possible to avoid putting business logic in your XSLT and that would help with your separation of concerns. I do not consider this a benefit, however.<p>&gt;Benefit #3: Transformations<p>This is not a benefit of the language. This simply what it was originally intended to do.<p>&gt;Benefit #4: Focus on API: The focus on XML as the result of a controller naturally focuses development on the application API<p>As opposed to other languages where you don&#x27;t focus development on the application API?<p>&gt;Benefit #5: Sand-boxed<p>Definitely a benefit but far from a unique one. It is also doesn&#x27;t have particularly good sandbox implementations: <a href="https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/" rel="nofollow">https:&#x2F;&#x2F;www.mozilla.org&#x2F;en-US&#x2F;security&#x2F;known-vulnerabilities...</a><p>&gt;Benefit #5: Ease of testing<p>Compared to what?

Wow, I never thought I&#x27;d see someone say that. I found it to be an endless nightmare when I had to use it. (We thought t would be really cool to store links and other stuff in XML and then transform that into our ASP.NET pages, so we could change the XML file without changing the website. It got complicated over time.)<p>The point about the syntax is a good one, but I don&#x27;t like the idea that people should just equivalently like any syntax that expresses the same basic ideas.<p>I can&#x27;t say why exactly but something just feels fundamentally wrong with writing code in XML. I felt the same way when I had to write MSBuild scripts, which are XML. I guess it could be trying to do imperative things in a declarative language, but that doesn&#x27;t seem to be a problem for Lispers.

XSLT is one of those cases where the idea and the intention is great, but the actual implementation is horrible.<p>I would love to see someone propose a modern alternative to XSLT, that works for the same use cases, but avoids XSLTs mistakes.

I interned at a company with an XML+XSLT based MVC framework once. I actually thought it worked really well and generally agree with the article. A lot of more &quot;modern&quot; template and transform solutions are aiming for the same goals: sandboxed, side-effect free, limited logic, and so on.<p>I especially like the power of combining XSLT with Batik and FOP. You can take backend data and present it as an interactive table, a visualization, or a PDF report really easily.<p>I will say that the syntax is <i>awfully</i> obtuse, though. I find that support for various powerful-but-obtuse 1990s&#x2F;2000s solution stacks splits along an IDE-user line: those who use IDEs are generally comfortable working with XML and XSLT in Java while text-editor devotees tend to hate that class of solution.

I can say with high confidence that I&#x27;ve probably written more XSLT then any of the commentators here ... respect completely their right to hate&#x2F;love&#x2F;ignore any tech, but many of the comments here are based on very little fact.<p>* first bugbear - XSLT is not an implementation of lisp (or insert lang here), we shouldn&#x27;t care if it implements said language well or not<p>* XSLT is extremely well (saxon) implemented in some processors and poorly in others ... unsure what that has to do with the language itself.<p>* XSLT has more implementations then a lot of other popular languages (Ruby, Perl, python come to mind), that doesn&#x27;t make it better (or worst) then those languages ... its just a fact.<p>* there are no security vulnerabilities in the design of XSLT that I am aware about (well, there are, and most certainly are in implementations, but at that level I can call out issues with every language and its processor(s)) ... stating it is insecure by design is rubbish<p>* anyone using XSLT v1.0 should know that there has been, for years, an XSLT v2.0 production ready version in the form of saxon-ce (w&#x2F; appropriate open source license) ... I can&#x27;t explain why folks insist on using XLST v1.0, some are doing so cause they can&#x27;t migrate to XSLT v2.0, many of them are unaware of new options.<p>I can understand why folks find XSLT hard, or hurts their brain or makes them want to cringe at the mention of an angle bracket ... teaching basic programming idioms is hard for most people, learning fp principles is even more of a bender (esp if you come from OO world) ... XSLT template matching is a powerful mechanism which allows one to perform transformations with a succinct set of matching rules ... but yes it is verbose and like many languages, XSLT has its ugly points to the language.<p>If you are allergic to angle brackets, then any language that uses them is going to be anathema to them, but every person I&#x27;ve known who have learned XSLT became a better programmer for it. Thats my own personally biased single data point observed &#x27;fact&#x27;.

XSLT definitely has its flaws and I&#x27;m not currently using it, but I am currently building an app whose UI is heavily data-driven, meaning a screen might display a dynamic list of items, each with a totally different editing&#x2F;viewing&#x2F;previewing experience. You can dance around the edges of this with current templating engines to the point where you have a workable solution for a specific case, but honestly nothing really compares to the generalizing power of template matching where all you&#x27;d need to do is wire up the appropriate XPath selector to a new template and there you go. This level of abstraction does not even appear to be on the radar of the templating libraries I&#x27;m familiar with but I&#x27;d love to hear about those that do support it if they exist.

I&#x27;d recently experimented with XSLT for a PHP site&#x27;s templating engine, after having ignored it since learning it about a decade ago. I swapped out all PHP code to load a bunch of variables for building a big DOMDocument tree in-memory, then applying my XSLT to that to build the rendered HTML. Once I stopped trying to stick a bunch of &lt;xsl:if&gt; and &lt;xsl:for-each&gt;es all over the place, and took a compositional approach to templating where I simply defined the &lt;xsl:template&gt;s I needed and then put &lt;xsl:apply-templates&gt; where I wanted them to go, it actually worked extremely well. All my templates were nicely organized, and I&#x27;m far happier working in XML than HTML, with all it&#x27;s wacky requirements with some tags needing to be closed and others not. It&#x27;s just the little things that really made me happy -- sticking my fontawesome icons in with an &lt;i class=&quot;fa fa-pied-piper&quot; &#x2F;&gt; instead of &lt;i class=&quot;fa fa-pied-piper&quot;&gt;&lt;&#x2F;i&gt; always brought a smile to my face. It also made testing nice and fast since it&#x27;s pretty easy to save the XML I want to transform as a file outside of my PHP app, and just xsltproc it from a terminal until I get it working how I want it.<p>The big pain points were all around the library support. The XSLT lib was generally fine, but the XML processing PHP provides was rubbish. The main complaint I heard was that even PHP5.5 wouldn&#x27;t support outputting as html5, and you need to manually just echo out a &#x27;&lt;!DOCTYPE html&gt;&#x27; to work around that. I couldn&#x27;t just import HTML directly from elsewhere as rendered by my CMS into my document tree either - it needed to have string literals of tags concatenated to it just to work. The sheer number of piddly little flags that are barely documented but you need to get exactly right in order for it to work at all was a big nuisance too. I also needed to turn off all parser warnings so it wouldn&#x27;t barf on reading html5 docs, and when a big advantage of the language is that you can be strict about your markup, it seems quite silly to have to turn off warnings.<p>Looking back on it, none of my problems were really with XSLT as a language, just with how it&#x27;s implemented in various languages. I feel like a lot of people got turned off when they learned about it in school, and consequently nobody was interested in doing a good job of implementing its supporting libraries in any language.

The opposing viewpoint: <a href="http://fishbowl.pastiche.org/2002/02/12/xslt_is_the_spawn_of_satan/" rel="nofollow">http:&#x2F;&#x2F;fishbowl.pastiche.org&#x2F;2002&#x2F;02&#x2F;12&#x2F;xslt_is_the_spawn_of...</a>

used a ton of xslt. it&#x27;s great for what it&#x27;s good for (transforming xml). of course, if i had to do it all over again i wouldn&#x27;t be using xml in the first place.

I bought into xslt2... which I think was only ever implimented in the saxon parser, written by they guy that wrote large chunks of the spec. My chain was simple, MS Access DB -&gt; XML (via hand written vba) -&gt; parser -&gt; 4 documents with information that was consistent. I then handed it over to a programmer to replace the Access DB &#x2F; XML &#x2F; Parser with the server versions, and he never did get it quite right. For my next project I chose JSON, on the idea that a beautiful solution doesn&#x27;t mean much if it can&#x27;t be productionized. Still sad about xslt though, lots of potential for making good looking pdfs and webpages that were consistent.

For me XSLT (I mean 2.0 and above) is awesome technology for current web environment. There are a lot of markup languages with which I can for example create graphics (SVG) and use it inside PDF (thru formatting objects (XSL-FO)). I can store complex application configurations inside Excel (OOXML) and transform it to xml and validate it (and then generate data file for db). Or I can manage language translations in excel file and merge them to individual properties files. I can also use powerful XSLT 2.0 inside browser with Saxon-CE. There are really lots of use cases for XSLT. I must mention that I use this technology with Apache ANT and this combination saved a lot of my time! In this way it is possible to do sophisticated automations. I don&#x27;t know how many people use it but it is possible to have a build file and some xml configuration. In main ant target you specify xslt task (input=xml configuration, output=build file) and subsequent ant task which triggers this generated build file. This technique gives great flexibility! Of course when working with XMLs you need a good IDE!

I&#x27;m very interested in working on a Javascript framework where you work directly with XML (for data and event binding) and let XSLT handle transforming it to HTML -- imagine React, except you work with XML instead, and treat it as an interface for your HTML.<p>Email me if you&#x27;d like to chat about it!

What I like about them the most of the separation. You&#x27;re actually manipulating the data (XML) and displaying it to end user in HTML without going through the formalities of coding.<p>Being using them since 1999 too. Still use them today although more work is being done with JSON&#x2F;JS.

I hate to promote my own site (<a href="http://theexceptioncatcher.com" rel="nofollow">http:&#x2F;&#x2F;theexceptioncatcher.com</a>) but I found that it made it a lot easier to separate the design of the site from the content. Most of my websites rarely ever change, so having a dynamic site is over kill. XSLT&#x2F;XML helps to keep it as a static site, and I have the opportunity to change&#x2F;fix the design at will.<p>Also, I&#x27;ve managed to setup a system to generate my resume via an XML&#x2F;XSLT transform. I haven&#x27;t published how I do that (or the public version [which is out of date]).<p>It&#x27;s a tool and it can be very useful if you understand what you&#x27;re doing. Additionally, there is Unix support for XSLT processing.

The improved syntax is interesting. Are there any better front-ends to XSLT? A quick google turned up SLAX, but I wonder if there are others.<p><a href="https://github.com/Juniper/libslax" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Juniper&#x2F;libslax</a>

One interesting use-case is having an Atom feed and HTML page at the same time. See source code here: <a href="https://curiosity-driven.org/" rel="nofollow">https:&#x2F;&#x2F;curiosity-driven.org&#x2F;</a>

I&#x27;ve used XSLT for APIs that return XML. This allows looking at the output of the API in a human-readable format. This is convenient as a debug tool, and anything that returns an XML page should have a link to the XLST for it.

So much promise but a clunky abomination imo. I personally wasted a lot of time with it about 10 years ago. I&#x27;ve noticed that technologies that are easier to work with in a text editor eventually win out.

ahhh, XSLT, haven&#x27;t heard that name in awhile.<p>For my CS honours thesis, I created XSLT debugging program - my research paper is here<p><a href="http://ww2.cs.mu.oz.au/~jbailey/papers/wise.ps" rel="nofollow">http:&#x2F;&#x2F;ww2.cs.mu.oz.au&#x2F;~jbailey&#x2F;papers&#x2F;wise.ps</a><p>I miss it :) but now that I&#x27;m doing lots of web development &amp; javascript, I do wonder that it is somewhat &quot;slow&quot; or &quot;heavy&quot; than other approaches.<p>Nonetheless, it was an awesome experience diving deep into the technology.

If I never heard the acronym XSLT again it would be too soon.

First, I don&#x27;t understand what&#x27;s with the complaints about the syntax. It&#x27;s just a flavor of XML. If you work with XML all day, then XSLT looks just fine. But even if you don&#x27;t like the syntax, so what - there aren&#x27;t any alternatives to XSLT.<p>Those of you that know and love XSLT will understand when I say I wish I could be cast into an alternative universe where XSLT continued to be mainstream.<p>I&#x27;ll continue to leverage this power-tool (and get paid handsomely by by clients for wielding such power) for the rest of my career.

&gt; He can have it.

Totally agree, XSLT is a great instrument and it can&#x2F;should be used in a browser too, see <a href="http://www.yegor256.com/2014/06/25/xml-and-xslt-in-browser.html" rel="nofollow">http:&#x2F;&#x2F;www.yegor256.com&#x2F;2014&#x2F;06&#x2F;25&#x2F;xml-and-xslt-in-browser.h...</a>

repost: <a href="https://news.ycombinator.com/item?id=8695638" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8695638</a> but there was no prior discussion there.

components could be achieved using xslt, you have a high level app spec, and you transform all the components.