This isn't abstract; it's about shipped bits we don't control. A quick example: Service Workers on Google's biggest properties. These are *hugely* latency sensitive services. If rollout of a feature slows things down, that can block a launch. Enter Navigation Preload.
-
-
Replying to @slightlylate @cwiiis
Nav Preload is a feature we designed in collaboration with Facebook and the Site Isolation team as they were looking into the latency impacts of Service Workers. It gets things started much sooner, allowing us to avoid blocking network fetches on (potentially slow) disk.
1 reply 0 retweets 1 like -
Replying to @slightlylate @cwiiis
Google's highest-traffic sites need nav preload to be able to enable Service Workers. This has been communicated to other vendors for a long, long time now. And yet (see the bottom):https://developer.mozilla.org/en-US/docs/Web/API/NavigationPreloadManager …
1 reply 0 retweets 1 like -
Replying to @slightlylate @cwiiis
The result is other vendors telling us how unfair it is that we don't offer these features to their browser. Except we can't. It'd be a worse experience for users if we did! Unlocking progress means both sides need to deliver.
1 reply 0 retweets 1 like -
Replying to @slightlylate
That line of argumentation doesn't fly though, other browsers don't not implement it out of malice for Google's users. There are good reasons others don't just drop everything they're doing to service Google's needs (which is essentially what is being asked for here)
1 reply 0 retweets 0 likes -
Replying to @cwiiis
Nobody needs to be acting with malice here. It only requires a genuine disagreement about priorities and goals to get into the situation I described.
1 reply 0 retweets 2 likes -
Replying to @slightlylate @cwiiis
And it isn't just Google sites. There's a generalized difficulty about listening to customer.
1 reply 0 retweets 1 like -
Replying to @slightlylate @cwiiis
Adding features to browsers isn't just about writing code. Each OSS browser has it's own hierarchy of planning, process, and reviewership. We tried getting new features into WebKit when we were contributing >50% of patches, and it didn't work (hence Blink).
2 replies 0 retweets 1 like -
Replying to @slightlylate @cwiiis
So, for the set of features that are uncontroversial (no matter how that happened), just writing code can be a meaningful improvement. But that doesn't describe situations like Nav Preload where some engines don't prioritize no matter how many huge sites tell them they need it.
1 reply 0 retweets 1 like -
Replying to @slightlylate @cwiiis
And, so we're clear, some fraction of this *is* teams not prioritizing the way I'd prefer. I'll advocate to those teams to do better if/when they're pointed out to me; we have org support to make this situation not suck to the extent the issue isn't missing essential features.
2 replies 0 retweets 1 like
(and yes, performance issues can be essential features)
-
-
Replying to @slightlylate
I don't think anything you've said is unreasonable, but I question in that situation where priorities are disagreed on, even when multiple big sites have agreed on those priorities, that the course of action should just be "go ahead anyway".
2 replies 0 retweets 1 like -
- 1 more reply
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.