AppCache and WebSQL are more complicated cases since there is cross-browser support and migration is more difficult due to the mismatch in behavior (declarative vs. procedural; SQL vs. "NoSQL" APIs), so I would not start with these.
--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAA6qCNf44yBSAL9o8k8dbVP9bUiUGnJaBf7OGxTKH5r3nJBDNg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CABc02_Lm2ruRBOfiZDF8SH4gRQABTewi%2BWVSHSAU%2BaeCi_cDyQ%40mail.gmail.com.
Do we have a list of the largest users of those APIs? I think adding further messages along the lines of sync XHR will help exactly nothing to drive down usage :/
It might also be interesting to measure how often somebody has the console open for sites using those APIs, to get an idea about how frequently somebody could potentially see this warning.
On Mon, Jul 30, 2018 at 11:39 PM Jochen Eisinger <joc...@chromium.org> wrote:Do we have a list of the largest users of those APIs? I think adding further messages along the lines of sync XHR will help exactly nothing to drive down usage :/It seems plausible to me that we'd need to spend non-trivial effort to drive usage down. Until we have the resources, I am hoping for a low-effort way to prevent usage from going up.It might also be interesting to measure how often somebody has the console open for sites using those APIs, to get an idea about how frequently somebody could potentially see this warning.I claim that building a Web app without opening DevTools is similar to writing compilation error-free C++. Possible, but not plausible :)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAA6qCNe%3DAQJaiJOTM7Jt5O0cYgX47Cn3465arUvCYYbmjVBxWA%40mail.gmail.com.
'Victor Costan' via blink-api-owners-discuss <blink-api-ow...@chromium.org> schrieb am Di., 31. Juli 2018, 10:03:On Mon, Jul 30, 2018 at 11:39 PM Jochen Eisinger <joc...@chromium.org> wrote:Do we have a list of the largest users of those APIs? I think adding further messages along the lines of sync XHR will help exactly nothing to drive down usage :/It seems plausible to me that we'd need to spend non-trivial effort to drive usage down. Until we have the resources, I am hoping for a low-effort way to prevent usage from going up.It might also be interesting to measure how often somebody has the console open for sites using those APIs, to get an idea about how frequently somebody could potentially see this warning.I claim that building a Web app without opening DevTools is similar to writing compilation error-free C++. Possible, but not plausible :)I had assumed that new apps don't use those APIs? Do we see usage going up?
--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To post to this group, send email to blink-api-ow...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAA6qCNcDYStgVzB%3DfVG8mA-3Ci29Cu0dpTCo3KVMi_NtDv4sKw%40mail.gmail.com.
It seems plausible to me that we'd need to spend non-trivial effort to drive usage down. Until we have the resources, I am hoping for a low-effort way to prevent usage from going up.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAARdPYfEDYN0%3D3UmBYB6Y8WyogE2u4SA-L0jFuoLcnZF0_HB8A%40mail.gmail.com.
+Eric since this really seems like a "best practices" discussion - so something to discuss with the lighthouse/devtools teams - not API owners. API owner policy is still that we don't do "hopeful deprecations".On Tue, Aug 28, 2018 at 3:35 PM Rick Byers <rby...@chromium.org> wrote:+1 to what Philip has said here.Having some sort of "interop warning" or other devtools/lighthouse UI for warning developers about depending on non-standard behavior seems potentially valuable to me. In general the problem is tough because real apps often feel the need to rely on non-standard feature detection - so just because we see some non-standard API being used usually doesn't mean the application works incorrectly without it (it just falls back to some other standard code path). So we have not yet succeeded in coming up with a general purpose mechanism which we think is worth building. But I personally have no opposition to someone adding a new type of console warning - as long as it doesn't imply a feature WILL be removed before there is a legitimate plan to do so (i.e. a date).It seems plausible to me that we'd need to spend non-trivial effort to drive usage down. Until we have the resources, I am hoping for a low-effort way to prevent usage from going up.I think our collective experience here is that this is ALWAYS exactly that - an empty "hope". Developers often do whatever works - copying code from wherever they can get it etc. We constantly want to convince developers to do things differently, but they know their constraints/trade-offs better than we do and so our hopes are rarely helpful in practice (if we had console warnings for everything we "hoped" developers would change, every website would probably generate thousands of distinct messages). Lighthouse is really our tool for expressing our opinion on best practices. Chrome has to cope with whatever developers choose to do in practice up to the point we can safely make a breaking change in behavior.On Mon, Aug 6, 2018 at 11:56 AM Philip Jägenstedt <foo...@chromium.org> wrote:While deprecation messages don't seem effective in driving down usage, I am very sympathetic to the "booby trap" argument, that some web developers are using these APIs without realizing they're not on a path to interop. This is different from the sync XHR case, which works (but blocks the main thread) everywhere, but we'd like to remove it everywhere if only usage dropped.With https://w3c.github.io/reporting/#deprecation-report web developers will have a way to notice use of deprecated APIs in the wild, so I don't think that devtools being open or not should factor into this, unless I'm misunderstanding the upside of doing that?
I don't think it would hurt to add a new console warning. Lighthouse could surface that information fairly easily.
What are some examples you all are thinking of?
Could we use wpt.fyi data somehow?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAGW2wGH_Pv3ewkJU0kLH2tM%3DabR7imMYCz04yKi6xk0fbsQQWA%40mail.gmail.com.
On Tue, Aug 28, 2018 at 4:54 PM Eric Bidelman <ericbi...@chromium.org> wrote:I don't think it would hurt to add a new console warning. Lighthouse could surface that information fairly easily.
What are some examples you all are thinking of?The two examples Victor (or was it Josh) used earlier were AppCache and WebSQL. I agree these are good ones - it's certainly risky for anyone to take a dependency on these technologies for new development, but they're also not at the point where we can claim to have a concrete plan to remove them. Maybe the nature of being large foundational technologies also makes them more interesting (better cost/benefit tradeoff) than, say, some -webkit-specific gradient syntax or something...Could we use wpt.fyi data somehow?That would be great to aspire to. To be useful in the short run it would probably need some amount of hand-curation and manually mapping of APIs to WPT directories or something. I know Philip and his team have thought about this quite a bit, but it's hard.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAFUtAY9PEZ-_Gxff7G%3DUmv8xx6Zw%2B3ZzKZ%3DY_zmPho7-XV7biQ%40mail.gmail.com.