6 ms·

Javascript was instantly a hit from the day it was released, and it grew from there. XSLT never took off. Ever. It has never been a major force on the web, not

by jerf 1y ago

Javascript was instantly a hit from the day it was released, and it grew from there. XSLT never took off. Ever. It has never been a major force on the web, not even for five minutes. Even during the "XML all the things!" phase of the software engineering world, with every tailwind it would ever had, it was never a serious player. There was, at no point, any reason to invest in it any farther. Moreover, even if you push a button and rewrite history so that even so it was heavily invested in anyhow, I see no reason to believe it would have ever been a major force in that alternate history either. I would personally contend that it has always been a bad idea, and if anything, it has been unduly propped up by the browsers and overinvested in as it is. But perhaps less inflammatorily and more objectively, it has always been a foreign paradigm that most programmers have no experience in, and this was even more true in the "XML all the things!" era which predates the initial Haskell burst that pushed FP forward by a good solid decade, and the prospects of it ever being popular were never all that great.

em-bee 1y ago
i also don't see XSLT solving any problem that javascript could not solve. heck, if you rally need XSLT in the browser, using javascript you could even call some library like saxonjs, or you could run it webassembly.
- youngtaff 1y ago
  How do you format a raw XML file in the browser without XSLT?
  - em-bee 1y ago
    instead of including a reference to the XSLT sylesheet apparently you can also include javascript: https://stackoverflow.com/a/16426395 https://stackoverflow.com/a/16426395
    - youngtaff 1y ago
      But can it transform / format the XML?
      - em-bee 1y ago
        why should it not? once loaded it should find the XML in the DOM and transform that any way you like.
        em-bee 1y ago
        for the record, i just tested that the loaded javascript can access the DOM.
    - LegionMammal978 1y ago
      That's only if the original document is an XHTML document that will have scripts loaded. Other XML documents, such as RSS feeds, will not have any support for JS, short of something silly like putting it in an iframe.
      - em-bee 1y ago
        i didn't test it, but the stackoverflow answers suggested otherwise. are they wrong?
        youngtaff 1y ago
        Perhaps you should have tried testing it before commenting?
        em-bee 1y ago
        if you know that the solution does not work, then just say so and maybe explain why, instead of being snarky. all i did was to share a link to a resource. if you don't trust that resource you need to do your own testing. what ever i say, whether i tested it or not, doesn't add much more value. you can't trust my words any more than the resource i linked. you asked half a dozen times in the last few days how a plain xml file can be transformed without xslt. and you claimed that xslt can be used to transform an rss feed. well, guess what, i just tested this: an rss feed with the standard mimetype application/rss+xml doesn't load either an xsl stylesheet or javascript. to make that work you have to change the mimetype, and if you do that, both the xsl stylesheet or the javascript load. (just not both at the same time)
- account42 1y ago
  It solves the problem of not requiring a full turing machine with a giant API that has a history of actual exploits and not just FUD behind it.
  - em-bee 1y ago
    i believe XSLT is touring complete, and regarding exploits, you rather want to read this: https://news.ycombinator.com/item?id=44910050 https://news.ycombinator.com/item?id=44910050 it turns out that because XSLT was largely ignored, it is full of security issues, some of which have been in there for decades. so the reason XSLT doesn't have a history of exploits is because nobody used it.
- xg15 1y ago
  True, but that raises the question, why don't the browsers do that? I think no one would object if they removed XSLT from the browser's core and instead loaded up some WASM/JavaScript implementation when some XSLT is actually encountered. Sort of like a "built-in extension". Then browser devs could treat it like an extension (plus some small shims in the core) while the public API wouldn't have to change.
  - em-bee 1y ago
    because there is no demand for it.
