Hacker News Reader

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.

View on HN

Multiple MB?

I'm looking at: https://github.com/mfreed7/xslt_polyfill

Which uses: 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.

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

xslt-polyfill.min.js is 1.3 MB on its own

https://github.com/mfreed7/xslt_polyfill/blob/main/xslt-poly...

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

Reply on news.ycombinator.com