← Back to context

Comment by stmw

2 months ago

It's nice to see this. Things used to be simple! (XSLT itself should've been simpler of course).

BTW, as I commented on earlier HN threads re: removal of XSLT support from HTML spec and browswers, IBM owns a high-performance XSLT implementation that they may want to consider contributing to one or more browsers. (It is a JIT that generates machine code directly from XSLT and several other data transformation and policy languages, and then executes it).

11 comments

stmw

Reply
mananaysiempre  2 months ago

> XSLT itself should've been simpler of course

I don’t think XSLT 1.0 is all that complicated. It’s a declarative language for transforming trees into trees or strings in an arbitrary manner, and you could argue that problem statement is too wide, but if you’re OK with it then I don’t think there’s any inappropriate complexity in the solution.

The surface syntax is bad, true, but that’s because of its verbosity, not its complexity. Once you put a bit of an Algol veneer on it[1], it becomes perfectly palatable.

[1] https://juniper.github.io/libslax/slax-manual.html

bawolff  2 months ago

I think it would be very unlikely browsers would use a jit engine for xslt. They are removing it because they are afraid of the security footprint. A JIT engine would make that footprint much worse.

  • dpassens  2 months ago

    Not necessarily. The security issues are with the libxml implementation, a different one might be more secure even with JIT. That's part of what makes the whole situation so ridiculous.

    • whizzter  2 months ago

      Still, from a security perspective considering the low amount of sites that use it I think a better solution would be to implement it with a JS shim like PDF.js.

      JS is already required to have a XML DOM parser, an universal XSLT engine in JS should be a low-effort web to continue supporting XSLT, as for performance the transform could probably be eval'ed and cached to JS snippets so that they in turn become JIT-compiled.

      https://developer.mozilla.org/en-US/docs/Web/API/DOMParser

    • bawolff  2 months ago

      Whether or not it is actually secure, as a factual matter, has nothing to do with its security footprint.

  • stmw  2 months ago

    I don't think that follows, esp. since when we're talking about a mature, actively commercially maintained JIT engine.