On Jan 16, 2015, at 4:07 PM, Dimitri Glazkov <dglaz...@google.com> wrote: > On Fri, Jan 16, 2015 at 1:14 PM, Ryosuke Niwa <rn...@apple.com> wrote: > >> On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov <dglaz...@google.com> wrote: >> On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa <rn...@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.
Indeed. > 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 implementations are so desired, they could certainly do that. There is nothing that prevents from UAs to run any scripts at any timing as long as the observed behavior is interoperable. For example, an implementation could construct a queue of nodes as a form of a detached DOM tree, and then call constructors on those objects after manually detaching them; the noes could be inserted again once the elements are "constructed". Such an approach allows implementing Jonas' proposal with very small set of changes to existing HTML parser implementations. > 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. Unless I'm missing something, scripts that use JavaScript APIs exposed by those custom elements cannot run until those custom elements are "upgraded". Again, this is not a problem that should be solved for only custom elements. This is a generic script and resource dependency problem for which an extensive list of use cases have been identified: https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html > 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. There are a lot of high profile websites that run scripts prior to the document has finished parsing. Furthermore, if that were already the case, how does introducing the mechanism for elements to asynchronously upgrade help authors at all? If anything, it adds another dimension to the already complex problem space developers have to face today. > 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. Correlation doesn't imply causation. The way I see it, a lot of Web apps are using the HTML parser as a bootstrapping mechanism today because they need to get data out of JSON they fetched out of services instead of embedded in HTML. Also, if the needs of developers obsolete HTML and DOM, then so be it. Perhaps the future of the Web apps is a bundle of ES6 modules. - R. Niwa
