4 ms·
You are misreading the documentation. There's no such distinction as live node vs. static node in that sense. There's only a distinction between a live node lis
by anderskaseorg 5y ago
You are misreading the documentation. There's no such distinction as live node vs. static node in that sense. There's only a distinction between a live node list and a static node list. This is a difference between getElementsByClassName("foo") and querySelectorAll(".foo"), but not between getElementById("foo") and querySelector("#foo").
The difference is whether membership changes in the collection are reflected immediately. Changes to the nodes themselves are reflected as usual either way, and node references do not spookily invalidate or repoint themselves.
- kasajian 5y agospookily?
- JoelEinbinder 5y agoIts a reference to Einstein's spooky [action at a distance](https://en.wikipedia.org/wiki/Action_at_a_distance https://en.wikipedia.org/wiki/Action_at_a_distance)
- snovv_crash 5y agoGlad to hear that Javascript is such a simple language and only experts should use things like C++.
- samastur 5y agoThis is an API issue (DOM), not a language one.
- da_chicken 5y agoDeflecting to semantics or categorization isn't a defense.
- christophilus 5y agoSimilarly, C is crappy because operating system APIs are crappy.
- samastur 5y agoMy point it that it is a defined behaviour of the DOM API which is generally implemented in C++ and exposed to Javascript environment. It behave exactly the same way if you use bindings for any other language. It's not an ECMAScript defined feature. You can also implement exactly this behaviour in any language so how is this then a Javascript language issue?
- snovv_crash 5y agoNo, it's a language issue. The language doesn't let you specify that things cannot go out of scope 'spookily', so it is ambiguous and you have to trust things like documentation. Just like it's easy to make memory management issues in C, this is the kind of thing that's easy to get wrong in JS.
- rndgermandude 5y agoIt's not part of javascript, it's part of the DOM API, and yes, that makes a difference. That's like calling C++ bad because you don't like boost, or calling python bad because you don't like django. (I am not saying tho that there isn't plenty to criticize in javascript itself). The DOM API is not javascript specific. The API surface is defined in terms of WebIDL (Web Interface definition language). While it is most commonly found in browsers and therefore javascript, it is not specific to browsers or javascript. Browsers themselves ship various javascript environments that do not even include the DOM API at all (WebWorkers aka threads, ServiceWorkers, PAC all give you an environment without a DOM). nodejs doesn't come with a DOM (tho there is an implementation available in jsdom). There is nothing really preventing you from looking at the DOM spec and writing your own DOM API implementation for your preferred language. In fact Microsoft and Google used to do that for their in-browser support of vbscript and dart respectively, python ships with xml.dom (implementing an older version of the spec), java ships with org.w3c.dom (implementing an older version of the spec). There is a C# implementation in the AngleSharp library, somebody wrote a go implementation, and so on.
- snovv_crash 5y agoSo tell me, how would the invalidation work if the API were written in a language like Rust? You've just listed a bunch of GCed languages and told me it's due to the API not the language. GC lets you be sloppy with resource initialization/cleanup though, and having GC doesn't magically fix when the external objects you interact with go in and out of scope. So what I'm arguing above is that GCed languages are actually just as hard as manual memory managed languages the moment you need to interact with the real world... be it UI elements, file handles, network sockets, or whatever. Memory isn't the only resource that needs management, and languages that have idiomatic resource management are actually good at this kind of thing.