The ultimate reason we do not use XSL is that we need lightweight, incremental transformations. Unfortunately, that is something the in-browser XSLT implementations do not give us.

Furthermore, I think it is fair to say we use these combinators not for templating, but rather for reactive transformations. The syntax may look sub-optimal (which it certainly is), but the fact that it is pure javascript makes it really expressive.

Also, are you saying you’ve dropped XSL as a template language altogether and moved forward/backward to writing HTML using the above functions? That would seem like a step backward to me: I can still sense the bad taste in my mouth of my first Perl scripts and the sweetness when I ‘invented’ templating (and later when Lon introduced me to XML/XSL).

Nicely written article. Thanks for the inspiration.

Very sharp, this is indeed a typo! Thanks for this notification. In this example the `deep’ combinator can only take one argument.

Another way to write it down is to put an additional seq inside the `deep’:
var toc = mkElem(“ul”)(seq(deep(seq(isHeader, mkElem(“li”))(self))));

seems to be
var toc = mkElem(“ul”)(seq(deep(isHeader), mkElem(“li”)(self)));

Yes, this is exactly what we have done! Because the underlying semantics are very clean rebuilding it was very easy. These combinators for themselves have no big advantage over XPath of course, but now that we have our own implementation in JavaScript extending (in multiple dimensions) becomes very easy.

The reason for this post was showing other programmers that looking at the semantics of an existing system can change it from some black box magic into something simple and understandable. There was never an intention to present something that on itself could ever supersede XPath/XSLT.

Thanks for keeping XSLT functional!

This of course was always one of the major justifications for making XSLT/XPath a functional language.

It seems to me that all you have done is to strip off the syntactic sugar offered by the XPath syntax and expose the underlying functional semantics.