Using XSLT 2.0 as a Web Scripting Language

Stunning JavaScript implementation suggests more is possible

A language built to support event handling, not strictly a functional programming language but fitting that mold. A deep understanding of markup structures. A home in the browser.

That’s JavaScript, all right—but now, thanks to JavaScript, it is also XSLT. After all the discussion I heard about templates and JavaScript at Fluent and OSCON, starting with a language built on templates seems like a better and better option.

Thursday afternoon at Balisage, O’Neil Delpratt and Michael Kay discussed Interactive XSLT [2.0] in the browser, showing not just the usual transformations but a working engine for a graphical interface. Their earlier XML Prague paper also tells the story and shows more code detail, including a chess game.

The Saxon-CE project page, in addition to pointing to a GitHub repo and identifying the open source (MPL) license, links to the documentation. In properly recursive style, that documentation itself uses Saxon-CE to display its content. There’s also a simpler books application.


Interactive XSLT demo selecting books.

The demos themselves are pretty normal Dynamic HTML work, but they don’t use the usual JavaScript, and they aren’t making piles of Ajax calls to a server in the background. They don’t just generate with XSLT and then script with JavaScript, as was true of most earlier uses of XSLT in the browser. Instead, the JavaScript facilitates the use of XSLT logic. The XSLT defines and supports interactivity in the applications. They load the data up front, responding to events that happen to nodes in the document by transforming content and putting the results in the DOM tree. Delpratt disconnected his wireless to demonstrate its independence.

I need to take a much closer look at the details of this, especially performance. It uses a subset of XSLT 2.0, notably without XML Schema. It’s built using GWT, which Kay said bound it to the client-side world of browsers, but it may be possible to use it on the server side with Node.

Kay described the mechanisms for interactivity:

The development style is different. You start with an HTML skeleton and populate it with different style sheets. You can change those sections in response to an event.

I’m very happy to see that this isn’t regenerating the entire page. After years of dealing with JavaScript event handlers, though, I want to take a very careful look at how this works in XSLT. I’m also curious about the potential for handling concurrent processing, though Kay warned that “We don’t make an effort to handle concurrency better than JavaScript handles it.”

A questioner asked if this would also work with graphics, particular SVG. Kay admitted his surprise to be using XSLT as a graphics programming language. (Via Twitter, here’s a demo with SVG graphics from @XMLArbyter as well.)

Personally, this completes a circle for me. XSLT, when I finally applied it to large enough (and appropriate) problems, taught me to think about data flows, and broke me of the expectation that variables were changeable. That made it easier for me to work with Erlang and shift to functional programming. That made me re-examine how I used JavaScript, and made a lot of things I’d done “because I was supposed to” make sense.

Now I get to play with XSLT, in a JavaScript context. I didn’t see that coming.

(And even if you don’t like XSLT, hopefully the mere fact that this works gives you more ideas.)


Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Web Platform
  • Simon St.Laurent

    A small update. I woke up this morning wondering whether this use of XSLT could handle asychronous processing, as all the XSLT I’ve ever done was effectively batch processing.

    Fortunately, they thought about that before I did, and I found this in the XML Prague paper: “The use of ixsl:schedule-action here is not so much to force a delay, as to cause the search to proceed asynchronously. This ensures that the browser remains responsive to user input while the search is in progress.”

    Much good stuff, with a reasonably minimal set of extension functions.

  • sivanm

    Having worked extensively with XSLT early in my career deeply affected the way I program and I’m thankful for it. In particular, the propensity to frame problems as data transformation pipelines, comfort with immutability and recursion (often required in XSLT1.0), all have paid off many times.

  • Jean Kaplansky

    Simon – Did you see the recent Google blink-dev post stating the intent to deprecate and remove XSLT from Blink?:!topic/blink-dev/zIg2KC7PyH0

    I was surprised to see very little opposition to the post.

    Do you think this is going to be a trend in browser engines going forward?

    Any other comments?

    Thanks for your thoughts.

    • Simon St.Laurent

      The bad news is that such deprecations make XSLT look, well deprecated and removed.

      The good news is that this XSLT approach uses JavaScript, so doesn’t need that support. It also can do things – in particular responding to events – that the built-in XSLT isn’t really set up to do.

      It’s a very tricky time. I’m not sure whether to be an optimist or a pessimist.

      • Jean Kaplansky

        Thanks for your input. I’ve been trying to make heads or tails of the “we should deprecate this/that” attitude that I’m starting to see in the browser vendor community. An XSLT approach that uses JavaScript outside the browser itself is definitely a good thing!

      • piers_hollott

        I’ve been working with an approach that combines Saxon-CE and AngularJS, where Angular provides the MV* pattern, services architecture, and data-binding for JSON payloads and Saxon-CE allows you to do much more expressive templating and interaction if you have XML payload. Angular makes sense of JavaScript scoping nicely, and Saxon-CE obscures it a bit by creating new scope whenever you do something interactive. Combining the two forces you to remember to do things the smart way with CSS.

        There’s a sweet spot in there somewhere. Underneath it all, you still have JavaScript event-handling, and that probably creates a problem when you start to mix frameworks.