4 ms·

> JavaScript is better than XSLT in every way Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't k

> JavaScript is better than XSLT in every way Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. It gives a very low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. You link a template just like you link a CSS file to reuse styles. Obvious. The equivalent Javascript functionality's documentation[0] starts going on about classes and callbacks and shadow DOM, which is by contrast not at all approachable for someone who just wants to make a web page. Obviously Javascript is necessary if you want to make a web application, but those are incredibly rare, and it's expected that you'll need a programmer if you need to make an application. Part of the death of the open web is that the companies that control the web's direction don't care about empowering individuals to do simple things in a simple way without their involvement. Since there's no simple, open way to make your own page that people can subscribe to (RSS support having been removed from browsers instead of expanded upon for e.g. a live home page), everyone needs to be on e.g. Facebook. It's the same with how they make it a pain to just copy your music onto your phone or backup your photos off of it, but instead you can pay them monthly for streaming and cloud storage. [0] https://developer.mozilla.org/en-US/docs/Web/API/Web_components https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

dfabulich 1y ago
XSL is a Turing-complete functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function. Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad. The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements. XSL's "escape hatch" is to allow arbitrary Turing-complete transformations, with <xsl:variable>, <xsl:for-each>, and <xsl:if>. This makes easy transformations easy and hard transformations possible. XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled. > It gives a low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. JavaScript is a much better low-effort high-power on-ramp to templated web pages with no build steps or server software. JavaScript is the natural fit for adding custom HTML elements (web components). Seriously, XSLT is worse than JavaScript in every way, even at the stuff that XSLT is best at. Performance/bloat? Worse. Security? MUCH worse. Learnability / language design? Unimaginably worse. EDIT: You edited your post, but the Custom Element API is for interactive client-side components. If you just want to transform some HTML on the page into other HTML as the page loads, you can use querySelectorAll, the jQuery way.
- James_K 1y ago
  > Security? MUCH worse. This is patently false. It is much better for security if you use one of the many memory-safe implementations of it. This is like saying “SSL is insecure because I use an implementation with bugs”. No, the technology is fine. It's your buggy implementation that's the problem.
  - ndriscoll 1y ago
    XSLT used as a pre-processor is obviously also a fundamentally better model for security because... it's used as a preprocessor. It cannot spy on you and exfiltrate information after page load because it's not running anymore (so you can't do voyeuristic stuff like capture user mouse movements or watch where they scroll on the page). It also doesn't really have the massive surface Javascript does for extracting information from the user's computer. It wasn't designed for that; it was designed to transform documents.
- Mikhail_Edoshin 1y ago
  Come on. With XSLT you write a rule and then write a fragment of the resulting document. <xsl:template match="abc"> <def ghi="jkl"/> </xsl:template> This is one of simplest ways to do things. With JavaScript you what? Call methods? CreateElement("def").setAttribute("def", "jkl") There is a ton of "template engines" (all strictly worse than XSLT); why people keep writing them? Why people invented JSX with all the complicated machinery if plain JavaScript is better?
munificent 1y ago
> XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively? I'd be willing to bet good money that the Venn diagram of users that fit the intersection of "authoring content for the web", "care about separating content from HTML", "comfortable with HTML", "not comfortable with JavaScript", and "able to ramp up on XSLT" is pretty small. At some point, we have to just decide "sorry, this use case is too marginal for every browser to maintain this complexity forever".
- rendaw 1y ago
  I've seen non-programmers learn SQL, and SQL is far more inconsistent, complex, non-orthogonal, fragmented, footgunny, and user hostile than most programming languages. I'm not sure what I mean by this, WRT XSLT vs Javascript.
- ndriscoll 1y ago
  I was such a non-programmer as a child, yes. At the time that XSLT was new, if you read a book on HTML and making web pages from the library, it would tell you about things like separating content from styles and layout, yes. Things that blew my mind were that you could install Apache on your own computer and your desktop could be a website, or (as I learned many years later) that you could make a server application (or these days now Javascript code) that calls a function based on a requested path instead of paths being 1:1 with files. By contrast, like I said XSLT was just a natural extension of HTML for something that everyone who's written a couple web pages wants to do. The fact that the web's new owners have decided that making web pages is too marginal a use-case for the Web Platform is my point.
  - ErroneousBosh 1y ago
    > it would tell you about things like separating content from styles and layout, yes. That's what CSS does.
    - 1y ago
ErroneousBosh 1y ago
> not at all approachable for someone who just wants to make a web page If someone wants to make a web page they need to learn HTML and CSS. Why would adding a fragile and little-used technology like XSLT help?
- Mikhail_Edoshin 1y ago
  Because you do not want to create web pages, but to render some information in the form of web pages. And as you write that information you make distinctions unique to a) this information and b) your approach to it. And one of the best ways to do this is to come up with a custom set of XML tags. You write about chess? Fine: invent tags to decribe parties, positions and moves. Or maybe a tutorial on Esperanto? Fine; invent a notation to highlight the lexical structure and the grammar. You can be as detailed as you want and at the same time you can ignore anything you do not care about. And then you want to merely render this semantically rich document into HTML. This is where XSLT comes in.
