Feature #3589
closedSaxon-JS should depend only upon JavaScript, not web browsers
0%
Description
As a developer and consultant, I wish to deliver XSLT 2.0+ and XSD 1.1 solutions to customers and clients via JavaScript.
Server-side¶
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.
Client-side¶
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).
Updated by Michael Kay almost 7 years ago
Thanks for the feedback. Your thinking is very much in line with our strategic direction. Node.js is a key target for the technology, and to deliver that we need to have a better story on parsing and serialization; but more than that, we need to be able to compile stylesheets within the Javascript environment. To that end we are working on a version of the compiler front-end written in XSLT to make it completely portable.
We also recognize the use case for a client-side configuration in which the event-handling extensions are disabled.
Updated by Michael Kay over 4 years ago
- Description updated (diff)
- Status changed from New to Closed
Fixed with the release of Saxon-JS 2
Updated by Kenneth Hughes over 4 years ago
Excellent news! Congratulations on the major new release, and thank you!
Please register to edit this issue
Also available in: Atom PDF Tracking page