6 ms·

No mention of XSLT? Feels like it would be highly relevant since many folks have not considered transforming or styling XML since those days, and would be inter

No mention of XSLT? Feels like it would be highly relevant since many folks have not considered transforming or styling XML since those days, and would be interested in understanding the huge leap from that to this. And given Jon Udell has written about XSLT before[0], I'm sure this was an intentional decision. Not sure I understand it though. 0: https://www.xml.com/pub/a/2003/08/13/udell.html https://www.xml.com/pub/a/2003/08/13/udell.html

danielvaughn 1y ago
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.
- A4ET8a8uTh0_v2 1y ago
  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.
  - danielvaughn 1y ago
    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.
    - toyg 1y ago
      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.
      - int_19h 1y ago
        I don't think it was ever "purged" - I mean, which modern browser doesn't handle XSLT 1.0? Nor did the spec itself stop evolving. The problem is that the browsers have deprecated the technology before XSLT 2+ could be adopted.
        toyg 1y ago
        > which modern browser doesn't handle XSLT 1.0? 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).
    - willseth 1y ago
      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.
sheepscreek 1y ago
The performance of available XSLT translation engines would be a big consideration for me, especially in a hot-reload context to support fast iterations.
- thechao 1y ago
  That was my first thought: no XSLT 3 engine that I know of keeps an in-memory object that supports iterative retemplating on diff changes to the source. I think the closest to this is in the functional communities and their lenses. Given how "far" XSLT can reach through a document via Xpath, I don't think it's an easy-to-solve problem.
