And named form controls are accessible as properties of the same name on their form element.
Named element IDs can be referenced as JavaScript globals
101–110 of 113 posts
Re: Named element IDs can be referenced as JavaScript globals
#102Earlier quoted context omitted.
May be worth testing it against getElementsByClassName(), which also returns a live collection.
I actually just went and tested and in webkit at least my 100% perfect test case I had querySelector taking 2x longer than getElementById. I tried understanding what the current webkit code does but the selector matching code is now excitingly complex due to the CSS JIT. Many many years ago I recall querySelector starting out with a check for #someCSSIdentifier and shortcutting to the getElementById path, but maybe m…
Yup that's what it did, and Chrome still does. After much research and prototyping the CSS JIT didn't improve real world content (especially given the complexity) so it was never added to Chrome.
Re: Named element IDs can be referenced as JavaScript globals
#103The global scope polluter has pretty bad performance and interop surprises, you shouldn't depend on it and instead use getElementById even if it's a bit more verbose. It uses a property interceptor which is fairly slow in v8: https://source.chromium.org/chromium/chromium/src/+/main:out... to call this mess of security checks: https://source.chromium.org/chromium/chromium/src/+/main:thi... which has this interop surpr…
Is there a reason to not use querySelector, since it’s a lot more flexible? One reason jQuery became so popular is because the DOM was painful to use. Things like querySelector fix that.
QuerySelectors are slow. Epic slow. I would also argue that querySelectors are far less flexible and became popular because they are instead easy.
https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc
ProTip: Without numbers performance opinions are wrong by several orders of magnitude 80% of the time.
Re: Named element IDs can be referenced as JavaScript globals
#104Earlier quoted context omitted.
In isolation definitely, but in real world code it might be faster to use querySelector for branchy code if it doesn’t always use an id. As with everything, if it’s not performance-sensitive write the code that’s easier for humans to read, and if it is measure first.
I'm not sure what you're trying to say here, as it's tautologically correct that getElementById can't be used in cases where you want to select on more than just the id. Do you mean a use case where you have branchy code that produces a selector string that has some id only paths?
Yes. Branchy code which could sometimes use getElementById and other times use querySelector may be faster if it always uses querySelector, even if that call itself is slower. The reason for this is that the JITs sometimes deoptimize on branchy logic with inconsistent property access between branches. They also deoptimize on branchy logic defining intermediate values, but much less often when the value is a consistent type like a string (selector).
Re: Named element IDs can be referenced as JavaScript globals
#105Earlier quoted context omitted.
I'm not sure what you're trying to say here, as it's tautologically correct that getElementById can't be used in cases where you want to select on more than just the id. Do you mean a use case where you have branchy code that produces a selector string that has some id only paths?
Yes. Branchy code which could sometimes use getElementById and other times use querySelector may be faster if it always uses querySelector, even if that call itself is slower. The reason for this is that the JITs sometimes deoptimize on branchy logic with inconsistent property access between branches. They also deoptimize on branchy logic defining intermediate values, but much less often when the value is a consisten…
This would only be relevant if you're doing something like
var theFunction = condition ? "querySelector" : "getElementById";
...
document[theFunction](...)
if (condition)
document.querySelector(...)
else
document.getElementById(...)
It is possible that the higher level JITs pay attention to the branch counts on conditions or use other side channels for the deopt, but for host functions it's generally not something that will happen as the JITs see natively implemented functions as largely opaque barriers - they only have a few internal (to the runtime itself) cases where they make any assumptions about the behaviour of host functions.
Re: Named element IDs can be referenced as JavaScript globals
#106Earlier quoted context omitted.
There is some effort to standardize something along these lines. Well, some things which combined would achieve this. It’s too late to bake it into ESM, but I believe it’ll be possible with ShadowRealms[1] and/or SES[2], and Built-in Modules (JS STL)[3]. 1: https://github.com/tc39/proposal-shadowrealm 2: https://github.com/tc39/proposal-ses 3: https://github.com/tc39/proposal-built-in-modules
Luckily the Reddit thread has the Yu-Gi-Oh! jokes so I don't have to repeat them here.
I don’t know what jokes or Reddit thread you’re referring to or why it has anything to do with my comment referencing three technical proposals, but I’ll take your word for it that you don’t have to repeat them here.
Re: Named element IDs can be referenced as JavaScript globals
#107Earlier quoted context omitted.
Yes. Branchy code which could sometimes use getElementById and other times use querySelector may be faster if it always uses querySelector, even if that call itself is slower. The reason for this is that the JITs sometimes deoptimize on branchy logic with inconsistent property access between branches. They also deoptimize on branchy logic defining intermediate values, but much less often when the value is a consisten…
This would only be relevant if you're doing something like var theFunction = condition ? "querySelector" : "getElementById"; ... document[theFunction](...) it won't apply to if (condition) document.querySelector(...) else document.getElementById(...) As from the point of view of the runtime the latter has two call sites, and each one is monomorphic and will very quickly (first layer of the JIT tower generally) become…
> As from the point of view of the runtime the latter has two call sites, and each one is monomorphic
I expected that to be the case but I’ve actually measured it and it’s not always. It is, when the object being accessed has a consistent shape/hidden class, as you mention, but a lot of times they don’t. A weird case is native interfaces because while the host functions are opaque and you’d expect they have a stable shape the interfaces themselves are often mutable either for historical reasons or shortcuts taken in newer proposals/implementations. Accessing document.foo isn’t and can’t be monomorphic in many cases, even if it can be treated that way speculatively. But branchy code can throw out all sorts of speculation of that sort. I don’t know which level of the JIT this occurs at, I’m just speaking from having measured it as a user of the APIs.
Re: Named element IDs can be referenced as JavaScript globals
#108Earlier quoted context omitted.
Is there a reason to not use querySelector, since it’s a lot more flexible? One reason jQuery became so popular is because the DOM was painful to use. Things like querySelector fix that.
QuerySelectors are slow. Epic slow. I would also argue that querySelectors are far less flexible and became popular because they are instead easy . https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc ProTip: Without numbers performance opinions are wrong by several orders of magnitude 80% of the time.
I’m getting 70mops byId and 23mops qs-#id. This looks like making a huge difference until I add these cases:
3: "abc”.replace("a", "b")
4: "1" * 2
Re: Named element IDs can be referenced as JavaScript globals
#109Earlier quoted context omitted.
QuerySelectors are slow. Epic slow. I would also argue that querySelectors are far less flexible and became popular because they are instead easy . https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc ProTip: Without numbers performance opinions are wrong by several orders of magnitude 80% of the time.
I’m getting 70mops byId and 23mops qs-#id. This looks like making a huge difference until I add these cases: 3: "abc”.replace("a", "b") 4: "1" * 2 Which result in 15mops and 74mops respectively. This test measures diameters of neutrinos so to say.
My experience is that most developers tend to guess at performance and throw away numbers they disagree with. As a result performance testing is only something product owners care about.
Re: Named element IDs can be referenced as JavaScript globals
#110Earlier quoted context omitted.
Luckily the Reddit thread has the Yu-Gi-Oh! jokes so I don't have to repeat them here.
I don’t know what jokes or Reddit thread you’re referring to or why it has anything to do with my comment referencing three technical proposals, but I’ll take your word for it that you don’t have to repeat them here.
https://www.reddit.com/r/javascript/comments/t8mdli/future_j... if you’re curious. Didn’t mean to be overly vague, I just think ShadowRealms is an unusually funny name for a technical proposal. I guess it doesn’t have the same effect if you didn’t grow up watching the same cartoons.