I love the pragmatic pointer of using `querySelector()` for muscle memory, rather than getElementById() for the negligible performance difference. Not 100% where I found it, but for looping over a NodeList I've been doing: ```js Array.prototype.forEach.call(listOfNodes, (elem) => { }); ``` Should I give more consideration to the NodeList foreach() method or a for...of loop?
Definitely! What you do was needed a few years back when NodeList.forEach() lacked broad support. Today, it's available in every browser and can be used with the call() hack. That or for...of both work great.
It would be nice to explain the difference between "display:none" and the hidden attribute, because it's not the same thing. Choosing to change the way it's hidden is (I think) outside the scope of converting to vanilla JS. Also, does the use of "for...of" free you of having to check for an empty result from querySelector()?
Functionally, the hidden attribute is identical to display:none;. They literally do the same thing, and for a while, the CSS polyfill for the hidden attribute was [hidden] {display: none;} Which is all to say, we're not really changing anything of importance in this particular case. For extra safety, it is still a good idea to check that something was returned with querySelector(), but in this instance with hard-coded HTML, I chose to skip that check. In a real-world application, I might include it.
Thanks for giving a reason to look it up and find that there's a new value for hidden: "until-found" which means it can be found with in-page search. The docs also say "Web browsers may implement the hidden state using display: none", the key word being "may". I think I was remembering "visibility: hidden", which is quite different from "display: none". My main concern from the docs page is "elements styled display: block will be displayed despite the hidden attribute's presence", because of course CSS overrides attributes, which means it is not good to arbitrarily replace it when converting to plain JS unless you know all the code involved. As for the for loop, who ever writes for hard-coded HTML? Would an empty result from querySelector() cause a problem in the for loop? I have used the for loop technique in other languages to eliminate an if statement.
@@thinkjoyously A few threads to pull at here... [hidden] is a native attribute whose use is preferred over display: none for toggling visibility today. You can override visibility of display: none, too. What you're describing is collisions in app behavior, which is a bigger issue than "which approach to hidings things did I use?" "Which means it is not good to arbitrarily replace it when converting to plain JS" With all due respect, we're not converting some big legacy app here. We're looking a small snippet of example code and exploring how we'd use modern approaches to code it instead. [hidden] is 100% appropriate here. "As for the for loop, who ever writes for hard-coded HTML?" Most websites are pre-rendered HTML, often with the aid of a CMS or static site generator, NOT dynamically generated HTML with JavaScript. And again, this was a teaching video, not a battle-hardened, production ready app. I'm not particularly interested in arguing about minutia in the TH-cam comments.
I usually put 2 functions like this in my code function $(selector, element=document) { return element.querySelector(selector) } function $$(selector, element=document) { return Array.from(element.querySelectorAll(selector)) }
@@gomakethings I always create more little helper functions, depending upon what the project needs, like an empty function, or a set styles function base on an object.
I still love jQuery and still use it. I don't see a noticeable performance gain by not using it. "Because it's old" just doesn't seem to be a good reason not to use it. Most of HTML is "old" too. But I do think it's good to teach new people on vanilla JS first.
Hi Brian - sounds like you're using newish hardware and good internet, then! Ditching jQuery for vanilla JS has big, measurable performance impacts, particularly on older devices and sluggish web connections.
@Go Make Things what is it, 30kb? Even at 7Mps it still downloads in just a few milliseconds. You don't need the latest hardware or superfast broadband to handle it. And it could already be cached in the client. Optimizing images will gain far more performance than avoiding a jquery download. Just sayin'. Chris, I was referring to download performance, e.g. 30kb versus a 2mb hero image. That initial page load is what most users notice and images are the killer there. And the caching I referred to was local, not cdn. But your points are well taken about in-browser performance, I don't dispute that at all. I just think that for most web pages the performance hit is so negligible (20 milliseconds on average, I'm estimating, according to one of those links) that it shouldn't be the primary decision to not use jQuery. I wouldn't use it for Amazon.com, of course. Also, anyone using WordPress has much bigger concerns besides jQuery. 😂 Thanks for the links and responses. General, Yes vanilla is easy. Just not quite as easy as J. Like I said, I definitely advise people to learn vanilla. I just don't see the point in ripping out J and refactoring for vanilla when all you are saving, for most web pages, is a few milliseconds.
@@briankgarland The latest version of jQuery is 285kb after the browser compiles and unminifies it. However, file size alone is only a small fraction of how JavaScript impacts performance. Optimizing images will NOT have a bigger performance impact than reducing your JavaScript usage. That's a myth started years ago that wasn't true then and very much isn't true now. 1kb of JavaScript is substantially worse for performance than 1kb of JPG is. I would encourage you to learn more about web performance, as you're making a lot of statements and assumptions that simply aren't accurate. Links to follow...
I love the pragmatic pointer of using `querySelector()` for muscle memory, rather than getElementById() for the negligible performance difference.
Not 100% where I found it, but for looping over a NodeList I've been doing:
```js
Array.prototype.forEach.call(listOfNodes, (elem) => { });
```
Should I give more consideration to the NodeList foreach() method or a for...of loop?
Definitely! What you do was needed a few years back when NodeList.forEach() lacked broad support. Today, it's available in every browser and can be used with the call() hack.
That or for...of both work great.
so there is no an instant jQuery to vanilla javascript converter?
Not that I'm aware of, no.
It would be nice to explain the difference between "display:none" and the hidden attribute, because it's not the same thing. Choosing to change the way it's hidden is (I think) outside the scope of converting to vanilla JS.
Also, does the use of "for...of" free you of having to check for an empty result from querySelector()?
Functionally, the hidden attribute is identical to display:none;. They literally do the same thing, and for a while, the CSS polyfill for the hidden attribute was [hidden] {display: none;}
Which is all to say, we're not really changing anything of importance in this particular case.
For extra safety, it is still a good idea to check that something was returned with querySelector(), but in this instance with hard-coded HTML, I chose to skip that check.
In a real-world application, I might include it.
Thanks for giving a reason to look it up and find that there's a new value for hidden: "until-found" which means it can be found with in-page search.
The docs also say "Web browsers may implement the hidden state using display: none", the key word being "may".
I think I was remembering "visibility: hidden", which is quite different from "display: none".
My main concern from the docs page is "elements styled display: block will be displayed despite the hidden attribute's presence", because of course CSS overrides attributes, which means it is not good to arbitrarily replace it when converting to plain JS unless you know all the code involved.
As for the for loop, who ever writes for hard-coded HTML? Would an empty result from querySelector() cause a problem in the for loop? I have used the for loop technique in other languages to eliminate an if statement.
@@thinkjoyously A few threads to pull at here...
[hidden] is a native attribute whose use is preferred over display: none for toggling visibility today. You can override visibility of display: none, too. What you're describing is collisions in app behavior, which is a bigger issue than "which approach to hidings things did I use?"
"Which means it is not good to arbitrarily replace it when converting to plain JS"
With all due respect, we're not converting some big legacy app here. We're looking a small snippet of example code and exploring how we'd use modern approaches to code it instead. [hidden] is 100% appropriate here.
"As for the for loop, who ever writes for hard-coded HTML?"
Most websites are pre-rendered HTML, often with the aid of a CMS or static site generator, NOT dynamically generated HTML with JavaScript.
And again, this was a teaching video, not a battle-hardened, production ready app.
I'm not particularly interested in arguing about minutia in the TH-cam comments.
I usually put 2 functions like this in my code
function $(selector, element=document) {
return element.querySelector(selector)
}
function $$(selector, element=document) {
return Array.from(element.querySelectorAll(selector))
}
Big fan of that technique, especially if you find yourself typing selectors a lot!
@@gomakethings I always create more little helper functions, depending upon what the project needs, like an empty function, or a set styles function base on an object.
I still love jQuery and still use it. I don't see a noticeable performance gain by not using it. "Because it's old" just doesn't seem to be a good reason not to use it. Most of HTML is "old" too. But I do think it's good to teach new people on vanilla JS first.
Hi Brian - sounds like you're using newish hardware and good internet, then!
Ditching jQuery for vanilla JS has big, measurable performance impacts, particularly on older devices and sluggish web connections.
all can be done in vanilla js without importing an abstraction library like jquery
@General Aladeen That's always been true, but it was created to make things a bit easier. Which it does.
@Go Make Things what is it, 30kb? Even at 7Mps it still downloads in just a few milliseconds. You don't need the latest hardware or superfast broadband to handle it. And it could already be cached in the client. Optimizing images will gain far more performance than avoiding a jquery download. Just sayin'.
Chris,
I was referring to download performance, e.g. 30kb versus a 2mb hero image. That initial page load is what most users notice and images are the killer there. And the caching I referred to was local, not cdn. But your points are well taken about in-browser performance, I don't dispute that at all. I just think that for most web pages the performance hit is so negligible (20 milliseconds on average, I'm estimating, according to one of those links) that it shouldn't be the primary decision to not use jQuery. I wouldn't use it for Amazon.com, of course. Also, anyone using WordPress has much bigger concerns besides jQuery. 😂
Thanks for the links and responses.
General,
Yes vanilla is easy. Just not quite as easy as J. Like I said, I definitely advise people to learn vanilla. I just don't see the point in ripping out J and refactoring for vanilla when all you are saving, for most web pages, is a few milliseconds.
@@briankgarland The latest version of jQuery is 285kb after the browser compiles and unminifies it. However, file size alone is only a small fraction of how JavaScript impacts performance.
Optimizing images will NOT have a bigger performance impact than reducing your JavaScript usage. That's a myth started years ago that wasn't true then and very much isn't true now.
1kb of JavaScript is substantially worse for performance than 1kb of JPG is.
I would encourage you to learn more about web performance, as you're making a lot of statements and assumptions that simply aren't accurate.
Links to follow...