4 ms·
It's interesting that we don't have a replacement for this use case. For me, XSLT hits a sweet spot where I can send a machine-parsable XML document and a small
by 8organicbits 11mo ago
It's interesting that we don't have a replacement for this use case. For me, XSLT hits a sweet spot where I can send a machine-parsable XML document and a small XSLT sheet from dirt cheap static web hosting (where I cannot perform server-side transforms, or control HTTP headers). This is fairly minimal and avoids needing to keep multiple files in sync.
I could add a polyfill, but that adds multiple MB, making this approach heavyweight.
- crazygringo 11mo agoMultiple MB? I'm looking at: https://github.com/mfreed7/xslt_polyfill https://github.com/mfreed7/xslt_polyfill Which uses: https://github.com/DesignLiquido/xslt-processor/tree/main https://github.com/DesignLiquido/xslt-processor/tree/main But they don't look that heavy. Am I missing something? Megabytes of JS would be enormous.
- svieira 11mo ago> The implementation is all agnostic about namespaces. It just expects XSLT elements to have tags that carry the xsl: prefix, but we disregard all namespace declaration for them. Just for a start. It's a tiny polyfill for a tiny subset of the thing that is XSLT 1.0.
- 8organicbits 11mo agoxslt-polyfill.min.js is 1.3 MB on its own https://github.com/mfreed7/xslt_polyfill/blob/main/xslt-polyfill.min.js https://github.com/mfreed7/xslt_polyfill/blob/main/xslt-poly...
- crazygringo 11mo agoI see, thank you -- so it's not the JavaScript part, it's basically 99% a huge WASM blob. I can understand not wanting to include something like that, yikes.