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.

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.

You can also implement exactly this behaviour in any language so how is this then a Javascript language issue?