Feature #3589


Saxon-JS should depend only upon JavaScript, not web browsers

Added by Kenneth Hughes over 6 years ago. Updated about 4 years ago.

Build and Release
Start date:
Due date:
% Done:


Estimated time:
Applies to JS Branch:
Fix Committed on JS Branch:
Fixed in JS Release:
SEF Generated with:
Contact person:
Additional contact persons:


As a developer and consultant, I wish to deliver XSLT 2.0+ and XSD 1.1 solutions to customers and clients via JavaScript.


Node.js interest and adoption have reached noteworthy levels among enterprise customers.

  • It is easier to introduce XSLT and other Saxon XML solutions into an organization that has adopted Node.js when a pure, full JavaScript implementation of those solutions is available.

  • Architectural design of solution systems is simplified when a new platform (Java or .NET) needn't be introduced just for XML technology.


As an aficionado of functional, declarative, and rule-based paradigms, I would love to develop for my clients in Lisp or any number of non-imperative languages that are unfortunately permanently niche-bound now. Similarly, I see technical merit to Saxonica's Saxon-CE and (current) Saxon-JS design decisions in the browser. However, socially it is simply not happening: General UIs are not being written in XSLT in the browser and never will be to any significant extent in production settings.

Where XSLT still could offer value in the browser is in the delivery of local, platform-independent checking and transformation of XML documents. No event processing model. No reliance on browser vendor support for proper parsing or serialization. Just pure W3C standards adherence, implemented in JavaScript so it can be distributed to and run by clients without installation.

Web app GUIs can be written via many strong frameworks atop JavaScript in the browser. Saxon-JS can't compete in that arena. Saxon-JS can compete and win by delivering the real strength of XSLT, XML-to-XML transformation, to the edges of the network:

  • Work is offloaded from central servers, reducing performance bottlenecks and processing costs.

  • Sensitive data need never leave customer premises.

  • Network bandwidth usage is reduced when the size of the data being transformed greatly exceeds the size of the XSLT code and libraries (yes, including parsing and serializing components).

Please register to edit this issue

Also available in: Atom PDF Tracking page