← Back to context

Comment by jerf

3 months 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.

31 comments

jerf

Reply
em-bee  3 months 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.

  • xg15  3 months 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.

  • lenkite  3 months ago

    You can have template includes that are auto interpreter by the browser - no need to write code AFAIK using XSLT.

    • em-bee  3 months 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.

      10 replies →

  • account42  3 months 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  3 months ago

      i believe XSLT is touring complete, and regarding exploits, you rather want to read this: 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.