41–50 of 113 posts
Another similar gotcha is that the global-scoped `name` variable must be a string. See https://developer.mozilla.org/en-US/docs/Web/API/Window/name for details. var name = true; typeof name; // "string", not "boolean" Luckily, this is not true within ES modules which you probably use most of the time anymway.
I don't want to sound like I have an axe to grind (but I do), but this is the kind of feature/wart that shows the age of the HTML/CSS/JS stack. The whole thing is ripe for a redo. I know they get a lot of hate, but of all the big players in this space I think FB is the best equipped to do this in a way that doesn't ruin everything. I just wonder if they have an incentive (maybe trying to break the Google/MS hegemony…
I don't want to sound like I have an axe to grind (but I do), but this is the kind of feature/wart that shows the age of the HTML/CSS/JS stack. The whole thing is ripe for a redo. I know they get a lot of hate, but of all the big players in this space I think FB is the best equipped to do this in a way that doesn't ruin everything. I just wonder if they have an incentive (maybe trying to break the Google/MS hegemony…
Web developers have worked around quirks for as long as I can remember. The stack has many warts, but we learn to adapt to them. Like 90% of a web developer's job is working around gotchas, and will continue that way. A 'redo' might not be needed. Developers need something to moan about and need something to keep them employed :)
Seems like something that could have been made safer just by name spacing it a bit better. Something like “window.elements.myDiv”? I wonder why the decision to go straight to the root.
The simplest possible syntax is to make named elements available globally, and if that clashes with future additions to the DOM API then well that's a problem for some future idiots to worry about.
as a strategy it worked pretty well, unfortunately
Now I'm worried of using IDs and finding issues with globals in JavaScript. Seems to be a curious issue to be debugged.
In 2022, that alone is enough to wipe it from my toolbox as a web developer. Ain't nobody got time for that.
(... there are lots of other reasons it'd be bad practice to rely on this as well, although it's nice for debugging when available).
Another similar gotcha is that the global-scoped `name` variable must be a string. See https://developer.mozilla.org/en-US/docs/Web/API/Window/name for details. var name = true; typeof name; // "string", not "boolean" Luckily, this is not true within ES modules which you probably use most of the time anymway.
It takes a special kind of human to name variable "name" but not have it be a string.
name = {first: "Jane", last: "Doe"}
The 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…
Now I'm worried of using IDs and finding issues with globals in JavaScript. Seems to be a curious issue to be debugged.
Avoid globals at all costs - use IIFE [1] instead, wrapping your function in parenthesis and invoking it right away. [1] https://developer.mozilla.org/en-US/docs/Glossary/IIFE
{
let foo = 1
};
// foo is undefined here