800+ IT
News
als RSS Feed abonnieren📚 Deprecating and removing Web SQL
💡 Newskategorie: Programmierung
🔗 Quelle: developer.chrome.com
This is a living post that will be updated as the deprecation steps outlined below happen.
The Web SQL Database API, which allows you to store data in a structured manner on the user's computer (internally based on the SQLite database engine), was introduced in April 2009 and abandoned in November 2010. While it was implemented in WebKit (which powers Safari and early versions of Chrome) and remained active in the Blink engine (that powers Chrome after the switch from WebKit), Gecko (which powers Firefox) never implemented this feature and WebKit removed it in 2019.
The World Wide Web Consortium (W3C)
encourages
those needing web databases to adopt
Web Storage API technologies like
localStorage and
sessionStorage, or
IndexedDB. These
technologies show their strengths when it comes to key/value stores and structured data, but
acknowledgely also have weaknesses like the lack of a strong query language. People want SQL on the
web for a reason.
Our intention is to empower developers to create their own solutions for structured storage and we're therefore working with the SQLite team to create a SQLite implementation over WebAssembly. This solution will replace Web SQL.
Web SQL deprecation steps
- [✅ Done.] Web SQL was deprecated and removed for third-party contexts in Chromium 97.
- [📍 We are here.] Web SQL access in insecure contexts is deprecated as of Chromium 105 at which time a warning message will be shown in the Chrome DevTools Issue panel.
- [🔮 In the future.] Web SQL access in insecure contexts will be completely removed in a later milestone.
- [🔮 In the future.] The final step will be to remove Web SQL completely in all contexts, but no date has been set for this step yet.
Where to go from here
As pointed out in the introduction,
Web Storage API technologies like
localStorage and
sessionStorage, or the
IndexedDB standard are
good alternatives in many, but by far not all cases.
We're therefore working with the SQLite community on a replacement for Web SQL based on SQLite implemented in WebAssembly (Wasm), which will be released in the near future. For developers looking for a drop-in replacement, we're investigating if a shim script can be provided. The article will be updated once the replacement is ready.
Rationale for leaving storage to web developers
With the advent of Wasm, SQL or NoSQL solutions can come to the web. One example is DuckDB-Wasm, another is absurd-sql. Based on these creations, we feel that the developer community can iterate on and create new storage solutions faster and better than browser vendors.
We're not planning to just remove Web SQL. In fact, we're planning to replace it with something that will be maintained by the open-source community, served as a package that can be updated at will—without the burden of introducing fixes and new features directly into browsers. Our objective really is to let developers bring their own database to the web.
What's more, we're hoping that this example will help a new ecosystem of open-source databases to flourish! The release of file system access handles finally provides the new primitive on which custom storage solutions can be built.
Reasons for deprecating Web SQL
Sustainability and security concerns
The Web SQL specification cannot be implemented sustainably, which limits innovation and new functionality. The last version of the standard literally states "User agents must implement the SQL dialect supported by Sqlite 3.6.19". SQLite was not initially designed to run malicious SQL statements, yet implementing Web SQL means browsers have to do exactly this. The need to keep up with security and stability fixes dictates updating SQLite in Chromium. This comes in direct conflict with Web SQL's requirement of behaving exactly as SQLite 3.6.19.
API shape
Web SQL also is an API that shows its age. Being a child of the late 2000s, it's a great example of "callback hell", as the code sample (courtesy of Nolan Lawson) below impressively demonstrates. As you can see, the SQL statements (using the SQLite SQL dialect) are passed as strings to the database methods.
openDatabase(
// Name
'mydatabase',
// Version
1,
// Display name
'mydatabase',
// Estimated size
5000000,
// Creation callback
function (db) {
db.transaction(
// Transaction callback
function (tx) {
// Execute SQL statement
tx.executeSql(
// SQL statement
'create table rainstorms (mood text, severity int)',
// Arguments
[],
// Success callback
function () {
// Execute SQL statement
tx.executeSql(
// SQL statement
'insert into rainstorms values (?, ?)',
// Arguments
['somber', 6],
// Success callback
function () {
// Execute SQL statement
tx.executeSql(
// SQL statement
'select * from rainstorms where mood = ?',
// Arguments
['somber'],
// Success callback
function (tx, res) {
// Do something with the result
var row = res.rows.item(0);
console.log('rainstorm severity: ' + row.severity + ', my mood: ' + row.mood);
},
);
},
);
},
);
},
// Error callback
function (err) {
console.log('Transaction failed!: ' + err);
},
// Success callback);
function () {
console.log('Transaction succeeded!');
},
);
},
);This code is obsolete. Don't use it in practice.
If you were to run this code and inspect the created table with Chrome DevTools, this is the result:
Lack of implementer support
Apart from the arcane API shape (at least from today's point of view), Mozilla had many concerns about Web SQL being built upon SQLite:
"We don't think [SQLite] is the right basis for an API exposed to general web content, not least of all because there isn't a credible, widely accepted standard that subsets SQL in a useful way. Additionally, we don't want changes to SQLite to affect the web later, and don't think harnessing major browser releases (and a web standard) to SQLite is prudent."
You can read about Mozilla's concerns in former Mozillan Vladimir Vukićević's blog post. For some more history, check out the W3C Web Applications Working Group minutes (and, if you really want to go into the details, read the IRC logs) and the mailing list archives). Additionally, Nolan Lawson's blog post provides a good overview of what happened.
Feedback
If you have any concerns about the deprecation steps communicated in this post, please let us know on the blink-dev mailing list. Membership in this group is open to anyone, and anyone is allowed to post.
Related links
- All deprecations and removals in Chromium
- ChromeStatus entry: Deprecate and remove WebSQL in third-party contexts
- ChromeStatus entry: Deprecate and remove WebSQL in non-secure contexts
- Intent to Deprecate and Remove: WebSQL in third-party contexts
- Intent to Deprecate and Remove: WebSQL in non-secure contexts
- Chromium issue: Deprecate and remove WebSQL in third-party contexts
- Chromium issue: Deprecate and remove WebSQL in insecure contexts
- Chromium issue: Deprecate and remove WebSQL (Window#openDatabase)
Acknowledgements
This article was reviewed by Joe Medley and Ben Morss, and Joshua Bell. Hero image by Jan Antonin Kolar on Unsplash.
...