- basscomm 1y ago
  > Why would adding a fragile and little-used technology like XSLT help? A few years ago I bought a bunch of Skylanders for practically nothing when the toys to life fad faded away. To keep track of everything I made a quick and dirty XSLT script that sorted and organized the list of figures and formatted each one based on their 'element'. That would have been murderous to do in plain HTML and CSS: https://wyrm.org/inventory/skylanders.xml https://wyrm.org/inventory/skylanders.xml
  - dfabulich 1y ago
    It would have been murderous with just CSS, but it would have been trivial to do with JS, much easier than the hundreds of lines of XSL you wrote. https://wyrm.org/inventory/skylanders.xsl https://wyrm.org/inventory/skylanders.xsl
    - basscomm 1y ago
      > but it would have been trivial to do with JS Maybe! How much Javascript would I have to learn before I could come up with a 'trivial' solution? > the hundreds of lines of XSL you wrote. Those hundreds of lines are the same copy/pasted if statement with 5 different conditions. For each game, I create a table by: alphabetizing the XML > going through the list searching for figures that match the game > each time I find one go through the color list to find the color to use for the table row. There are 10 color choices per game, which means that I repeated a 10-choice if statement 5 times. There's nothing difficult here, it's just verbose.
spankalee 1y ago
I'm a web components guy myself, but that's not the equivalent JavaScript functionality at all, as XSLT doesn't event have components. XSLT is a functional transform language. The equivalent JavaScript would be something like registry of pure functions of Node -> Node and associated selectors and a TreeWalker that walks the XML document, invokes matching functions, and emits the result into a new document. Or you could consume the XML as data into a set of React functions.
dist-epoch 1y ago
Nobody learned web programming by putting XSLT on top of XML. This is a fantasy world that does not exist. People used PHP, or a tool which created HTML (DreamWeaver), or a website, or maybe a LLM today.

dfabulich 1y ago

XSL is a Turing-complete functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function. Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad. The problem is: no clean API is perfectly shaped for UI, so you always wind up having to do arbitrary, non-trivial transformations with tricky uses of for-each to make the output HTML satisfy user requirements. XSL's "escape hatch" is to allow arbitrary Turing-complete transformations, with <xsl:variable>, <xsl:for-each>, and <xsl:if>. This makes easy transformations easy and hard transformations possible. XSL's escape hatch is always needed, but it's absolutely terrible, especially compared to JS, especially compared to modern frameworks. This is why JS remained popular, but XSL dwindled. > It gives a low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natural fit if you want to add new custom HTML elements. JavaScript is a much better low-effort high-power on-ramp to templated web pages with no build steps or server software. JavaScript is the natural fit for adding custom HTML elements (web components). Seriously, XSLT is worse than JavaScript in every way, even at the stuff that XSLT is best at. Performance/bloat? Worse. Security? MUCH worse. Learnability / language design? Unimaginably worse. EDIT: You edited your post, but the Custom Element API is for interactive client-side components. If you just want to transform some HTML on the page into other HTML as the page loads, you can use querySelectorAll, the jQuery way.

