4 ms·

XSLT is still good to learn -- I think it's conceptually sound, but its implementations are often terrible. I think the big pain points for most people are how

by jkoudys 12y ago

XSLT is still good to learn -- I think it's conceptually sound, but its implementations are often terrible. I think the big pain points for most people are how finicky XML is in general, but also that any libs you use to generate your XML and translate it require an absurd amount of configuration. Years ago, I saw all the weaknesses in mixed PHP/html for building pages, but all the server-side templating languages looked terrible (still do). I fell in love with the idea that was championed back in the late 90s, where you use your application to build XML, which only describes your data. You'd then have some XSLT on your web server (or in-browser) that would transform the XML into your document. Nowadays, this isn't that different of an approach from using my server-side PHP/python/node/Go to generate JSON, then building my DOM based on client-side templates; since I use ReactJS, my transforms are even still XML. A lot of the best-practices I learned from XSLT transferred over nicely too, e.g. avoiding control logic (<xsl:if>) in favour of <xsl:apply-templates>, since good javascript client-side templates should avoid branching control logic in favour of just Array.prototype.map() wherever you can. I think the real key isn't about understanding recursion, though you will gradually gain an appreciation for it, but understanding composition. Templating is too often done in the style common among poor developers, where they think about building a whole "page", instead of defining the components of that page. XSLT, in theory, would've been great for that, it's just a pain in the butt to actually implement. tl;dr if there is a need for this proposal, it would be better met by cleaning out all the cruft from XSLT, and building implementations that don't require such arcane syntax nobody can use it.

outsidetheparty 12y ago
Agreed re composition -- the sign that the language had finally 'clicked' was when you started seeing lots of little xsl:templates instead of one gigantic mass of if statements. I don't really agree that cruft or configuration difficulties were the problem, though. Verbose, sure, fine, but otherwise spare to a fault. I suspect it's more that it demanded understanding of fairly sophisticated coding concepts to be at all useful, but was too often perceived as "front end" tech, or as just another markup language -- so ended up being dropped in the laps of too many designers-with-a-few-javascript-recipes-under-their-belts who simply weren't equipped to cope with it. I spent a while running XSLT training sessions for a corporate client; 95% of my trainees would just reel away in disgust and confusion the instant they learned they wouldn't be able to, say, increment a variable. (The remaining handful would be all OMG THIS IS WHAT I HAVE BEEN WAITING FOR MY WHOLE LIFE. It got to be a little game of mine to try to predict ahead of time who would be which.) Maybe it was just ahead of its time; the average front-end web developer is a lot more sophisticated these days than we were back then. (yes yes get off my lawn I have clouds to shout at)
- FeloniousHam 12y ago
  Count me among those reeling in disgust: XML is unpleasant to work with, XSLT just adds layers of complexity on top of that. I wrote transforms for the few cases where I needed straight XML-to-XML conversions, but anything of complexity I retreated to a "real" language. It's obviously a personal choice, but I find working in XSL/XML like running through mud. The success of JSON is due in part to the low signal-to-noise inherent in XML, and maybe XSL's low popularity is likely due to the necessary complexity of dealing with unnecessarily noisy data. I sometimes daydream about a present where YAML got there first.
T-hawk 12y ago
XSLT is conceptually sound indeed, a transformation of tree structures. But the requirements and real-world usage cases thrown at it are often terribly suited for it. Real applications just don't fall neatly into tree transformations. I inherited a financial reporting web app using XSLT as the rendering mechanism. Requirements included things like running totals (state!), suppressing leading values when repeated between rows (also state), alternating row colors, external dependencies such as numeric formatting based on user's locale settings. A stateless tree transformation doesn't express that elegantly, so you end up with fantastically complicated and ugly XPath hacks. A running total would come from something like "sum all my parent's children with an index less than mine". Then that breaks when something comes up to introduce a need for another layer beneath that parent. XSLT is purely functional. <xsl:if>template</xsl:if> isn't even control logic, it is functional evaluation, the same as Lisp's (if x template nil). <xsl:for-each> also isn't an imperative loop (it's map) even though it looks imperative and most enterprise programmers trained on imperative languages think it is and use it as such. So it's no surprise that XSLT in the wild ends up as a messy ball of mud. Most templating languages have this problem, including PHP/HTML. The messy nature of real requirements isn't unique to XSLT. But XSLT manifests it most dramatically since it lacks a stateful and imperative framework to fall back on.
- spdustin 12y ago
  Just in case you're using XSL still, you could use <xsl:key/> to let you quickly do subtotals by summing the node set of items that match whatever grouping level you're on when you emit the last item in the group. <xsl:key name="items-by-order" match="item" use="../@orderid"/> ...snip...  <xsl:if test="count(. | key('items-by-order', ../@orderid)[last()]) = 1"> <xsl:value-of select="sum(key('items-by-order', ../@orderid))"/> </xsl:if> Running totals would be similar, except that your apply-templates for the item group would include a select that restricts the available nodes to the key() function's result, and you would sum current node with preceding nodes.
