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.
-
-
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
The difference here, Adam, is that the other dominant browser (Safari) has an economic incentive to maintain a gap between the capabilities of web and native. Competition isn't a bad thing.
1 reply 0 retweets 1 like -
Replying to @davidbrunelle @RickByers and
Adam Rackis Retweeted Rich Harris
Yeah Apple's crap in lots of ways (no iOS service workers outside Safari?! fucking anti-trust goddamnit). But this argument would have a LOT more credence if Apple wasn't pointing to absolutely legit problems with this api.https://twitter.com/Rich_Harris/status/1220479580298977281 …
Adam Rackis added,
Rich HarrisVerified account @Rich_HarrisReplying to @BurialOfTheDeadasync function add_this_stylesheet(href) { document.aSS = [...document.aSS, await import(href)]; } add_this_stylesheet('./foo.css'); add_this_stylesheet('./bar.css'); Whichever stylesheet comes over the network first will get blown away by the second one2 replies 0 retweets 0 likes -
Replying to @AdamRackis @davidbrunelle and
...and isn't proposing compatible extensions or surface API to cover async cases, but is instead demanding breaking change while not shipping an alternative.
1 reply 0 retweets 1 like -
Replying to @slightlylate @AdamRackis and
Why would they ship a non-agreed upon API though when the first (broken) attempt apparently has to stick around for legacy reasons? It’s damned if you do, damned if you don’t.
0 replies 0 retweets 1 like -
Replying to @slightlylate @danbucholtz and
I'm sorry but "they didn't ship an alternative to the thing we want therefore we're gonna ship our broken thing because progress" is a seriously bad take.
1 reply 0 retweets 0 likes -
-
Replying to @davidbrunelle @slightlylate and
Because maybe the thing you want ... isn't a good idea? Maybe the thing you want isn't what other people want, and so they're not gonna do the R&D for your thing, for you—in which case you just have to fix your own thing.
1 reply 0 retweets 0 likes
I invite you to peruse the actual intent thread and the various links from it before casting more baseless aspersions:https://groups.google.com/a/chromium.org/forum/m/?hl=th#!topic/blink-dev/gL2EVBzO5og/discussion …
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.