Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
should I replace document.getElementById or so by document.querySelector?
any difference?
Will you recommend me to use querySelector?
When you are selecting on ids anyway, use getElementById as that’s a lot more efficient than using querySelector on an id selector. The latter runs the whole CSS selector parsing, while the former can just take the ID and get the element with that ID directly.
Of course, when selecting based on other criteria than the element’s id, querySelector (and querySelectorAll) obviously has its place.
(The obligatory benchmark to prove this claim, although I do want to note that benchmarks are not everything, and the difference probably won’t make much difference in an actual application.)
Both serves same purpose in your case. But getElementById is most proven approach. However, if you are not concerned about legacy browsers then querySelector will also suffice.
Enjoy!
If querySelector is available in the browser that your users use. Then you can use it. It is nice to not have to litter your html with ids. Selecting using css selectors is extremely flexible.
Performance is a red herring. My shitty old laptop can manage 3 million selections a second...
The real problem is compatibility. How are you going to deal with browsers that don't have it available? Do you care? You probably have to care.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
My question is the following. Should I avoid using any kind of jQuery code in Angular application as it seems legit to have only one thing interacting with DOM.
Another question is if anyone came across problems where he couldn't find any other solution but writing a quick hack with jQuery.
Thank YOU!
Yes it's a bad practice, but sometimes it will save you much time, especially when you are looking for a plugin,
Do it when necessary only, and keep a note to switch it back when other solutions are available.
The first thing you should do is to read this thread on SO "Thinking in AngularJS" if I have a jQuery background?. This will give you some perspective.
When it comes to Angular, it the model that drives the view and most of the times direct DOM manipulation is not required.
For example if you are using DOM manipulation to show\hide element, add remove class or set style, then better to use ng-show\ng-class\ng-style directive.
But there are cases when DOM manipulation is required and that is the time you write directives and either use jqLite or jQuery to manipulate DOM.
My suggestion would be to avoid jQuery unless you have to incorporate a jquery plugin that is dependent on jQuery.
While developing always look if the inbuilt directives that can serve your purpose. If not can jqLite be used to achieve what is desired. Your final resort should be jQuery.
Well it's just two large resources, which makes your app "heavy". Otherwise it's only a preference thing. Personally I don't use jQuery with any of the reactive frameworks (Vue, React nor Angular).
Remember that anything jQuery can do, you can do with vanilla JS.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
There are many ways to use JavaScript. When I use JavaScript with an anchor, I write code like this and I think this way is right.
Method One
But my co-worker uses JS like this.
Method Two
Is there a coding standard or are both methods correct?
DISCLAIMER: Inline JavaScript is, generally speaking, a bad idea, and 99% of the time you're much better off separating concerns, and using a library, such as jQuery, or whatever similar toolset that your framework of choice recommends.
Nonetheless, to answer your question, if you must use inline JavaScript, I recommend that you omit the "JavaScript:" keyword. It specifies a "pseudo-protocol," and is not necessary for modern browsers to interpret the code. It is a relic from the last decade, and there is a bug with some versions of IE:
"There is one (somewhat obscure) bug with the javascript protocol - in
Internet Explorer*, it will think you are leaving the page when you
click the link. If you are using window.onbeforeunload, then your
navigate-away message will appear at this time. For this reason alone,
we've stopped using the javascript protocol completely so we don't
have this bug show up because we forgot to check for it when we add a
navigate-away message to some page."
When do I need to specify the JavaScript protocol?
https://bytes.com/topic/javascript/answers/504856-javascript-pseudo-protocol-event-handlers
Both the ways are ok but in first way you should use a external JS file. Otherwise it is ok.
For small tasks and events second ways is good.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
I have heard that querySelector and querySelectorAll are new methods to select DOM elements. How do they compare to the older methods, getElementById and getElementsByClassName in terms of performance and browser support?
How does the performance compare to using jQuery's query selector?
What is the difference between queryselector and getElementById?
When should we use queryselector instead of getelementbyid? Is there Any example which is not possible using getElementById?
"Better" is subjective.
querySelector is the newer feature.
getElementById is better supported than querySelector.
querySelector is better supported than getElementsByClassName but querySelector gives you a static node list while getElementsByClassName gives you a live node list.
querySelector lets you find elements with rules that can't be expressed with getElementById and getElementsByClassName
You need to pick the appropriate tool for any given task.
(In the above, for querySelector read querySelector / querySelectorAll).
The functions getElementById and getElementsByClassName are very specific, while querySelector and querySelectorAll are more elaborate. My guess is that they will actually have a worse performance.
Also, you need to check for the support of each function in the browsers you are targetting. The newer it is, the higher probability of lack of support or the function being "buggy".
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
Improve this question
I have heard that querySelector and querySelectorAll are new methods to select DOM elements. How do they compare to the older methods, getElementById and getElementsByClassName in terms of performance and browser support?
How does the performance compare to using jQuery's query selector?
What is the difference between queryselector and getElementById?
When should we use queryselector instead of getelementbyid? Is there Any example which is not possible using getElementById?
"Better" is subjective.
querySelector is the newer feature.
getElementById is better supported than querySelector.
querySelector is better supported than getElementsByClassName but querySelector gives you a static node list while getElementsByClassName gives you a live node list.
querySelector lets you find elements with rules that can't be expressed with getElementById and getElementsByClassName
You need to pick the appropriate tool for any given task.
(In the above, for querySelector read querySelector / querySelectorAll).
The functions getElementById and getElementsByClassName are very specific, while querySelector and querySelectorAll are more elaborate. My guess is that they will actually have a worse performance.
Also, you need to check for the support of each function in the browsers you are targetting. The newer it is, the higher probability of lack of support or the function being "buggy".
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am writing up some code in Javascript/JQuery that involves some confusing DOM operations, or at least they are to me because I'm relatively inexperienced.
I try to help myself by doing a couple of console.log()s, but the thing is if you just log a DOM element you get useless information, mostly it's object Object.
I was wondering what the most usefull generic attributes of a HTML element are so that I could easily follow what the script is doing?
I was wondering what the most usefull generic attributes of a HTML element are so that I could easily follow what the script is doing?
Don't use logging for debugging. Use a debugger for debugging. Even IE (8 and up) has a debugger built in. If you want to know what the code is doing, there's nothing that substitutes for stepping through the code in the debugger and examining your various variables and such as you go.
But answering your specific question, I'd say I'd want to see the DOM element's tagName, className (e.g, class[es]), and id (if any).
I would use chrome when inspecting the console log, the objects actually come through so you can expand and see all of their properties. Keep in mind some of the older browsers, IE8 or 7, do not support console.log and it will throw a javascript error.