Dancing on the grave of Web SQL

Groups of men and women dancing with each other

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

If you would like to reply to or comment on this blog post, feel free to email me at efe@mmhq.me.