Deprecation message for WebSQL

[Ayu Ishii]

Hi Blink API Owners!

The Chrome Storage team has been working to deprecate WebSQL for a while now. And while it has been discouraged to show deprecation messages before having an Intent to Deprecate with a target milestone, we were wondering if we can have an exception for WebSQL.

While we’ve done what we can to communicate this deprecation so far [1], there are probably a lot of developers that do not actively follow our latest announcements. And having gone through deprecations for our legacy quota APIs, our experience is that deprecation messages are effective in informing them. With the recent release of SQLite-on-WASM over OPFS, which we are publicizing as our alternative, we believe this is the right time to extend our reach to inform developers.

We’re trying to perform this deprecation in a way that's particularly considerate of developers' needs. We’ve reached out to Enterprise teams at Chrome, ChromeOS, Microsoft and Salesforce. We’ve worked with internal teams to ensure their partners are informed. We’ve scoured the web for usage, getting in contact with standard libraries where we've discovered dependencies.

At the same time, we know migration takes time. Enterprises in particular may require 18-24 months. Working with internal partners to move off of WebSQL has taken us over a year, after telegraphing its demise for years prior. It’s simply hard to reach developers all over the world, and we want to get the word out by any means at our disposal. 

I think the deprecation message could help other developers plan early for their potentially large migration, prepare accordingly for the deprecation trial, and ultimately drive usage down. We plan to update this blog as we proceed through the steps with further timeline, and publish migration guidance to SQLite-on-WASM in the coming months. 

Please let me know your thoughts!

Best,
Ayu

[1] Communications

• 2021 Nov - BlinkOn talk discussing the future of WebSQL

• 2021 Nov - The State of WebSQL in Chromium published

• 2022 Aug - Chrome Dev blog published

• 2022 Aug - Analyzed usage from UKM and HTTP Archives and working with the WEC team and Chrome OS Enterprise/Education/Kiosk/Consumer teams, as well as Microsoft and Salesforce to warn their partners

[Yoav Weiss]

Apologies if this was already covered in other contexts, but a few questions:

• What does current usage look like? Do we have use counters?
• Did you try UKM analysis and targeted outreach to large users of the API?
• Can you guesstimate a targeted removal date given current usage?

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/5352f1bb-dc2b-426d-b78e-7d871eec51f3n%40chromium.org.

[Ben Morss]

Yes, we've engaged in an extended effort to locate and contact developers who this would affect. We did a UKM analysis, and we've also been busy querying HTTP Archive.

So far, we only know of one major company that's using WebSQL for database storage. Everyone else we've found is using it because they've included a library that's doing feature detection or browser sniffing, or that's using it as backup for simple key-value pairs in case other storage facilities somehow don't work. I've written scripts that use regular expressions to identify such JS libraries. These helped us set a date for removing another old feature, webkitStorageInfo. We need to finish this analysis on the top sites found via UKM and those found using HTTP Archive. We expect to complete this analysis in December.

In the meantime, none of the Enterprise teams we've talked to at Chrome, ChromeOS, Microsoft or Salesforce have found any WebSQL use among their partners. Nor have the other partner-focused Google teams.

Ben

[Ayu Ishii]

For UserCounter data, we follow these counters here.

- OpenWebDatabase - Risks over-counting, because openDatabase() is exposed on the Window and Worker global objects
- V8SQLTransaction_ExecuteSql_Method - Most accurate counting, as executeSql() is fairly deep in the object graph -- openDatabase() -> {changeVersion() / readTransaction() / transaction() } -> executeSql().

These show around 0.3-0.4% of page loads as of November, which is still high. 
We anticipate this to go down a little more in the next few months as we (hopefully) finish supporting internal partners off of the API.
I'm not sure how to give a good guesstimate given this, but would appreciate any guidance.

Best,
Ayu

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-discuss+unsub...@chromium.org.

[Yoav Weiss]

On Tue, Nov 22, 2022 at 4:39 PM Ben Morss <mo...@google.com> wrote:

Yes, we've engaged in an extended effort to locate and contact developers who this would affect. We did a UKM analysis, and we've also been busy querying HTTP Archive.

So far, we only know of one major company that's using WebSQL for database storage. Everyone else we've found is using it because they've included a library that's doing feature detection or browser sniffing

Feature detection is good. Browser sniffing is bad. (generally in life)

Any reason to expect browser sniffing libraries to update themselves once we unship? Could you split those two populations?

 

, or that's using it as backup for simple key-value pairs in case other storage facilities somehow don't work. I've written scripts that use regular expressions to identify such JS libraries. These helped us set a date for removing another old feature, webkitStorageInfo. We need to finish this analysis on the top sites found via UKM and those found using HTTP Archive. We expect to complete this analysis in December.

Would also be interesting to include in this analysis the partners that Ayu mentioned that are planning to move over to use another API, and proactively subtract their usage numbers from the overall and see where it gets you.

[Daniel Bratell]

I want to add that deprecation messages (or Issues as they are called now) without an end date have turned out to be non-effective in driving down usage. Too many systems and tools have deprecations that don't mean anything and only an end date seems to really get the message across, that something is going to disappear.

And since deprecations without end dates are so bad at reducing use, typically removal gets delayed and the deprecation message linger for a very long time and more or less becomes invisible to web developers.

In this case we'd want the use to drop by 99% or something in that magnitude which is a lot. Hopefully most of that is just a few large users, but that is not quite guaranteed.

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/566a5895-71cd-4bc5-83c7-aae4deccd68an%40chromium.org.

[Ben Morss]

Point taken about deprecations without end dates. While I was looking into current usage of webkitStorageInfo, I looked around the web to see what people were saying. This was the top result on Google search.

About libraries - @Thomas Steiner been creating issues on their github repos. We'll work with others to get in touch with the libraries as well. So far, I haven't seen a library where removal would change any functionality or throw an error, but we'll keep looking.

After we finish searching for WebSQL usage and analyzing what it's for in December, I can update this thread with results. At that point  choosing a date for removal might well be straightforward.

Ben

To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/5352f1bb-dc2b-426d-b78e-7d871eec51f3n%40chromium.org.

[Chris Harrelson]

My recommendation is to attempt another deprecation with:

* A target milestone you plan to commit to (e.g. version N)

* An accompanying time-limited deprecation (reverse) origin trial advertised widely (version N + M)

This approach worked for several difficult-to-deprecate features in the past. Experience has shown that version N will arrive and some sites will notice breakage, complain, then join the deprecation origin trial as a result. But once they are in the origin trial they know they only have M releases to fix their code.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAA6%2Bj4viwA4ky-noJiV7EPh-Ay%3DbYQXTrJp135vjRUsiTgrYWg%40mail.gmail.com.