> Even with ES6 modules, we don't create a dummy modules while modules are loading and later automatically replace them under the foot.

This is exactly what we do with ES6 modules.

(In reply to Domenic Denicola from comment #1)
> > Even with ES6 modules, we don't create a dummy modules while modules are loading and later automatically replace them under the foot.
> 
> This is exactly what we do with ES6 modules.

How? import { myClass } from 'mymodule'; doesn't create a promise or anything. It'll just block until mymodule is loaded.

Referencing myClass will be a reference error until 'mymodule' is loaded. This normally comes up in the case of circular dependencies.

(In reply to Domenic Denicola from comment #3)
> Referencing myClass will be a reference error until 'mymodule' is loaded.
> This normally comes up in the case of circular dependencies.

I'm not certain what you mean by "until 'mymodule' is loaded' but the 'mymodule' will be synchronously fetched and evaluated before the following statements are executed.

e.g.
import { myClass } from 'mymodule'; // (1)
new myClass; // this line of code is never executed until (1) is done executing.

The fact we can encounter a circular dependency in (1) is an orthogonal issue. The fact of matter is that the declarative syntax for importing an ES6 module DOES synchronously block the script execution.

It is correct that (2) will not execute until (1) is done executing. But (1) simply creates a dummy myClass binding which will cause ReferenceErrors if executed before myClass's definition is evaluated. myClass's definition may or may not be evaluated by executing (1).

Here is a simple example:

// a.js
import * as bModule from './b.js';
import { b } from './b.js';

// bModule is a dummy module with no properties
// if b is referenced it will cause a ReferenceError
// console.log(b); // fails

export let a = 1;

setTimeout(() => {
  // bModule is no longer a dummy module and has a b property
  // b can be referenced without errors
  console.log(b); // works
}, 100);

////////

// b.js
import * as aModule from './a.js';
import { a } from './a.js';

export let b = 2;

////////

// entry.js
import './b.js';

Execution order is entry.js -> a.js -> b.js. Thus inside a.js we have the dummy module which later gets upgraded. In fact this happens for a.js (and entry.js) as well, but you don't observe that since you can't see them pre-upgrade.

Again, even in this example, files are fetched and evaluated synchronously.

But let us not derail this bug from the main topic, which is about not upgrading custom elements. Even if my statement about class wasn't accurate, the fact that upgrading existing elements is a bad idea wouldn't change.

I think it's very relevant. In a dynamic system with interdependencies, upgrading of some sort is important. We have it for ES6 modules, and it makes just as much sense for custom elements, for the same reasons.

(In reply to Domenic Denicola from comment #7)
> I think it's very relevant. In a dynamic system with interdependencies,
> upgrading of some sort is important. We have it for ES6 modules, and it
> makes just as much sense for custom elements, for the same reasons.

Why?

Moved to https://github.com/w3c/webcomponents/issues/134