Go to, let us go down, and there confound their language, that they may not understand one another's speech.
Genesis 11:7, The Bible
I was wandering round the web recently and stumbled upon an article about the death of Web SQL. I couldn't ask for a better article.
In this blog post, I would like to dissect the downfall of Web SQL.
Web SQL almost made it
Every other (relevant) browser had implemented Web SQL already. Google Chrome was first and then Safari. But there was one stubborn one: Mozilla. Thankfully, they stood out and said "No, thanks" to SQL.
Why? A couple reasons:
There were many implementations of SQL
There is no true agreed-upon standard. This would cause frequent changes to APIs on the web, which is a horrible experience for developers and progressive learners (like me).
Imagine having to update your code every couple months because the standard changed, as opposed to once and never again. You might as well you JavaScript frameworks. 😒
It suffered from callback hell
I don't think we would miss code like this on the web (sometimes referred to as callback hell):
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!');
},
);
},
);
Enough said.
Most SQL implementations end up buried in another interface
After SQL is used as a foundation for your database architecture, a common pattern found among developers is to create another layer (e.g an object-relational model or ORM) or library over the SQL layer. In a case like this, it may benefit developers more if the API exposed was more high-level than raw SQL.
Working with a single layer is easier to maintain, instead of working with SQL and another layer on top of it.
Mozilla failed to see its usefulness
Mozilla refused to implement the feature in Firefox stating:
"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."
Wise words from a decent browser vendor.
So what can we use instead?
IndexedDB is the answer. I haven't really used it myself, but I don't think it would be more difficult than SQL.
Of course, for people that still want to use SQL, there is the WASM option available maintained by the open-source community. 😒
The bottom line
If the web can cut out bloat, so can you. Get rid of something you don't need today.
Bloat always falls off like how Adobe Flash and Silverlight did on the web. Dispose of it before it sinks your ship.
More resources
- Web Storage and SQL - Vladimir Vukićević
- Web SQL in Memoriam - Nolan Lawson
- IndexedDB - W3 working draft