jsdom vs happy-dom

[cfife-btig]

Hi there, I'm not sure if this is the place to ask this, but I'm a little confused by how there seems to be two different engines for rendering the dom, happy-dom and jsdom. Could someone share why some of the vitest examples seem to have both and roughly what their differences are?

[sheremet-va]

happy-dom is a faster alternative, but it doesn't have some Web APIs. jsdom is more mature package.

[vhscom]

@knownasilya Could you share what specific bug or bugs you experienced that where the deal breaker?

[knownasilya]

capricorn86/happy-dom#1079
capricorn86/happy-dom#1181

Plus others I'm sure, but I moved back to jsdom after those two. Seems less spread out maintenance wise (one main maintainer).

[ghost]

I had this weird bug with happy-dom while doing el.replaceChild(newNode, el.childNodes[index]). Even though el had childNodes, it was throwing error that Node to be inserted before is not the child of element.

With jsdom, it was not erroring out.

[samal-rasmussen]

capricorn86/happy-dom#1079
capricorn86/happy-dom#1181

Both of those issues are resolved and a lot of other feature implemented since. Lots of activity recently and consistently. The happy-dom dev seems super effective.

[ItamarGronich]

For more complex projects, jsdom is amazing but a bit slower.

@belgattitude jsdom can't submit forms....
jsdom/jsdom#1937

[mindplay-dk]

I think a lot of us wish for a more lightweight DOM mock for quick unit tests.

I was quite excited about undom but ran into various problems using that as well.

I'm afraid, at this time, jsdom remain the devil you know.

You wouldn't think it'd be all that difficult to replicate just the most essential DOM features in a more lightweight way - just a simpler package, with a smaller scope, without mocking the entire browser, but still accurate to the specs.

But I dunno... the DOM specs are awful complex. 🤔