Re: Minimum viable custom elements

On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov <dglazkov@google.com> wrote:
> On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>
>> When an author imports a ES6 module, we don't create a fake object which
>> gets resolved later by rewriting its prototype.
>>
>
> These are two completely different things, right? In one situation, you
> are dealing with HTML Parser and blocking thereof. In another, there's no
> such concern.
>
>
> How are they different at all?  I have a hard time understanding how
> differentiating DOM objects from other ES6 builtins will fit your stated
> design goal to explain the Web platform.
>

... because DOM objects are not the ES6 built-ins?


>
> If we are implementing the HTML parser as well as the entire DOM in
> JavaScript, why wouldn't we just use constructors to create DOM nodes?
>

I feel like we're walking in circles at this point.

It's pretty safe to say that we're years away from being able to implement
HTML parser and the entire DOM in JS. Even then, time-shifted callbacks (or
similar write-barrier-style abstraction) still make sense. The JS that
implements the parser or DOM may desire to run the custom elements JS code
only in certain places (see Mutation Events -> Mutation Observers).


>
> If your concern is that it would block the rendering of the page,
>

No, it is not.


>
> If your concern is that authors must wait until other scripts that define
> custom elements are loaded even after DOMContentLoaded is fired,
>

No, it is not.

Let me repeat and extend what I said earlier in the thread. In the world
where we have non-blocking scripts and HTML parser that yields, upgrades
are a performance/ergonomics primitive.

With upgrades, the non-blocking script could execute during a yield,
register elements, and keep on going. The chunk of html that was parsed
previously will upgrade, and the chunk that hasn't yet parsed will start
queueing callbacks. The developer does not need to care about the timing of
registration. From their perspective, the order of callbacks will be the
same.

Without upgrades, you as a developer are highly incentivized to reduce the
amount of html after your non-blocking script, because you need to wait
until the doc parsed completely until you can sensibly run the script.

This is what's happening today, as evidenced by most frameworks moving away
from using HTML Parser as anything but script bootstrapping device, and
relying on imperative tree construction. And in that world, upgrades are
useless -- but so is HTML. And eventually, DOM.

:DG<