To me CustomElements V1 is the API that would have benefited most from origin trials. It was specced unpolyfillable (relying on ES6 syntax) which real dev exposure would have immediately found. Classic failure of backroom standardizationhttps://twitter.com/slightlylate/status/1139626438766673920?s=19 …
-
-
-
Replying to @rwaldron @cramforce
constructor `super()` calls. Other option was (V0's) prototype swizzling.
1 reply 0 retweets 1 like -
They core problem is that to be "truly native", subclasses of host objects and intrinsic types (e.g. Array, Number, etc.) need a way to signal to the runtime that they are "special". For DOM, this means wiring up a C++-side pointer to a backing struture (in ~all impls).
3 replies 0 retweets 0 likes -
This has to be done super early in the object's lifetime. In V0, we did this by looking at the swizzled prototype chain at new-time. This allowed the runtime to allocate the required backing data and wire up property lookup to use it. In V1, `super()` has to happen *first*.
1 reply 0 retweets 0 likes -
Both approaches get you temporally coherent "DOMness", with the syntactic approach opening up the same thing for other intrinsic types at the cost of
@cramforce's regretted compat/polyfillability1 reply 0 retweets 0 likes -
We had a weak preference for syntax, but TC39 took *forever* on intrinsic subclassing (ZOMG), so in V0 we did the dirty thing that also got us polyfilling circa '12 or '13.
2 replies 0 retweets 1 like
Fast-forward to V1 design in '15, syntax looks like a more reasonable bet, and some folks in the committee are...shall we say...rather _insistent_.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.