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