RE: Custom elements contentious bits

From: Brian Kardell [mailto:bkardell@gmail.com] 

> I'd really like to understand where things really are with async/sync/almost sync - does anyone have more notes or would they be willing to provide more exlpanation?  I've read the linked contentious bit and I'm still not sure that I understand.

The question is essentially about at what time the custom element callbacks are being called. There are three possible times:

1. Synchronously, i.e. from within the middle of the DOM Standard's relevant algorithms/from within browser C++ code, we call out to JavaScript. There is then no queuing.
2. "Nanotask" timing, i.e. right before exiting C++ code and returning back to JS, we call out to queued JS.
3. Microtask timing, i.e. we put the callbacks on the standard microtask queue, letting any JS run to completion before running the microtasks.

The difference between 1 and 2 is very subtle and shows up only rarely, in complicated algorithms like cloning or editing. 3 is what you would more traditionally think of as "async".

> I can say, for whatever it is worth, that given some significant time now (we're a few years in) with web component polyfills at this point I do see more clearly the desire for sync.  It's unintuitive at some level in a world where we (including me) tend to really want to make things async but if I am being completely honest, I've found an increasing number of times where this is a actually little nightmarish to deal with and I feel almost like perhaps this might be something of a "least worst" choice.  Perhaps there's some really good ideas that I just haven't thought of/stumbled across yet but I can tell you that for sure a whole lot of frameworks and even apps have their own lifecycles in which they reason about things and the async nature makes this very hard in those cases.

I'm not really sure what you're talking about here. Is it something besides Chrome's web components, perhaps some unrelated framework or polyfill? Chrome's web components have always used (2), which is not really async in any meaningful sense.

> Shadow DOM will definitely help address a whole lot of my cases because it'll hide one end of things, but I can definitely see cases where even that doesn't help if I need to actually coordinate.  I don't know if it is really something to panic about but I feel like it's worth bringing up while there are discussions going on.  The declarative nature and the seeming agreement to adopt web-component _looking_ tags even in situations where they are not exactly web components makes it easy enough to have mutually agreeing "enough" implementations of things.  For example, I currently have a few custom elements for which I have both a "native" definition and an angular directive so that designers I know who write HTML and CSS can learn a slightly improved vocabulary, say what they mean and quickly get a page setup while app engineers can then simply make sure they wire up the right implementation for the final product.  This wasn't my first choice:  I tried going purely native but problems like the one described above created way too much contention, more code, pitfalls and performance issues.  In the end it was much simpler to have two for now and reap a significant portion of the benefit if not the whole thing.

This is a bit off-topic but...

As you point out, the main benefit of custom elements is not that you can use custom tag names in your markup---that is easily accomplished today. The benefits are being able to use the DOM API on the resulting tree (document.querySelector("my-custom-el").myCustomMethod()) and, most importantly, lifecycle callbacks. If you want lifecycle callbacks with a third-party framework, you must let that framework control your page lifecycle. The things Angular does to ensure this are horrendous, e.g. monkeypatching every DOM method so that it can know when certain lifecycle events happen. Letting the browser simply call out to author-supplied callbacks when it's already doing work is going to be much nicer.

> Anywho... I'm really curious to understand where this stands atm or where various companies disagree if they do.

Since nobody is proposing 3, where we stand now is that there seems to be a disagreement between 1 and 2. I don't really understand the advantages of 1 over 2, but I do believe Apple still prefers 1. It would be great to hear more.

Received on Monday, 28 December 2015 19:05:56 UTC