The time is right for a DOM templating API

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.

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.

It's sort of similar to regular pattern-matching, but sadly not built for ergonomics :(

The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)

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.

Can you generate XSLT from s-expressions though? :thinking:

Exhaustiveness is only relevant for the compiler-managed pattern matching of a traditional FP type system, where you need to write an implementation (patterns that will be used at matching usage sites) for everything that your types promise.

XSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful; if some part of the input document is processed several times, it's perfectly well defined.

I get it, but it's hard to track

If by "hard to track" you mean not knowing what template is producing an observed bad output, the modularity of self-contained templates and XPath expression is likely to help with debugging.

The problem here is runtime includes, especially the "drop source in place" style includes, coupled with dynamic dispatch at runtime. These two things in combination make static analysis of execution flow anywhere from really hard to impossible

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.

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".