vidarh 12y ago
I built a whole website based on spitting out XML and using XSLT on either the server or (optionally; hidden behind a flag) in the browser to transform the XML to HTML. It gave us 90% of our API "for free": On any page you could add an argument to the URL to spit out the XML data for the page, and others to get the items on the page as ATOM or RDF. The developers hated the constraints it placed on them. But it was exactly because of the things the developers were prone to doing that was the reason for structuring it that way in the first place.

by jkoudys 12y ago

outsidetheparty 12y ago

Agreed re composition -- the sign that the language had finally 'clicked' was when you started seeing lots of little xsl:templates instead of one gigantic mass of if statements. I don't really agree that cruft or configuration difficulties were the problem, though. Verbose, sure, fine, but otherwise spare to a fault. I suspect it's more that it demanded understanding of fairly sophisticated coding concepts to be at all useful, but was too often perceived as "front end" tech, or as just another markup language -- so ended up being dropped in the laps of too many designers-with-a-few-javascript-recipes-under-their-belts who simply weren't equipped to cope with it. I spent a while running XSLT training sessions for a corporate client; 95% of my trainees would just reel away in disgust and confusion the instant they learned they wouldn't be able to, say, increment a variable. (The remaining handful would be all OMG THIS IS WHAT I HAVE BEEN WAITING FOR MY WHOLE LIFE. It got to be a little game of mine to try to predict ahead of time who would be which.) Maybe it was just ahead of its time; the average front-end web developer is a lot more sophisticated these days than we were back then. (yes yes get off my lawn I have clouds to shout at)

FeloniousHam 12y ago
Count me among those reeling in disgust: XML is unpleasant to work with, XSLT just adds layers of complexity on top of that. I wrote transforms for the few cases where I needed straight XML-to-XML conversions, but anything of complexity I retreated to a "real" language. It's obviously a personal choice, but I find working in XSL/XML like running through mud. The success of JSON is due in part to the low signal-to-noise inherent in XML, and maybe XSL's low popularity is likely due to the necessary complexity of dealing with unnecessarily noisy data. I sometimes daydream about a present where YAML got there first.

T-hawk 12y ago

XSLT is conceptually sound indeed, a transformation of tree structures. But the requirements and real-world usage cases thrown at it are often terribly suited for it. Real applications just don't fall neatly into tree transformations. I inherited a financial reporting web app using XSLT as the rendering mechanism. Requirements included things like running totals (state!), suppressing leading values when repeated between rows (also state), alternating row colors, external dependencies such as numeric formatting based on user's locale settings. A stateless tree transformation doesn't express that elegantly, so you end up with fantastically complicated and ugly XPath hacks. A running total would come from something like "sum all my parent's children with an index less than mine". Then that breaks when something comes up to introduce a need for another layer beneath that parent. XSLT is purely functional. <xsl:if>template</xsl:if> isn't even control logic, it is functional evaluation, the same as Lisp's (if x template nil). <xsl:for-each> also isn't an imperative loop (it's map) even though it looks imperative and most enterprise programmers trained on imperative languages think it is and use it as such. So it's no surprise that XSLT in the wild ends up as a messy ball of mud. Most templating languages have this problem, including PHP/HTML. The messy nature of real requirements isn't unique to XSLT. But XSLT manifests it most dramatically since it lacks a stateful and imperative framework to fall back on.

spdustin 12y ago
Just in case you're using XSL still, you could use <xsl:key/> to let you quickly do subtotals by summing the node set of items that match whatever grouping level you're on when you emit the last item in the group. <xsl:key name="items-by-order" match="item" use="../@orderid"/> ...snip...  <xsl:if test="count(. | key('items-by-order', ../@orderid)[last()]) = 1"> <xsl:value-of select="sum(key('items-by-order', ../@orderid))"/> </xsl:if> Running totals would be similar, except that your apply-templates for the item group would include a select that restricts the available nodes to the key() function's result, and you would sum current node with preceding nodes.

vidarh 12y ago

I built a whole website based on spitting out XML and using XSLT on either the server or (optionally; hidden behind a flag) in the browser to transform the XML to HTML. It gave us 90% of our API "for free": On any page you could add an argument to the URL to spit out the XML data for the page, and others to get the items on the page as ATOM or RDF. The developers hated the constraints it placed on them. But it was exactly because of the things the developers were prone to doing that was the reason for structuring it that way in the first place.