Fix for LinkeDOM compatibility: don't rely on live collections

[eordano]

This allows @mozilla/readability to work with LinkeDOM, an alternative to jsdom that is much faster, has a smaller RAM footprint, and uses less dependencies (4 vs 96).

It's intended as a drop-in replacement for jsdom, but when trying to use it with readability, I stumbled into one small issue with a cached instance of childNodes. This new lib, LinkeDOM, does not update cached instances, so there is an incompatibility with how Readability.js accesses the DOM. This practice of using childNodes as both a node of a tree, with the expectations and side effects of modifying the tree indirectly, and also as an Array, sounds like 1990's JavaScript -- it feels awkward to use it nowadays.

More info here: WebReflection/linkedom#43

[gijsk]

Thanks for the PR.

It's intended as a drop-in replacement for jsdom, but when trying to use it with readability, I stumbled into one small issue with a cached instance of childNodes.

I somewhat suspect you'll have more issues with more complex documents, but I guess it's hard to know either way until we take this PR and you try to actually use things in the wild.

This new lib, LinkeDOM, does not update cached instances, so there is an incompatibility with how Readability.js accesses the DOM. This practice of using childNodes as both a node of a tree, with the expectations and side effects of modifying the tree indirectly, and also as an Array

It seems like implementing support differently to what the spec says is likely to lead to web compat issues all over the place. For instance, it sounds like the implementation also violates the spec in terms of not always returning the same object when accessing .childNodes (indicated in the DOM spec by the [SameObject] annotation for the idl definition of the property). I guess that's a trade-off the LinkeDOM folks are making, and perhaps it depends on whether you run web page scripts or not...

[eordano]

Yes, you raise very valid points! FWIW, I'm merely a user of LinkeDOM. I patched this into readability and have not found yet other caveats with the small set of websites I tried it on.

I guess this is something they might have to reconsider in the future; but it sits in the fine line between being backwards compatible and using an API that barely survived the passage of time because it was super sticky, conditioned implementations to strictly abide by it, and just "good enough" to avoid replacement.

Thank you for accepting the PR!

[WebReflection]

I guess that's a trade-off the LinkeDOM folks are making

Yup, no intention in bringing in legacy behaviors or things with practical zero usefulness (such as el.childNodes === el.childNodes) but I'm updating the FAQ section to avoid surprises

and perhaps it depends on whether you run web page scripts or not...

Also no use case for that ... no intention to become as bloated as JSDOM is 'cause there's already JSDOM for that ;-)

LinkeDOM has MutationObserver and full Custom Elements V1 API but that was already a stretch over its main use case.

Anyway, on a quick look, there shouldn't be major issues with your current code, but happy to fix anything crucial that diverges too much from the standard, and thanks from me too for accepting this MR 👋