Deprecation warnings w/o removal dates?

[Joshua Bell]

We have a policy that we only show deprecation warning when APIs have a specific removal date. I.e. we will avoid logging "XXX is deprecated and will be removed" and only have "XXX is deprecated and will be removed on MM/YY"

However, there are a class of APIs where there the timeframe for removal is unknown (possibly still years away) based on metrics yet the lack of such a warning is actively harmful to web developers (who unknowingly take a dependency on such APIs given a lack of other documentation) and web users (since the APIs may only work in Chrome).

A handful of storage-centric APIs in this class:

• Quota - only exists in Chrome; existing spec has a scary "Beware!" warning -- if you find the ED. There is a standard replacement (Chrome+Firefox).  Usage 0.4%
  
• WebSQL - only exists in Chrome and Safary; existing spec has a scary "Beware!" warning. Usage 0.6% 
• AppCache - implemented everywhere; existing spec has "This feature is in the process of being removed from the Web platform.... Use service workers instead" Usage 0.3%
• File System - only exists in Chrome; existing spec is basically empty apart from "Work on this document has been discontinued"  Usage 6% 

But despite "knowing" that all of these are deprecated, we don't log anything about these, and new web applications continue to be built using these. Part of this is that we have documentation that still points at these (1) which may be marked deprecated (2, 3) or even ostensibly targeted at apps (4), but the usage may be hidden behind libraries. We have multiple anecdotes of new Google services being built relying on these APIs; when the Chrome team has noticed we've been able to guide the developers to standards-based alternatives with minimal friction, but that only happens when we're lucky.

Obviously, the teams that own these APIs need to invest more in active removal, and help drive developers to better APIs. 

What do the API OWNERS think about warnings for this class of API that don't make the claim "will be removed" but rather indicate that the functionality will not be available in other browsers, and suggest alternate APIs exist? e.g.

"XXX is not standardized and not supported in other browsers."

or ideally:

"XXX is not standardized and not supported in other browsers. Use YYY instead."

Concretely, for Quota:

"webkitStorageInfo is not standardized and not supported in other browsers. Use navigator.storage instead."

"webkitTemporaryStorage is not standardized and not supported in other browsers. Use navigator.storage instead."

"webkitPersistentStorage is not standardized and not supported in other browsers. Use navigator.storage instead."

For FileSystem:

"webkitRequestFileSystem is not standardized and not supported in other browsers. Use caches or indexedDB instead."

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.

Thoughts?

[Victor Costan]

On Mon, Jul 30, 2018 at 1:27 PM Joshua Bell <jsb...@google.com> wrote:

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.

I second Josh's request. I would like to add that I think AppCache and WebSQL are our most dangerous APIs.

Take partial / total cross-browser compatibility. Combine it with the fundamental differences between the "bad" APIs and the "good" APIs, and you get an evil booby trap. Specifically, cross-browser compatibility means that devs won't flag the "bad" APIs during early testing. "Bad" APIs can lead to architectures whose deep assumptions are incompatible with the "good" APIs. So, developers won't realize they're going down a wrong path, and their decisions become very expensive to reverse.

So please, please help us figure out a way to bring alarm signals to Web developers early in the application lifecycle.

Thank you very much,

    Victor

[PhistucK]

What about (additionally?) showing more (deprecation or non standard and similar) warnings by default when the Developer Tools feature is open while viewing a localhost URL (or anything that is mapped to 127.0.0.1, really)?

This is the place that developers will most likely pay attention to the console.

If you want to lessen the noise (sometimes too much, but might cover most cases still), maybe log those only for calls from same-origin sources (the last call in the stack trace is from a same-origin file), if this is assertable.

☆PhistucK

--
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.

[Jochen Eisinger]

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.

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.

[Victor Costan]

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 :)

Thank you,

    Victor

[Jochen Eisinger]

'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?

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]

On Tue, Jul 31, 2018 at 1:13 AM Jochen Eisinger <joc...@chromium.org> wrote:

'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?

We see new usage. I'll follow up separately with the specific data.

    Victor 

[Philip Jägenstedt]

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?

The suggested "not standardized and not supported in other browsers" messages LGTM, importantly they don't make it seem like removal is imminent when it's not.

The usage matters. It would be bad if in the end 20% of page loads had some unactionable warning so that web devs learn to ignore them. I don't know what the magic number is, but 1% seems reasonable.

--

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.

[Rick Byers]

+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.

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.

[Rick Byers]

+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".

[Eric Bidelman]

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?

That said, there are real cases where it's necessary to use a non-standard feature to "get the job done".

Other vendors might not support the API yet, a spec takes years to evolve (flexbox) and we're in a bad

state with 2-3 different versions of the same API, we're between APIs (getUserMedia promises vs. non-promises),

etc. Developers code around the compat issues b/c they need to.

On Tue, Aug 28, 2018 at 12:39 PM Rick Byers <rby...@chromium.org> wrote:

+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?

+1. I'm hoping the Reporting API will help with some of the discovery piece. It also future-proofs b/c you get deprecation/warnings

early and often.

[Rick Byers]

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.

[Eric Bidelman]

Ah I see. So we Lighthouse audits for AppCache and WebSQL that recommend service worker and IDB, respectively.

The reason we decided to add audits for those deprecated APIs is b/c for the reason you mentioned (no one should start

an app today using them) AND because they have viable replacements.

I think warning about these in a recommendation tool like Lighthouse makes sense but I'm not sure about DevTools.

We'd want to point devs to the alternative API to use with some background information. Not sure if all that is possible

with a console warning.

[Rick Byers]

Great! I guess I'm not surprised there's already a LH audit for those two - sorry, I should have checked. It seemed clear to me that Lighthouse was the right tool to provide that guidance around best practices.

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.

[Philip Jägenstedt]

On Tue, Aug 28, 2018 at 11:47 PM Rick Byers <rby...@chromium.org> wrote:

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.

There are lots of ideas in this space, but for dev tools features to warn about any use of Chrome-only APIs, I think the data from http://web-confluence.appspot.com/#!/ and/or https://github.com/mdn/browser-compat-data might be the best. Probably the former, which critically includes information about non-standard APIs.

We can get information about surface-level API support from wpt.fyi as well using the IDL tests (generated from from spec IDL blocks) but I think that VS Code is using the browser-compat-data repo and converging on that and investing in keeping it up-to-date via things like Confluence and WPT might make the most sense.

(For the deprecation messages this thread started from, just working out that it's Chrome-only is a tiny part of the problem.)

 

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.

[PhistucK]

I thought to suggest adding a command line flag, --disable-discouraged-features (or a runtime setting in the Developer Tools, leveraging feature policy with internal values), which removes deprecated as well as discouraged (would have been deprecated had there been a removal date or usage was low in order to start deprecating).

But I guess the same people that use Lighthouse might would use those, so Lighthouse may be the way to go. But some food for thoughts.

(Although, I would have probably used that flag, but I never used Lighthouse until today, due to this discussion)

(Then again, I did not develop web applications that could benefit from Lighthouse much, either because they were small, unimportant personal projects that can be slow or broken without me or others caring much, or because the ones I develop or maintain as an employee have a very different and broken focus of resources)

I remember the Firefox console (before its Developer Tools feature existed) used to show a lot of warnings about discouraged syntax, features and more that I would use to fix my code. But maybe this was just me.

That was about the only thing that was useful to me about Firefox (still, I never used it as a primary browser).

☆PhistucK