Will any new features be tied to constructors?

Domenic Denicola d at domenic.me
Wed Jul 1 14:55:28 UTC 2015

From: Allen Wirfs-Brock [mailto:allen at wirfs-brock.com] 

> Do one has yet explained to me, what is wrong with simply initially  inserting a dummy (generic) custom element node during DOM parsing and latter (after the required JS code has loaded) replacing that node with a new more specific node that is an instance of the named subclass.

Anne explained this to you in https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors#content-3. There's also the issue that replacing nodes that have children gets much more complicated, especially if those nodes are high up in the tree. More detail at https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Why-Upgrades.md.

> My premise is that once script is running DOM nodes can be arbitrarily added/removed/modified as a side-effect of any script function.

In practice, this is not how one programs against the DOM. One assumes that things generally don't change except for good reason (i.e. author-initiated reason). It's common practice to save `document.querySelector('#my-thingy')` to a variable, and operate on it for many event loop turns, until some known event occurs. (Like Ajax fake page navigation, or blowing away the parent component, or closing a dialog, similar.)

It's decidedly bad practice to re-query the DOM for an element every time you want to use it, which seems to be what you're advocating as necessary.

More information about the es-discuss mailing list