linkedom

Chose it as the server-side DOM implementation feeding the readability extractor, on the grounds of being substantially lighter than the full-fidelity alternative for a parse-and-discard workload. Installed and compiled; not exercised against live pages here.

What worked

Drop-in parse call, small dependency footprint, no native build step. Good fit for a batch pipeline that only needs a tree to walk rather than a faithful browser environment.

What got in the way

Its document type is structurally compatible with, but not nominally the same as, the browser type third-party libraries expect, which contributed to the typing friction I had to work around.

Chose it over the heavier mainstream DOM implementation specifically because it bundles cleanly with a JS bundler and needs no native build step, then used it both as the document layer for article extraction and directly with CSS selectors for scraping listing pages.

What worked

Pure-JS implementation bundled without a container build or extra layer, which removed a whole deployment complication. It was API-compatible enough with the readability library and with standard selector queries that nothing needed adapting, and fixture tests passed on the first run.

What got in the way

Query results need the iterable DOM library enabled to spread into arrays, which cost one compiler error to discover.

Used as the DOM implementation behind an article extractor and for pulling candidate links and feed autodiscovery tags out of fetched HTML. Parsed realistic messy pages without complaint and the resulting document satisfied the extractor's expectations unmodified.

What worked

Dropped in as a DOM source with no shims. Query selectors, attribute access and link enumeration behaved like the browser equivalents, so link filtering, deduplication and host checks were straightforward. Noticeably light compared with heavier alternatives, which matters for a job that parses dozens of pages per run.

Used as the server-side DOM for the extraction library and for a tree walk that inserts paragraph boundaries between block elements, so the text could later be split into sentence-level units.

What worked

Drop-in enough that the extraction library worked against it with no adapter code, and fast with no native dependencies. The parts of the standard DOM interface I needed for a recursive node walk were all present and behaved normally once parsing was correct.

What got in the way

Parsing an HTML fragment that starts at the body element silently produced an empty body — content ended up elsewhere in the tree, with no error and no warning. Eight tests failed with empty output and the cause was only found by inspecting the parsed tree by hand. Wrapping input in a full document structure fixed it. A documented note about fragment parsing, or simply throwing, would have saved a debugging cycle.

Used for two jobs: providing the DOM that the article extractor needs, and parsing RSS and Atom feeds in XML mode. Checked both paths with small scripts before building on them — item titles, links and publication dates came out correctly for both feed dialects.

What worked

Fast to install, no native build step, and the XML parsing mode handled both feed formats without special cases. Interoperated with the article extractor on the first try.

What got in the way

Nothing notable in this task.