5 ms·

I'm not necessarily opposed to something along these lines, except that it's basically already been tried: XSLT was essentially the inverse of this, where data

by _wmd 12y ago

I'm not necessarily opposed to something along these lines, except that it's basically already been tried: XSLT was essentially the inverse of this, where data endpoints were annotated with some static rendering descriptors. To me the XSLT approach seems cleaner, in that the URLs the browser is visiting are for the raw data itself, the URL scheme between machine and human is identical, and so on. XSLT also encouraged producing network-friendly compound representations for data, rather than the typical small collection of pure CRUD endpoints over fixed structures (/users/1, /comments/1231, etc.), since XSLT had limited ability to trigger loading external data without falling back to Javascript hacks or similar. But I imagine the tragic flaw in both the data binding proposal here and how XSLT worked is massively increased complexity for fairly little gain - and I think that's why XSLT has died a gentle death over the past decade. Still, both ideas appeal to me from the perspective of escaping horrendous chunks of procedural macros being shipped with data just to make it render on the client.

outsidetheparty 12y ago
Yep. I used to love XSLT -- working in it finally forced me to understand recursion at, like, a deep cellular level -- but the whole time I was using it I knew it was a doomed language (because most people don't want to have to understand recursion at a deep cellular level just to be able to lay out a damn web page.)
- pjmlp 12y ago
  Yet, alongside XHTML it would allow to move HTML to a proper layout engine like most native GUIs have, instead of the hack-a-mole we have to deal with.
- 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.
- talmand 12y ago
  I used to despise XSLT. Actually, I still do. As a front-end developer I found it absolutely horrid to work with. I jumped ship on that as soon as possible. But if you like it, that's cool.
  - deleted 12y ago
    [deleted]
- PedroBatista 12y ago
  XSLT is a good idea, everything else about it is just tragic, especially the language to the point I would support Nuremberg style Trials for this kind of events in computer history.
vbezhenar 12y ago
XSLT is a good idea with terrible implementation IMO. There's language called cduce. I'm not sure if it alive but it was interesting alternative implementation, though it was too much academical to be practical. But there could be usable language for trees transformation. Overall this idea is much better than current state of things.
nashashmi 12y ago
> XSLT has died a gentle death Maybe it is not because that XSLT is complex, but because XML has failed to become a language for the web. JSON has come to be the preferred choice. Which brings me to JSON and complexity: The complexity of retrieving data has been paved over multiple times using libraries. This has encouraged people to skip XML and go directly to JSON. If retrieval of XML data, or better yet JSON data, were to become simpler, I think more people would structure their webpages to use these types of resources. In the end, it would be a victory for both open Web and open applications. And that brings me to my last point: Dynamic elements. This web ain't succeeding without variable based dynamics. These pathways for dynamic behaviors have to be baked into browsers from the start. Then let JS abuse that dynamic just like JQuery abuses attributes, styles, and content.
- emodendroket 12y ago
  I think before someone goes putting JSON in even more places we should agree on a format for serializing dates, personally.
Millennium 12y ago
XSLT was an interesting language that unfortunately tried to solve the wrong problem. What we needed was AWK for the DOM. Instead we got a vision where XML would be used to transform other forms XML into yet OTHER forms of XML, and the result was a mess. I think there's still a place for an "AWK for the DOM". The XML extensions to gawk are interesting, but not really what I'm talking about; it works at a lower level (more like an "AWK for SAX"). jQuery comes closer to what I'm talking about, but I still wouldn't really call it a clean match.
- arethuza 12y ago
  That's a good idea - keep XPath but lose the XML based syntax. Edit: In fact, lose the XML completely and go with JSON and JSONPath.

by _wmd 12y ago

outsidetheparty 12y ago

Yep. I used to love XSLT -- working in it finally forced me to understand recursion at, like, a deep cellular level -- but the whole time I was using it I knew it was a doomed language (because most people don't want to have to understand recursion at a deep cellular level just to be able to lay out a damn web page.)

pjmlp 12y ago
Yet, alongside XHTML it would allow to move HTML to a proper layout engine like most native GUIs have, instead of the hack-a-mole we have to deal with.
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.
talmand 12y ago
I used to despise XSLT. Actually, I still do. As a front-end developer I found it absolutely horrid to work with. I jumped ship on that as soon as possible. But if you like it, that's cool.
- deleted 12y ago
  [deleted]
PedroBatista 12y ago
XSLT is a good idea, everything else about it is just tragic, especially the language to the point I would support Nuremberg style Trials for this kind of events in computer history.

vbezhenar 12y ago

XSLT is a good idea with terrible implementation IMO. There's language called cduce. I'm not sure if it alive but it was interesting alternative implementation, though it was too much academical to be practical. But there could be usable language for trees transformation. Overall this idea is much better than current state of things.

nashashmi 12y ago

> XSLT has died a gentle death Maybe it is not because that XSLT is complex, but because XML has failed to become a language for the web. JSON has come to be the preferred choice. Which brings me to JSON and complexity: The complexity of retrieving data has been paved over multiple times using libraries. This has encouraged people to skip XML and go directly to JSON. If retrieval of XML data, or better yet JSON data, were to become simpler, I think more people would structure their webpages to use these types of resources. In the end, it would be a victory for both open Web and open applications. And that brings me to my last point: Dynamic elements. This web ain't succeeding without variable based dynamics. These pathways for dynamic behaviors have to be baked into browsers from the start. Then let JS abuse that dynamic just like JQuery abuses attributes, styles, and content.

emodendroket 12y ago
I think before someone goes putting JSON in even more places we should agree on a format for serializing dates, personally.

Millennium 12y ago

XSLT was an interesting language that unfortunately tried to solve the wrong problem. What we needed was AWK for the DOM. Instead we got a vision where XML would be used to transform other forms XML into yet OTHER forms of XML, and the result was a mess. I think there's still a place for an "AWK for the DOM". The XML extensions to gawk are interesting, but not really what I'm talking about; it works at a lower level (more like an "AWK for SAX"). jQuery comes closer to what I'm talking about, but I still wouldn't really call it a clean match.

arethuza 12y ago
That's a good idea - keep XPath but lose the XML based syntax. Edit: In fact, lose the XML completely and go with JSON and JSONPath.