Native Tensor support

Isiah Meadows isiahmeadows at
Sat Jan 27 04:37:56 UTC 2018

I'm speaking from the framework's side. Yes, I did gloss over certain
complexities and constraints, but yes, it's almost there in practice.

1. If they don't expose the node through a ref or something, and no event
handlers exist, they could just assume (unsafely) you don't reference it,
and act accordingly. Note that I'm speaking from the framework level, which
can take liberties browsers can't.
2. I make the assumption you build change lists beforehand, and that
resolves all dependencies first. And in general, once you figure out what
changes need made, it doesn't actually matter as long as you unregister
`blur`/etc. handlers that fire on removal before applying the change list.
3. Script elements execute async, so you could ignore order here.
4. For style elements and ref-accessible elements, you could still execute
the changes in set slices, splitting on nodes/callbacks that require
awareness of past effects. (This could just be a flag.) However, these are
exceedingly rare.

On Fri, Jan 26, 2018, 23:18 Boris Zbarsky <bzbarsky at> wrote:

> On 1/26/18 10:49 PM, Isiah Meadows wrote:
> > Applying DOM changes from a static change list is
> > an embarassingly parallel\* problem.
> Only if you know there are no overlaps in terms of the nodes involved.
> And you ignore mutation events.  And you ignore the fact that mutation
> records expose your order of operations.  And you know that none of the
> insertions have immediate side-effects (e.g. none are <script> nodes).
> And your style system doesn't try to do style recomputation in certain
> ways.  And probably some other conditions that I'm forgetting.
> -Boris
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list