[00:00:00]

>> Evgenii Ray: So what is the DOM API? So the DOM API is a set of methods that we
can utilize to manipulate a DOM. And usually, we don't use it directly because most
of the libraries are handling the DOM mutations for us, for instance, React,
Angular or Vue. But there are cases where we actually need to use the DOM API.

[00:00:21]
And one of that is when you're building some low-level library that works with
virtualization or some DOM management. Also, it's used when you need to create some
generic components that can be ported to any library or framework. It can be a
video player or a chart engine. And also, for instance, you are building your
portfolio website, and you want to minimize the blueprint of your application by
not importing too many libraries.

[00:00:51]
So this way you can just use the DOM API and your app will be lightweight. So this
section will give us a quick refresher on how to use the DOM API. So first, let's
overview the objects that are available to us and how can we use the DOM API?

[00:01:11]
So the first global object that we are all aware of is the window. The window is
the globally accessible object, so you don't need to import anything. The next one
is the document, the document who presents HTML Element, basically, the page that
we're currently rendering. And the document can be accessed for the Window or
directly by referencing this as a Global Object.

[00:01:40]
Then we have some quick access links that we can use on the Document. It's a body
and head gives us the body check and head respectively. Now let's go for the Class
Hierarchy. All the elements on the HTML page are represented by HTMLElement. But
apparently the HTMLElement doesn't have any DOM API assigned to that.

[00:02:06]
The DOM API is actually assigned to the element prototype. So why is that? Because
the DOM API can actually work not with just HTML. So it can be also SVG elements or
XML-like things. That's why the DOM API lives on the element prototype instead of
HTMLElement. And we also have the Node.

[00:02:29]
The DOM is a tree and somehow, we need to access the tree properties. So that's why
we have a special class that's designed to represent a tree leaf, and this is the
Node. And we have exception, which is a TextNode, which basically extends the Node
plus. The TextNode is used when we use any text, then we need to wrap our text in
the HTMLElement.

[00:02:54]
So the browser needs to somehow to represent the text that we place in our in our
text. Then we have the HTMLDocument and HTMLDocument is outlier here because it has
the DOM API assigned to its prototype, but it extends the Node. I don't know the
reason why, but this is the exception in the whole hierarchy that we need to live
with.

[00:03:17]
And the next one is the Window. Basically, the Window has an instance of
HTMLDocument and it doesn't have any interesting properties on its prototype, so it
presents the Browser Viewport. Query methods, let's now understand how the browser
queries elements on a page, how the DOM API queries the elements.

[00:03:37]
So let's have first the most simple method, which is getElementByID. So when the
browser reads the page, it constructs the Hashmap of the elements. So it reads the
ID, and then it basically builds the cache where the ID is assigned to some HTML
reference. So this means that when we try to getElementByID the Time Complexity and
Read Costs is just O (1).

[00:04:05]
Because this is just basically accessing the object by its key. The situation is
slightly different when it comes to getElementsByClassName. So to
getElementsByClassName we need to actually traverse the whole tree, and the way the
browser traverse a tree it's use the DFS approach. So it basically goes through the
elements and finds all the all the elements on a page with the class text.

[00:04:36]
And the Time Complexity for this is linear, so we need to go for all elements in
the worst case, but you see there is a star here. This is because the browser is
quite smart, and it utilizes the Hashmap when you try to query things. So the first
query will take some time, but if you execute the same query next time, it will be
almost immediately because browser utilizes the caching mechanism.

[00:05:04]
And one thing about this method is also to trans the HTMLCollection. An
HTMLCollection is actually a legacy Collection which has one interesting
characteristic, it's life. So this means that if we modify the DOM Tree, and, for
instance, remove one element from the DOM, this will be reflected on our
HTMLCollection.

[00:05:30]
And that's why the Read Cost of the HTMLCollection is big O(N) and because every
time we need to read a single element, the browser will parse the tree again to
verify its position. So this is a disadvantage of this thing. But on the other
hand, the memory cost is low because the browser doesn't need to clone any objects,
it just takes the already existing references.

[00:06:00]
So you can utilize the HTMLCollection when you're low on memory and you need to use
as less memory as possible. Okay, the same way works the getElementByTagName. So
there is no difference at all, it allows us to query things by detect. So the
querySelector works slightly different. So it utilizes the CSS selector, so the
time complexity depends on the selector that we use.

