Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.



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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: