Comment by notpushkin

17 hours ago

I’m a big fan of XHTML (strictness is good) and feel like XSLT could be a great addition, but I hate the syntax. I’d love to build a Jinja to XSLT compiler one day.

I also have a simple playground for XSLT: https://xsltbin.ale.sh/

12 comments

notpushkin

Reply
nine_k  14 hours ago

XSLT's weaknesses are the extension of its strengths. It's the first homoiconic, purely functional language that enjoyed widespread adoption among "normal" developers, not type theory wonks.

But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful and expressive if you hold it right, almost like a Lisp. This saved me a few times around year 2000 or so.

  • PaulHoule  3 hours ago

    Homiconicity can get you into trouble.

    CSS and HTML have a dual relationship. You could certainly write CSS with an XML-like syntax but people would always get confused at whether they are looking at style or markup. Because HTML and CSS look completely different you never have that problem.

    XSLT shares the same problem with the RDF specs coming out at the same time that it hid the production rules/logical nature of the system, had it looked more like

      <someElement someAttributeattribute=$x/> -> <anotherElement>$x</anotherElement>

    it could have been quite different. But production rules never really sold (got told that by the marketing chief of vendor at a hotel bar after a conference they sponsored) and it's an interesting question why. They can do all kind of neat things like manage asynchronous processes that happen over a long period of time (like having a loan officer approve a loan) but nobody ever tried to use them to deal with the async comm problem in Javascript as far as I can tell.

  • agumonkey  14 hours ago

    I barely used xslt, but as a fp head I wanted to try, the most confusing part to me were terminology / semantics / decoupling. Seemed like matching templates could be anywhere making difficult to understand the meaning of a script.

    • PaulHoule  3 hours ago

      In some sense that's a strength. When things can happen in any order you can mash together two things and they work together.

      When I was looking for my own revolution in software engineering I saw one part of the low code/no code puzzle was that conventional tools force you to determine what order events happen which was something laymen shouldn't be bothered to do. Some counters are: spreadsheets (they figure out what order to calculate it), make (does a topological sort), dependency injection tools like Spring (writing a FactoryFactoryFactory isn't so bad, but maintaining it is a disaster when a "small" change means you have to reorder the order in which you construct everything)

      There is a "freedom is slavery" problem here. People saw the semantic web as "you're going to exhaust yourself arguing with people about standards and ontologies before you even start coding" and not "if my data is properly namespace I can throw data from 10 different sources together into my RDF database and start writing queries".

  • mattmanser  11 hours ago

    I wouldn't say it had widespread adoption. We used XSLT in my day job at the time to do client-side updates, even had a special SQL API that turned sql queries into XML automatically by naming the columns with a special syntax and it was virtually unheard of (2007?).

    It was actually great when you got it, but the learning curve was so steep many developers couldn't use it effectively to begin with. For complex pages only certain developers could make changes or fix the bugs. Precisely because it was functional and most developers at the time really only understood imperative.

    In fact, I remember the DailyWTF had a WTF about using XSLT as client-side transforms a few years later:

    https://thedailywtf.com/articles/Sketchy-Skecherscom

    But doing something like that was in fact so much faster than doing it in js, and when you groked it (deliberate throwback), it was so much simpler. I actually wrote a pivot table control in XSLT which completely blew away the performance of the pre-v8 javascript one. Pre-V8 javascript was so slow most developers wouldn't believe you now. A 10,000 iteration loop of even basic operations was often enough to cause IE6 to show a pop-up saying the page wasn't responding.

    The pivot table in javascript would crash with just a few hundred lines of data, in XSLT it was instant with even 10,000s.

    A really interesting use of XSLT on the web at the time was the WoW character viewer. You could view (and share) your character on Blizzard's website, with all their gear, skills, etc. It was blazingly fast for the time and it was all written in XSLT.