Also, we have an impl that works well. Folks can make "showstopper" claims, but the proof is in the pudding. Note: other vendors are not building and testing alternatives. Talk is cheap.
-
-
Replying to @slightlylate @davidbrunelle and
Remember the grandstanding around "type 2+ encapsulation" for SD and how it wasn't worth pursuing w/o it? Stop-energy comes in many forms. Watch who's writing code and making things (safely) available to test.
1 reply 0 retweets 1 like -
Replying to @slightlylate @davidbrunelle and
We also have a well proven path for making breaking changes. When others feel the design we shipped is wrong, they can ship the "right" design, and if we find it to also be reasonable we can ship it too and push the ecosystem to migrate to the more broadly supported form.
1 reply 0 retweets 2 likes -
Replying to @RickByers @slightlylate and
Then, when safe to do so, we remove the flawed design. No API design is ever perfect, having a pragmatic path for increasing interop and improving the designs over time is the only option other than stagnation. It takes a lot of effort, but we often find it to be worthwhile.
1 reply 0 retweets 1 like -
Replying to @RickByers @slightlylate and
But as
@slightlylate says, key here is action and daya, not just talk and opinion. In both directions it's always shipping and competition which drives improvement (eg. After a decade of talk of 3P cookies, Safari shipping ITP was the real catalyst for industry-wide change).1 reply 0 retweets 2 likes -
Replying to @RickByers @slightlylate and
It's super weird to me that everyone just de facto accepts as obvious that yeah JS features need to be thoroughly vetted by TC39, achieve consensus, and Stage 3 status before anything ships. But Google's pet web component projects get to play by a different set of rules?
2 replies 0 retweets 0 likes -
Replying to @AdamRackis @slightlylate and
It's not just Google's pet projects, as I just said in the other tweet JS lang is the exception to the norm of how the web has almost always evolved.
1 reply 0 retweets 1 like -
Replying to @RickByers @slightlylate and
Adam Rackis Retweeted Rick Byers
I'm glad you see the JS process as impressive! Why not set an example at Chrome to bring that sort of process to web standards? As the absolute dominant (borderline monopoly) browser, your example here could do a ton of good.https://twitter.com/RickByers/status/1221142523198001157 …
Adam Rackis added,
Rick Byers @RickByersReplying to @hrmny_ @slightlylate and 2 othersFWIW this is how the web has ALWAYS evolved. Almost all APIs we use today we're shipped in the dominant engine prior to a standard being ratified (IE, Netscape, WebKit, now chromium). JavaScript language is a notable and impressive counter-example.2 replies 0 retweets 0 likes -
Replying to @AdamRackis @RickByers and
TC39 is deeply unhealthy and has been for a long time. We route around via DOM frequently. Holding it up as a positive example is a mistake.
2 replies 0 retweets 3 likes -
Replying to @slightlylate @AdamRackis and
I admit ignorance, never been to a TC39 meeting myself. All that I find impressive is that major new things like Wasm seem to come compatibly in all engines at about the same time, and (maybe?) in a reasonable timeframe? I can't imagine that happening elsewhere.
3 replies 0 retweets 1 like
WASM developed in W3C CG (similar to WICG) & standardised at W3C as standalone document: https://www.w3.org/wasm/
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.