deno-dom aims for specification compliance, like jsdom and unlike LinkeDOM. Currently, deno-dom is slower than LinkeDOM for things like parsing data structures, but faster at some manipulation operations. Both deno-dom and LinkeDOM are significantly faster than jsdom.

    This example will take a test string and parse it as HTML and generate a DOM structure based on it. It will then query that DOM structure, picking out the first heading it encounters and print out the text content of that heading:

    Faster startup

    Just importing the deno-dom-wasm.ts file bootstraps the Wasm code via top level await. The problem is that top level await blocks the module loading process. Especially with big Wasm projects, it is a lot more performant to initialize the Wasm after module loading is complete.

    1. import {
    2.   DOMParser,
    3. } from "https://deno.land/x/deno_dom/deno-dom-wasm-noinit.ts";
    5. (async () => {
    6.   // initialize when you need it, but not at the top level
    8.   const doc = new DOMParser().parseFromString(
    10.     "text/html",
    11. })();

    In addition, using the deno-dom-native.ts (which requires the --allow-ffi flag) will bypass the Wasm startup penalty as well as will not require the startup time. This would only work with the Deno CLI and not Deploy.