It’s probably irrelevant to an introduction. I think in this post the goal is to explain to a modern audience why something like this is beneficial. XSLT is part of the history here, but including it wouldn’t help sell the idea.
I am hesitant. On the one hand, visualization as presented might drive some interest ( and maybe adoption ), but XLST would definitely be useful for a person that would actually suggest it as a solution toa nything. Not to search very far, I myself found recently I have to not just massage XML data, but also 'sell it' to my various bosses.
I guess what I am saying is: I see your point. I am also saying ( as I dig in a little deeper ) that XLST would likely be helpful.
Oh yeah for sure, there should be somewhere on their site that does some kind of comparison to XSLT. Because as you pointed out, anyone who knows their history is going to wonder about it.
I’ve personally never written an application using XSLT, but I’ve researched it a bit. In my limited understanding, I believe XSLT was designed for transformations that happen on initial page load, or in a SSR context. For dynamic client interactions like the ones enabled by React, it wouldn’t suffice since it’s designed to recreate the entire document on every pass.
^ I could be very wrong about this, would love for someone more knowledgeable than me to chime in and correct me.
You're basically correct, but this isn't due to a philosophical choice. Simply speaking, XSLT stopped evolving before Ajax really got popular, and it was eventually purged from most browsers altogether on security grounds. So nobody really tried to build XSLT engines that could address modern use-cases.
Somewhat ironically, the semantic web was initially supposed to be built on browsers making calls for XML data (the X in Ajax) to then be displayed via XSLT. This model failed to gain adoption mostly because, let's be honest, XSLT is just blooming hard.
I know it depends of the definition of "modern browser", but I'm fairly sure that MSIE and pre-chrome Edge had lost support for it at some point, since MSXML stopped being shipped with them.
I honestly don't know what the current state of the art is, but Firefox doesn't do native XSLT anymore afaik (yes, you can do it in JS, but it's an extra step).
Recreating whole documents is how XSLT has been commonly used, but that’s an implementation detail, and you can nearly as easily write XSLT to produce components. You can output XHTML components and update the vdom - kind of an abstraction leak but not a bad tradeoff if you want to reuse the rendering XSLT. Alternatively, XSLT 3.0 can produce (and consume!) JSON, so you can use it as way to bridge XML into a traditional React app or to simply process JSON.
