Benchmark: Is in the dom - MeasureThat.net

HTML Preparation code:

<div id="test-div"></div>

Script Preparation code:

const el = document.getElementById('test-div')

function isDom1(){
 return document.contains(el)
}

function isDom2(){
  const {display} = window.getComputedStyle(el);
  return !display || display !== 'none'
}

Tests:

Test 1
isDom1()
Test 2
isDom2()

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Test 1
Test 2

Fastest: N/A

Slowest: N/A

Latest run results:

No previous run results

This benchmark does not have any results yet. Be the first one to run it!

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):

LLMs can make mistakes. Check important info.

I'd be happy to explain the benchmark.

**What is being tested?**

The benchmark measures the performance of two functions, `isDom1()` and `isDom2()`, which check if an element with the id "test-div" exists in the DOM (Document Object Model) of a web page. The element is created using HTML code that is prepared by the user.

**Options being compared**

The benchmark compares the performance of two approaches to check if an element exists in the DOM:

1. **`document.contains(el)`**: This method checks if the `el` element (the "test-div" element) is a child of any ancestor node in the document tree.
2. **`window.getComputedStyle(el).display !== 'none'`**: This method uses the `getComputedStyle()` function to get the computed style of the `el` element and checks if its `display` property is not equal to `'none'`. If it's `'none'`, it means the element is hidden, so this approach will return false.

**Pros and cons of each approach**

1. **`document.contains(el)`**:
	* Pros: Simple, fast, and reliable.
	* Cons: It can be slower than `window.getComputedStyle(el).display !== 'none'` because it needs to traverse the document tree to find the ancestor node that contains the element.
2. **`window.getComputedStyle(el).display !== 'none'`**:
	* Pros: Faster because it only needs to access the computed style of the element, which is a cached value in modern browsers.
	* Cons: May return false if the element's `display` property is set to `'none'` using CSS styles (e.g., `visibility: hidden; display: none`). This can lead to incorrect results.

**Library usage**

There is no explicit library used in this benchmark. However, it's worth noting that `window.getComputedStyle()` is a standardized method for accessing an element's computed style, and most modern browsers implement it correctly.

**Special JS features or syntax**

This benchmark does not use any special JavaScript features or syntax, such as async/await, promises, or newer ECMAScript standards like arrow functions or let/catch blocks. The code is straightforward and easy to understand.

**Other alternatives**

If you were to reimplement this benchmark, you could consider the following alternative approaches:

* Using a library like `dompurify` or `jsdom` to create a simulated DOM environment for testing.
* Implementing a custom DOM traversal algorithm to compare the performance of different methods for checking if an element exists in the document tree.
* Using a different approach altogether, such as using CSS selectors to select the element and then checking its visibility.

However, these alternatives might not be necessary, and the current implementation is already quite straightforward and easy to understand.

Related benchmarks:

Is in the dom (version: 0)

Comparing performance of: Test 1 vs Test 2

Created: 3 years ago by: Guest

Jump to the latest result

Test 1

Test 2

Suite status: <idle, ready to run>

Fastest: N/A

Slowest: N/A

No previous run results

Autogenerated LLM Summary (model llama3.2:3b, generated one year ago):