James_K 1y ago
> Security? MUCH worse. This is patently false. It is much better for security if you use one of the many memory-safe implementations of it. This is like saying “SSL is insecure because I use an implementation with bugs”. No, the technology is fine. It's your buggy implementation that's the problem.
- ndriscoll 1y ago
  XSLT used as a pre-processor is obviously also a fundamentally better model for security because... it's used as a preprocessor. It cannot spy on you and exfiltrate information after page load because it's not running anymore (so you can't do voyeuristic stuff like capture user mouse movements or watch where they scroll on the page). It also doesn't really have the massive surface Javascript does for extracting information from the user's computer. It wasn't designed for that; it was designed to transform documents.
Mikhail_Edoshin 1y ago
Come on. With XSLT you write a rule and then write a fragment of the resulting document. <xsl:template match="abc"> <def ghi="jkl"/> </xsl:template> This is one of simplest ways to do things. With JavaScript you what? Call methods? CreateElement("def").setAttribute("def", "jkl") There is a ton of "template engines" (all strictly worse than XSLT); why people keep writing them? Why people invented JSX with all the complicated machinery if plain JavaScript is better?

munificent 1y ago

> XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively? I'd be willing to bet good money that the Venn diagram of users that fit the intersection of "authoring content for the web", "care about separating content from HTML", "comfortable with HTML", "not comfortable with JavaScript", and "able to ramp up on XSLT" is pretty small. At some point, we have to just decide "sorry, this use case is too marginal for every browser to maintain this complexity forever".

rendaw 1y ago
I've seen non-programmers learn SQL, and SQL is far more inconsistent, complex, non-orthogonal, fragmented, footgunny, and user hostile than most programming languages. I'm not sure what I mean by this, WRT XSLT vs Javascript.
ndriscoll 1y ago
I was such a non-programmer as a child, yes. At the time that XSLT was new, if you read a book on HTML and making web pages from the library, it would tell you about things like separating content from styles and layout, yes. Things that blew my mind were that you could install Apache on your own computer and your desktop could be a website, or (as I learned many years later) that you could make a server application (or these days now Javascript code) that calls a function based on a requested path instead of paths being 1:1 with files. By contrast, like I said XSLT was just a natural extension of HTML for something that everyone who's written a couple web pages wants to do. The fact that the web's new owners have decided that making web pages is too marginal a use-case for the Web Platform is my point.
- ErroneousBosh 1y ago
  > it would tell you about things like separating content from styles and layout, yes. That's what CSS does.
  - 1y ago

ErroneousBosh 1y ago

> not at all approachable for someone who just wants to make a web page If someone wants to make a web page they need to learn HTML and CSS. Why would adding a fragile and little-used technology like XSLT help?

Mikhail_Edoshin 1y ago
Because you do not want to create web pages, but to render some information in the form of web pages. And as you write that information you make distinctions unique to a) this information and b) your approach to it. And one of the best ways to do this is to come up with a custom set of XML tags. You write about chess? Fine: invent tags to decribe parties, positions and moves. Or maybe a tutorial on Esperanto? Fine; invent a notation to highlight the lexical structure and the grammar. You can be as detailed as you want and at the same time you can ignore anything you do not care about. And then you want to merely render this semantically rich document into HTML. This is where XSLT comes in.
basscomm 1y ago
> Why would adding a fragile and little-used technology like XSLT help? A few years ago I bought a bunch of Skylanders for practically nothing when the toys to life fad faded away. To keep track of everything I made a quick and dirty XSLT script that sorted and organized the list of figures and formatted each one based on their 'element'. That would have been murderous to do in plain HTML and CSS: https://wyrm.org/inventory/skylanders.xml https://wyrm.org/inventory/skylanders.xml
- dfabulich 1y ago
  It would have been murderous with just CSS, but it would have been trivial to do with JS, much easier than the hundreds of lines of XSL you wrote. https://wyrm.org/inventory/skylanders.xsl https://wyrm.org/inventory/skylanders.xsl
  - basscomm 1y ago
    > but it would have been trivial to do with JS Maybe! How much Javascript would I have to learn before I could come up with a 'trivial' solution? > the hundreds of lines of XSL you wrote. Those hundreds of lines are the same copy/pasted if statement with 5 different conditions. For each game, I create a table by: alphabetizing the XML > going through the list searching for figures that match the game > each time I find one go through the color list to find the color to use for the table row. There are 10 color choices per game, which means that I repeated a 10-choice if statement 5 times. There's nothing difficult here, it's just verbose.

spankalee 1y ago

I'm a web components guy myself, but that's not the equivalent JavaScript functionality at all, as XSLT doesn't event have components. XSLT is a functional transform language. The equivalent JavaScript would be something like registry of pure functions of Node -> Node and associated selectors and a TreeWalker that walks the XML document, invokes matching functions, and emits the result into a new document. Or you could consume the XML as data into a set of React functions.

dist-epoch 1y ago

Nobody learned web programming by putting XSLT on top of XML. This is a fantasy world that does not exist. People used PHP, or a tool which created HTML (DreamWeaver), or a website, or maybe a LLM today.