4 ms·

I can say with high confidence that I've probably written more XSLT then any of the commentators here ... respect completely their right to hate/love/ignore any

by jimfuller2014 12y ago

I can say with high confidence that I've probably written more XSLT then any of the commentators here ... respect completely their right to hate/love/ignore any tech, but many of the comments here are based on very little fact. * first bugbear - XSLT is not an implementation of lisp (or insert lang here), we shouldn't care if it implements said language well or not * XSLT is extremely well (saxon) implemented in some processors and poorly in others ... unsure what that has to do with the language itself. * XSLT has more implementations then a lot of other popular languages (Ruby, Perl, python come to mind), that doesn't make it better (or worst) then those languages ... its just a fact. * 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 * 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/ appropriate open source license) ... I can't explain why folks insist on using XLST v1.0, some are doing so cause they can't migrate to XSLT v2.0, many of them are unaware of new options. 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. If you are allergic to angle brackets, then any language that uses them is going to be anathema to them, but every person I've known who have learned XSLT became a better programmer for it. Thats my own personally biased single data point observed 'fact'.

Tloewald 12y ago
I don't think learning XSLT made me a better programmer, but it is an amazingly useful tool for dealing with large amounts of XML (which is what it was designed for). That said, the way XPATH works is -- to put it mildly -- counter-intuitive. My biggest gripe with XSLT is debugging. It's just not very much fun. Insofar as it forces you to reason very carefully about your code, that's probably good practice if you haven't already had plenty of practice -- e.g. developing websites before we had decent browser consoles, or writing INITs and TSRs in the 80s.
- qaribou 12y ago
  We were probably using it for very different things (I used it to render my HTML for a PHP site), but I actually found the debugging part to be a huge advantage of xslt. The errors I had relating to basic config and encoding issues were all big headaches, sure, but debugging issues caused by my own incorrect assumptions about how my data was structured was great -- I never felt lost and every message gave me a clear idea what I needed to look at.
qaribou 12y ago
Learning XSLT definitely helped me write much better views in any MVC/MVVM project I have, because the whole approach to template matching is useful as a general design principle. When I'd first started in web development, my views were all very top-down and rife with control logic. After spending considerable time rendering my pages by building XML and applying XSLT, I found a lot of the skills transfer. Lately I've been working a lot in React, and I've found that just understanding the new syntax can be learned in a weekend -- instead of transforming an XML doc, I load JSON into my state, and instead of writing <xsl:template>s I write React classes. The sort of skills that one refines over years, namely how to think of your rendered page as being composed of various smaller templates, benefit me everywhere. XSLT was a really intensive way to force myself to learn to think that way. Even my mixed PHP/HTML that I occasionally still have to write is considerably better. to your point about XSLT v1, I can speak to why it's so rarely used at least by PHP devs: v1 has been included as a default extension in PHP builds for many years, but v2 has always required a separate installation of saxon. I just checked on my reasonably up-to-date ubuntu default install, and it's XSLT 1.1.28. That's still far better than Go, where the only approach I've seen is to just install command-line xsltproc and execute that. v2.0 isn't going to catch on while v1.0 is what's considered the de-facto standard, and v1 being the de-facto standard is a big part of why so many have a poor opinion of xslt.

Tloewald 12y ago

I don't think learning XSLT made me a better programmer, but it is an amazingly useful tool for dealing with large amounts of XML (which is what it was designed for). That said, the way XPATH works is -- to put it mildly -- counter-intuitive. My biggest gripe with XSLT is debugging. It's just not very much fun. Insofar as it forces you to reason very carefully about your code, that's probably good practice if you haven't already had plenty of practice -- e.g. developing websites before we had decent browser consoles, or writing INITs and TSRs in the 80s.

qaribou 12y ago
We were probably using it for very different things (I used it to render my HTML for a PHP site), but I actually found the debugging part to be a huge advantage of xslt. The errors I had relating to basic config and encoding issues were all big headaches, sure, but debugging issues caused by my own incorrect assumptions about how my data was structured was great -- I never felt lost and every message gave me a clear idea what I needed to look at.

qaribou 12y ago

Learning XSLT definitely helped me write much better views in any MVC/MVVM project I have, because the whole approach to template matching is useful as a general design principle. When I'd first started in web development, my views were all very top-down and rife with control logic. After spending considerable time rendering my pages by building XML and applying XSLT, I found a lot of the skills transfer. Lately I've been working a lot in React, and I've found that just understanding the new syntax can be learned in a weekend -- instead of transforming an XML doc, I load JSON into my state, and instead of writing <xsl:template>s I write React classes. The sort of skills that one refines over years, namely how to think of your rendered page as being composed of various smaller templates, benefit me everywhere. XSLT was a really intensive way to force myself to learn to think that way. Even my mixed PHP/HTML that I occasionally still have to write is considerably better. to your point about XSLT v1, I can speak to why it's so rarely used at least by PHP devs: v1 has been included as a default extension in PHP builds for many years, but v2 has always required a separate installation of saxon. I just checked on my reasonably up-to-date ubuntu default install, and it's XSLT 1.1.28. That's still far better than Go, where the only approach I've seen is to just install command-line xsltproc and execute that. v2.0 isn't going to catch on while v1.0 is what's considered the de-facto standard, and v1 being the de-facto standard is a big part of why so many have a poor opinion of xslt.