[00:06:34]
So we always space some text on compiling the selector. So this means that the more
complex selector you have, the more time it takes to compile it for CSS. So the
read access and the Memory Cost is big O (1) because we're just returning the
single element. And the querying mechanism when we try to use the class names or
the text, it's the same as the DFS.

[00:07:04]
If we use the ID, then we gonna convert this statement to getElementByID instead.
So one interesting thing about the querySelector, and this is the querySelectorAll,
is because it returns the NodeList. The NodeList is not a type of collection, but
it's not life, it's just basically the copy of the elements.

[00:07:25]
So what the browser does it just copies the HTML objects. And this means that we
pay additional memory costs when we do the querying. So it's not advisable to query
too many things because you may end up having the memory spike. But the read access
is O(1) because you're just accessing the object directly from the array instead of
traversing the tree again by maintaining the life collection.

[00:07:51]
And the querying mechanism is the same, DFS plus Hashmap. Quick summary, so the
getElementsByID provide the best performance because the browser builds the cache.
But you need to make sure that you utilize the ID space correctly. So it's
basically apparent to you to rely on the IDs too much, because the ID name space is
shared across your multiple components and just make sure that you don't overuse
IDs in your app.

[00:08:23]
The getElementsByClassName or getElementsByTagName, provide a low memory overhead
because it returns to live collection with just references to existing objects. But
because the read access is high, so you need to make sure that you utilize this
collection right. Because if you're going to loop for this collection, yes, it will
convert to quadratic time.

[00:08:50]
And we don't want to do that in our app on the largest set of elements. The
querySelector have slightly worse performance than getElementByID. But the browser
itself heavily optimize any CSS selectors. So in different browsers, you may get
different results, but on average, it's very close actually to getElementByID.

[00:09:13]
But the elements that are returned from this query do not represent the live
collections. So if you remove the element from the DOM Tree, you may end up having
the stale element in your in your collection. Yeah, the same applies to the
querySelectorAll, but because it copies all the elements, you don't want to query
too many elements with this method.

[00:09:39]

>> Speaker 2: Could you clarify the difference between the time complexity of
querying versus the read cost?
>> Evgenii Ray: Yeah, okay. So if we'll go back to getElementsByTagName, for
instance. So the time complexity it takes to go through the elements, to find all
the elements that we are looking for is big O(N) because we need to go through all
elements in the worst case.

[00:10:06]
But the read cost is also big O(N) because we maintain the live collection. And
when we maintain a live collection, this means the browser needs to verify that the
element exists in the DOM Tree. So every time you're trying to access this live
collection, the browser queries the elements again to verify that the element is
still present.

[00:10:30]
That's why it can result to the Time Complexity, in the worst case, we'll need to
parse all elements again.
>> Speaker 3: Is there a reason the querySelectorAll returns to non-live element
lists compared to this one, for example, comparing or returning the live?
>> Evgenii Ray: So the live collection is actually legacy one, it's not recommended
to use for normal cases.

[00:10:59]
And I guess the querySelector returns non-live collection because we needed to have
some alternatives. The live collection has more drawbacks and if not used wisely,
can lead to more issues. But in our application development, we don't really need
to manage the live collections, and for most of the developers, the
querySelectories the better go because it doesn't have the expensive read access.

[00:11:27]

>> Speaker 2: Why would querySelectorAll impact memory while returning references
to Nodes which already exist in the DOM?
>> Evgenii Ray: Not exactly, we actually return the copies. Basically, the browser
creates a new object with the same values and the copies, and when you change the
properties of these objects, it will impact the original object.

[00:11:56]
But we have two separate objects basically, with the same properties and they're
connected with each other for the proxy mechanism. So it's a slightly different,
when we use the live collection, we actually guarantee we can actually reuse the
real reference to the object instead.
>> Speaker 2: When you're saying that the cache would make things faster next time,
are you always sure about that because class names can be dynamic?

[00:12:28]

>> Evgenii Ray: So you can't control that because it's up to the browser engine.
The same query methods can behave differently in Safari or Chrome depending on how
developers optimize that. For instance, Safari browser uses the WebAssembly
compilation for the native selectors, while the Chrome doesn't use that. Because
they find that the performance of existing querySelectors is fine on average.

[00:12:56]
So you can't guarantee the same results, and it's up to the engine. So the logic of
caching the querySelector is quite complex, and yeah, no guarantee [LAUGH].