getElementById vs. using the id name [duplicate] - javascript

This question already has answers here:
Do DOM tree elements with IDs become global properties?
(5 answers)
Closed 5 years ago.
I have found that I don't need use document.getElementById to get the an element, I can use like this:
<div id="observer1"></div>
Then i can access like a variable:
console.log(observer1);
Why should I use the document.getElementById if I can access directly?
I had never heard that this was possible, is there any side-effect, is this supported in all browsers?
Thank you.

Using console.log(observer1) just outputs the whole element. You have no control over it. You can't adjust properties, attributes or assign values. There is almost no practical use for doing it that way.

Related

jQuery, which is best, assigning element to variable or not? [duplicate]

This question already has answers here:
Is storing jQuery elements in variables more efficient?
(5 answers)
Closed 2 years ago.
While reading jQuery and Bootstrap documentation I often see this:
var modal = $('#someid');
modal.find('.something').text('something');
modal.find('.somethingelse').text('somethingelse');
It first assigns the element to a variable, then works from there. However I usually write this:
$('#someid').find('.something').text('something');
$('#someid').find('.somethingelse').text('somethingelse');
My question is, are there reasons for using the first method - assigning to a variable - other than the syntax itself? Is it faster or better regarding the DOM?
The first method is preferred for multiple reasons.
It cuts down on the number of times the DOM has to be accessed, which is a relatively slow operation and so it performs better.
It reduces the number of times your code instantiates a new jQuery object from an existing Element object, which is another performance benefit.
It DRYs up the code so that the same statements are not needlessly repeated.
As such you should always follow this practice, known colloquially as 'caching the selector', where possible.

What are the practical applications of using ParentElement instead of ParentNode? [duplicate]

This question already has answers here:
Difference between DOM parentNode and parentElement
(5 answers)
Closed 3 years ago.
I'm learning JavaScript and I learned about the Node.parentNode property, which simply returns the parent of the current node. However, JavaScript also has another property called Node.parentElement, which seems like the same thing. I found out from this question that the difference is that parentElement will return null if the parent node is not an element.
I understand the difference between the two, but I can't imagine this ever being useful. Is it ever good practice to use parentElement instead of parentNode? If not, why does it exist?
Edit: The question I have linked is similar, but not the same as my question, because it is asking how the two properties behave differently. I know the difference, but I want to know what the actual purpose is of ever using parentElement, or if it's pretty much always bad practice and we should all agree to ignore parentElement. This specific question - the 'why' rather than the 'what' - was not answered here.
It is, most of the time, pointless.
The difference is that the ParentNode is not always an Element, in which case ParentElement will return null.

Whats faster when using jquery selectors .classname or div.classname [duplicate]

This question already has answers here:
CSS :: Difference between .className and div.className
(3 answers)
Closed 6 years ago.
Is it faster to use
$(".classname").
or add the tag to look for as well
$("div.classname")
I think its the classname as i'm sure jquery will just loop through to get all classnames where the 2nd one will first get all the div tags and then loop through that subset to get the classnames. Thats what i think anyway.
Anyone know?
You can always run your code on jsperf.com to check code sequence performance in different browsers.
About your questions. Chrome run shows that strict selector (tag + class name) is much slower than class selector only
Anyway you can rerun this code in different browsers to use different program flow based on browser type.
https://jsperf.com/jquery-class-vs-tag-qualfied-class-selector/2

Do ng-hide and ng-show actually load the element and hide it, or does it only load on ng-show? [duplicate]

This question already has answers here:
When to favor ng-if vs. ng-show/ng-hide?
(7 answers)
Closed 6 years ago.
If it is the first, is it an effective way of programming, given that the elements may be 10 mb images or something? And what would be a better way?
ng-show/hide simple changes the display style, so the element is still loaded into the DOM regardless of the result.
You can use ng-if to determine if an element should be loaded to the DOM or not. Documentation here

Is getElementById optional in some browsers? [duplicate]

This question already has answers here:
Do DOM tree elements with IDs become global properties?
(5 answers)
Closed 8 years ago.
When accessing elements by window.someThing, the "someThing" should be the name of html element. But what I see now, is that I can access an element by id in the same way, without document.getElementById. When has this been changed? It looks like it works in Chrome, IE, Firefox 13, but not in Firefox 12.
For example:
<div id="MyDiv">Content</div>
<script>
MyDiv.innerHTML = "New Content";
</script>
Why does the example above work? Why don't I have to do:
var MyDiv = document.getElementById('MyDiv');
Is it something new, or has it always been possible and I just didn't know it?
http://www.quirksmode.org/dom/w3c_core.html#gettingelements
It's been (mostly) implemented since IE 5.5
I can't really find any info on using the ID as variable name. I'd suggest on sticking to getElementById("MyDiv").doSomething instead of MyDiv.doSomething, to improve compatibility.
Especially when you're writing larger scripts, you may mix up variable names with id's used in the page. getElementById ensures you "get" the DOM element.
This is not standard behavior in JavaScript. When adding a variable as you did with var MyDiv, the variable was added to the window object so that it could be accessed directly as if it were a property, but DOM elements were never added. I don't personally know the reasons for the new behavior, but my guess would be that it's just an expansion of the language engine's capability. If you really want to know what the behavior is supposed to be, you could always read the standard: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
Edit: Also, note that the method that is used to get the element is document.getElementById() which comes from the document object model. The method you're referring to is placing an id into the window object which can create conflicts by id. The standard defined method is to get the element from document and avoid putting things into the window. Using the window object in this manner would be similar to using a global variable (which is a bad practice re: http://www.javascripttoolbox.com/bestpractices/#namespace)
You can find your answer here: Can I Use an ID as a Variable Name?
In short, avoid it.
The reason it works is because the browser actually creates a variable window.document.myDiv
AVOID IT!
It seems like an amazing feature but I would recommend not using it because if you have divs with id same as that of some global JS variables, it would be conflicting and will also mess-up stuff in some other third party JS files that you include.
But You always have jQuery selectors always with you and not to forget the new querySelector feature in modern browsers :)

Categories