homarp 1y ago
if the target audience is 'citizen developer', aka Visual Basic (classic), I am not sure introducing XSLT is such a good idea.
majewsky 1y ago
Every time I've seen XSLT deployed, it was "that one hairball that no one besides the original author dares to touch". I'm not sure what it is about the technology, but it seems to either inevitably desolve into a complex mess or attract complexity fetishists. Either way, not something that would be an obvious choice for what OP is going for.
- Quarrelsome 1y ago
  its because it demands to everything to be effectively processed in a one liner and is locked into its early version due to a licensing failure (I've yet to work in an org that pays up). So if you work in XSLT, then you're stuck in 1999. IMHO the pattern to improve XSLT is to call out into more useful languages like javascript, which ofc somewhat defeats the point of using it, but it is a useful pattern to slowly move away from it, when encountering it in legacy projects.
  - lolive 1y ago
    Reinventing XML traversal/transformation in JavaScript will lead really fast into abstracting away the recursive tree traversal, then mapping node marchers to functions. Which is 99% what XSLT provides off the shelf.
    - Quarrelsome 1y ago
      many developers just want to have some space to do some extra logic and XSLT doesn't really accommodate for that. You have to deal with the input and create the output without pausing for breath. While this is fine in simple use-cases where the mapping is 1-1 but when the mapping gets more complicated then it becomes difficult to maintain.
      - willseth 1y ago
        That’s simply not true. Certainly it can be hard to wrap your head around architecting complex logic in XSLT 1.0, but it's not unlike how you have to change your thinking for functional programming generally. More ergonomic imperative logic and several other features in XSLT 2.0 made it a much more developer friendly language.
leptons 1y ago
>No mention of XSLT? Nope, but they sure had to make 1/2 the content about "AI" (otherwise nobody would read it?).
HellsMaddy 1y ago
My first exposure to XSLT was sketchers.com: https://thedailywtf.com/articles/Sketchy-Skecherscom https://thedailywtf.com/articles/Sketchy-Skecherscom Sadly it doesn't seem like they're using it anymore.
- donkeybeer 1y ago
  The example looks very minimal and neat by modern standards, shows how much messier modern websites are, I had to even think where is the "wtf".
judell 1y ago
I wrestled with how much history to bring into this because I want to look forward not back. The purpose of the announcement is to encourage people to try the tool and find out for themselves if it is a productive way to build the user interfaces they need.
bjoli 1y ago
When I discovered oleh kiselyov's SXML/SSAX. It is such a amazing way to work with xml that I simply stopped doing xslt all together. SSAX is probably the best xml parser I have ever used.
shanghaikid 1y ago
I remember Blizzard games' website were built by XSLT before, those websites were impressive.
stmw 1y ago
To use XSLT effectively, you need an intuitive understanding of functional programming, a good grip on low-level HTML5/CSS details, and an engine that can run it quickly and correctly. The first of these is very rare, especially among business programmers. It is about as far away from the "Visual Basic-inspired" design goals of XMLUI as possible. Yes, both involve XML but that's where the similar ends.

danielvaughn 1y ago

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.

A4ET8a8uTh0_v2 1y ago
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.
- danielvaughn 1y ago
  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.
  - toyg 1y ago
    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.
    - int_19h 1y ago
      I don't think it was ever "purged" - I mean, which modern browser doesn't handle XSLT 1.0? Nor did the spec itself stop evolving. The problem is that the browsers have deprecated the technology before XSLT 2+ could be adopted.
      - toyg 1y ago
        > which modern browser doesn't handle XSLT 1.0? 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).
  - willseth 1y ago
    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.

sheepscreek 1y ago

The performance of available XSLT translation engines would be a big consideration for me, especially in a hot-reload context to support fast iterations.

thechao 1y ago
That was my first thought: no XSLT 3 engine that I know of keeps an in-memory object that supports iterative retemplating on diff changes to the source. I think the closest to this is in the functional communities and their lenses. Given how "far" XSLT can reach through a document via Xpath, I don't think it's an easy-to-solve problem.

homarp 1y ago

if the target audience is 'citizen developer', aka Visual Basic (classic), I am not sure introducing XSLT is such a good idea.

majewsky 1y ago

Every time I've seen XSLT deployed, it was "that one hairball that no one besides the original author dares to touch". I'm not sure what it is about the technology, but it seems to either inevitably desolve into a complex mess or attract complexity fetishists. Either way, not something that would be an obvious choice for what OP is going for.

Quarrelsome 1y ago
its because it demands to everything to be effectively processed in a one liner and is locked into its early version due to a licensing failure (I've yet to work in an org that pays up). So if you work in XSLT, then you're stuck in 1999. IMHO the pattern to improve XSLT is to call out into more useful languages like javascript, which ofc somewhat defeats the point of using it, but it is a useful pattern to slowly move away from it, when encountering it in legacy projects.
- lolive 1y ago
  Reinventing XML traversal/transformation in JavaScript will lead really fast into abstracting away the recursive tree traversal, then mapping node marchers to functions. Which is 99% what XSLT provides off the shelf.
  - Quarrelsome 1y ago
    many developers just want to have some space to do some extra logic and XSLT doesn't really accommodate for that. You have to deal with the input and create the output without pausing for breath. While this is fine in simple use-cases where the mapping is 1-1 but when the mapping gets more complicated then it becomes difficult to maintain.
    - willseth 1y ago
      That’s simply not true. Certainly it can be hard to wrap your head around architecting complex logic in XSLT 1.0, but it's not unlike how you have to change your thinking for functional programming generally. More ergonomic imperative logic and several other features in XSLT 2.0 made it a much more developer friendly language.

leptons 1y ago

>No mention of XSLT? Nope, but they sure had to make 1/2 the content about "AI" (otherwise nobody would read it?).

HellsMaddy 1y ago

My first exposure to XSLT was sketchers.com: https://thedailywtf.com/articles/Sketchy-Skecherscom https://thedailywtf.com/articles/Sketchy-Skecherscom Sadly it doesn't seem like they're using it anymore.

donkeybeer 1y ago
The example looks very minimal and neat by modern standards, shows how much messier modern websites are, I had to even think where is the "wtf".

judell 1y ago

I wrestled with how much history to bring into this because I want to look forward not back. The purpose of the announcement is to encourage people to try the tool and find out for themselves if it is a productive way to build the user interfaces they need.

bjoli 1y ago

When I discovered oleh kiselyov's SXML/SSAX. It is such a amazing way to work with xml that I simply stopped doing xslt all together. SSAX is probably the best xml parser I have ever used.

shanghaikid 1y ago

I remember Blizzard games' website were built by XSLT before, those websites were impressive.

stmw 1y ago

To use XSLT effectively, you need an intuitive understanding of functional programming, a good grip on low-level HTML5/CSS details, and an engine that can run it quickly and correctly. The first of these is very rare, especially among business programmers. It is about as far away from the "Visual Basic-inspired" design goals of XMLUI as possible. Yes, both involve XML but that's where the similar ends.