Irrelevance for whom? Maybe not being able to use the web as a tool, to compete with native platforms makes it irrelevant for Google, but Google doesn’t speaks for everyone. Without engine diversity the web is no longer open, and that is its largest appeal over native.
-
-
Replying to @Kevin_Kamimura @RickByers and
Engine diversity absolutists need to describe what concrete benefits it provides that can't be achieved other ways in the medium-term (e.g., OSS forking, which has created huge divergence in the KHTML-lineage engines)
8 replies 0 retweets 2 likes -
Replying to @slightlylate @Kevin_Kamimura and
This is unworthy of you, Alex.
1 reply 0 retweets 7 likes -
Replying to @torgo @Kevin_Kamimura and
Asking that we understand our values, rather than simply using them as a cudgel? I hope not.
1 reply 0 retweets 1 like -
Replying to @slightlylate @torgo and
FWIW, I can make a strong case for engine diversity (ceteris paribus), but not one that trumps platform competitiveness. The mental exercises to demonstrate where you personally come down on this aren't hard to conjure.
2 replies 0 retweets 1 like -
Replying to @slightlylate @torgo and
In plain language, Web competes with Native. Google has a native platform but with as little lock in as possible (no hardware, payments nor browser lock in). Apple has a native platform with complete hardware, revenue and browser lock-in. Which do you think wants Web to win? 1/2
2 replies 2 retweets 6 likes -
Replying to @mikesherov @slightlylate and
Yeah Apple profits from native dominance, and Google profits from the web dominating (more adssss on mobile devices == fatter profits for G). Neither side should be taken at face value here.
2 replies 0 retweets 3 likes -
Replying to @AdamRackis @mikesherov and
And damn Google would look a lot fucking better if they were using their browser dominance to also strong-arm in features that help application developers. But nah - all web component stuff that's nicely designed to allow generic leaf-level drop-in "things" (like ads)
2 replies 0 retweets 0 likes -
Replying to @AdamRackis @slightlylate and
This is a ridiculous assertion. The fact that you don't like WC (and neither do I) doesn't mean they aren't helping application developers. So easy to point to mistakes. There is a mountain of stuff happening, each with their noisy detractors saying "no, do my thing instead!"
2 replies 0 retweets 2 likes -
Replying to @mikesherov @AdamRackis and
While I'm not a big fan of WC either, it's also a little narrow to say Chrome hasn't helped application developers. IntersectionObserver/ResizeObserver were both Chrome first and I'm so glad Google pushed it through early
1 reply 0 retweets 5 likes
When @ElliottZ, @ojanvafai, and I designed that, we had data in hand (thanks to @KenjiBaheux) and a looming deprecation that was about to make websites super slow. Debated endlessly about OT (decided against), but we moved because developer & user needs trump implementer needs.
-
-
Replying to @slightlylate @chrisdhanaraj and
Also fwiw ResizeObserver was designed with feedback from
@othermaciej and@cssrossen. The algorithm to prevent cycles was in response to their concerns about infinite loops. Apple may have taken a long time to ship it: https://webkit.org/blog/9997/resizeobserver-in-webkit/ … but we certainly talked to them.1 reply 0 retweets 4 likes -
Replying to @ElliottZ @slightlylate and
I don’t remember personally giving feedback on it but it’s possible! Or it might have been a different WebKit person. AFAIK neither Observer was pushed through in the face of objections or neglected feedback, unlike WC0 or the OP.
1 reply 0 retweets 3 likes - 3 more replies
New conversation -
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.