- lenkite 1y ago
  You can have template includes that are auto interpreter by the browser - no need to write code AFAIK using XSLT.
  - em-bee 1y ago
    XSLT is code. code written with XML syntax. let me give you an example: in order to create a menu where the current active page is highlighted and not a link, i need to do this: <a> <xsl:choose> <xsl:when test="@name='home'"> <xsl:attribute name="class">selected</xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href">/</xsl:attribute> </xsl:otherwise> </xsl:choose> home </a> | <a> <xsl:choose> <xsl:when test="@name='about'"> <xsl:attribute name="class">selected</xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href">/about.xhtml</xsl:attribute> </xsl:otherwise> </xsl:choose> about </a> | XSLT is interesting because it has a very different approach to parsing XML, and for some transformations the resulting code can be quite compact. in particular, you don't have an issue with quoting/escaping special characters most of the time while still being able to write XML/HTML syntax. but then JSX from react solves that too. so the longer you look at it the less the advantages of XSLT stand out.
    - ndriscoll 1y ago
      You're sort of exaggerating the boilerplate there; a more idiomatic, complete template might be: <xsl:variable name="nav-menu-items"> <item href="foo.xhtml"><strong>Foo</strong> Page</item> <item href="bar.xhtml"><em>Bar</em> Page</item> <item href="baz.xhtml">Baz <span>Page</span></item> </xsl:variable> <xsl:template match="nav-menu"> <nav> <ul> <xsl:apply-templates select="$nav-menu-items/item"> <xsl:with-param name="current" select="@current-page"/> </xsl:apply-templates> </ul> </nav> </xsl:template> <xsl:template match="item"> <xsl:param name="current"/> <li> <xsl:choose> <xsl:when test="@href=$current"> <a class="selected"><xsl:apply-templates/></a> </xsl:when> <xsl:otherwise> <a href="{@href}"><xsl:apply-templates/></a> </xsl:otherwise> </xsl:choose> </li> </xsl:template> One nice thing about XSLT is that if you start with a passthrough template: <xsl:template match="@*|node()"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> You have basically your entire "framework" with no need to figure out how to set up a build environment because there is no build environment; it's just baked into the browser. Apparently in XSLT 3.0, the passthrough template is shortened to just `<xsl:mode on-no-match="shallow-copy"/>`. In XSLT 2.0+ you could also check against `base-uri(/)` instead of needing to pass in the current page with `<nav-menu current-page="foo.xhtml"/> and there's no `param` and `with-param` stuff needed. In modern XSLT 3.0, it should be able to be something more straightforward like: <xsl:mode on-no-match="shallow-copy"/> <xsl:variable name="menu-items"> <item href="foo.xhtml"><strong>Foo</strong> Page</item> <item href="bar.xhtml"><em>Bar</em> Page</item> <item href="baz.xhtml">Baz <span>Page</span></item> </xsl:variable> <xsl:template match="nav-menu"> <nav> <ul> <xsl:apply-templates select="$menu-items/item"/> </ul> </nav> </xsl:template> <xsl:template match="item"> <li> <xsl:variable name="current-page" select="tokenize(base-uri(/),'/')[last()]"/> <a href="{if (@href = $current-page) then '' else @href}" class="{if (@href = $current-page) then 'selected' else ''}"> <xsl:apply-templates/> </a> </li> </xsl:template> The other nice thing is that it's something that's easy to grow into. If you don't want to get fancy with your menu, you can just do: <xsl:template match="nav-menu"> <nav> <ul> <li><a href="foo.xhtml">Foo</a></li> <li><a href="bar.xhtml">Bar</a></li> <li><a href="baz.xhtml">Baz</a></li> </ul> </nav> </xsl:template> And now you have a `<nav-menu/>` component that you can add to any page. So to the extent that you're using it to create simple website templates but you're not a "web dev", it works really well for people that don't want to go through all of the hoops that professional programmers deal with. Asking people to figure out react to make a static website is absurd.

by jerf 1y ago

em-bee 1y ago

i also don't see XSLT solving any problem that javascript could not solve. heck, if you rally need XSLT in the browser, using javascript you could even call some library like saxonjs, or you could run it webassembly.

youngtaff 1y ago
How do you format a raw XML file in the browser without XSLT?
- em-bee 1y ago
  instead of including a reference to the XSLT sylesheet apparently you can also include javascript: https://stackoverflow.com/a/16426395 https://stackoverflow.com/a/16426395
  - youngtaff 1y ago
    But can it transform / format the XML?
    - em-bee 1y ago
      why should it not? once loaded it should find the XML in the DOM and transform that any way you like.
      - em-bee 1y ago
        for the record, i just tested that the loaded javascript can access the DOM.
  - LegionMammal978 1y ago
    That's only if the original document is an XHTML document that will have scripts loaded. Other XML documents, such as RSS feeds, will not have any support for JS, short of something silly like putting it in an iframe.
    - em-bee 1y ago
      i didn't test it, but the stackoverflow answers suggested otherwise. are they wrong?
      - youngtaff 1y ago
        Perhaps you should have tried testing it before commenting?
        em-bee 1y ago
        if you know that the solution does not work, then just say so and maybe explain why, instead of being snarky. all i did was to share a link to a resource. if you don't trust that resource you need to do your own testing. what ever i say, whether i tested it or not, doesn't add much more value. you can't trust my words any more than the resource i linked. you asked half a dozen times in the last few days how a plain xml file can be transformed without xslt. and you claimed that xslt can be used to transform an rss feed. well, guess what, i just tested this: an rss feed with the standard mimetype application/rss+xml doesn't load either an xsl stylesheet or javascript. to make that work you have to change the mimetype, and if you do that, both the xsl stylesheet or the javascript load. (just not both at the same time)
account42 1y ago
It solves the problem of not requiring a full turing machine with a giant API that has a history of actual exploits and not just FUD behind it.
- em-bee 1y ago
  i believe XSLT is touring complete, and regarding exploits, you rather want to read this: https://news.ycombinator.com/item?id=44910050 https://news.ycombinator.com/item?id=44910050 it turns out that because XSLT was largely ignored, it is full of security issues, some of which have been in there for decades. so the reason XSLT doesn't have a history of exploits is because nobody used it.
xg15 1y ago
True, but that raises the question, why don't the browsers do that? I think no one would object if they removed XSLT from the browser's core and instead loaded up some WASM/JavaScript implementation when some XSLT is actually encountered. Sort of like a "built-in extension". Then browser devs could treat it like an extension (plus some small shims in the core) while the public API wouldn't have to change.
- em-bee 1y ago
  because there is no demand for it.
lenkite 1y ago
You can have template includes that are auto interpreter by the browser - no need to write code AFAIK using XSLT.
- em-bee 1y ago
  XSLT is code. code written with XML syntax. let me give you an example: in order to create a menu where the current active page is highlighted and not a link, i need to do this: <a> <xsl:choose> <xsl:when test="@name='home'"> <xsl:attribute name="class">selected</xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href">/</xsl:attribute> </xsl:otherwise> </xsl:choose> home </a> | <a> <xsl:choose> <xsl:when test="@name='about'"> <xsl:attribute name="class">selected</xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href">/about.xhtml</xsl:attribute> </xsl:otherwise> </xsl:choose> about </a> | XSLT is interesting because it has a very different approach to parsing XML, and for some transformations the resulting code can be quite compact. in particular, you don't have an issue with quoting/escaping special characters most of the time while still being able to write XML/HTML syntax. but then JSX from react solves that too. so the longer you look at it the less the advantages of XSLT stand out.
  - ndriscoll 1y ago
    You're sort of exaggerating the boilerplate there; a more idiomatic, complete template might be: <xsl:variable name="nav-menu-items"> <item href="foo.xhtml"><strong>Foo</strong> Page</item> <item href="bar.xhtml"><em>Bar</em> Page</item> <item href="baz.xhtml">Baz <span>Page</span></item> </xsl:variable> <xsl:template match="nav-menu"> <nav> <ul> <xsl:apply-templates select="$nav-menu-items/item"> <xsl:with-param name="current" select="@current-page"/> </xsl:apply-templates> </ul> </nav> </xsl:template> <xsl:template match="item"> <xsl:param name="current"/> <li> <xsl:choose> <xsl:when test="@href=$current"> <a class="selected"><xsl:apply-templates/></a> </xsl:when> <xsl:otherwise> <a href="{@href}"><xsl:apply-templates/></a> </xsl:otherwise> </xsl:choose> </li> </xsl:template> One nice thing about XSLT is that if you start with a passthrough template: <xsl:template match="@*|node()"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> You have basically your entire "framework" with no need to figure out how to set up a build environment because there is no build environment; it's just baked into the browser. Apparently in XSLT 3.0, the passthrough template is shortened to just `<xsl:mode on-no-match="shallow-copy"/>`. In XSLT 2.0+ you could also check against `base-uri(/)` instead of needing to pass in the current page with `<nav-menu current-page="foo.xhtml"/> and there's no `param` and `with-param` stuff needed. In modern XSLT 3.0, it should be able to be something more straightforward like: <xsl:mode on-no-match="shallow-copy"/> <xsl:variable name="menu-items"> <item href="foo.xhtml"><strong>Foo</strong> Page</item> <item href="bar.xhtml"><em>Bar</em> Page</item> <item href="baz.xhtml">Baz <span>Page</span></item> </xsl:variable> <xsl:template match="nav-menu"> <nav> <ul> <xsl:apply-templates select="$menu-items/item"/> </ul> </nav> </xsl:template> <xsl:template match="item"> <li> <xsl:variable name="current-page" select="tokenize(base-uri(/),'/')[last()]"/> <a href="{if (@href = $current-page) then '' else @href}" class="{if (@href = $current-page) then 'selected' else ''}"> <xsl:apply-templates/> </a> </li> </xsl:template> The other nice thing is that it's something that's easy to grow into. If you don't want to get fancy with your menu, you can just do: <xsl:template match="nav-menu"> <nav> <ul> <li><a href="foo.xhtml">Foo</a></li> <li><a href="bar.xhtml">Bar</a></li> <li><a href="baz.xhtml">Baz</a></li> </ul> </nav> </xsl:template> And now you have a `<nav-menu/>` component that you can add to any page. So to the extent that you're using it to create simple website templates but you're not a "web dev", it works really well for people that don't want to go through all of the hoops that professional programmers deal with. Asking people to figure out react to make a static website is absurd.