WebSQL对浏览器的支持不断增加。它的未来是什么？

Question

我已经四处查看，发现WebSQL的未来似乎有些艰难。

一方面，由于实际上每个实际实现都只使用SQLite3，因此它显然被广泛视为一种解决方案，因为该规范本身大量借鉴了SQLite3的设计语义，如果不专门使用SQLite3 将非常棘手。。

另一方面，自2017年2月起，所有主流浏览器似乎都支持它（http://caniuse.com/#search=websql）-Chrome已经有很长的历史了，它是在IE11 Edge 14中引入的，Firefox 50和Safari10。移动支持似乎也在积极发展（现在，只有注释说明它在某些三星手机上由于某些原因无法使用）。

IndexedDB背后的理论确实是有道理的：这是一个崭新的标准，不与任何现有库绑定，供应商可以设计自己的实现，进行竞争并避免供应商/库锁定。但是，我陷入了IndexedDB最不利的方面之一：由于实现开销，其抽象设计的性能似乎绝对是灾难性的。

http://scaljeri.github.io/indexeddb-vs-websql/v2.0.0/index.html是一键式IndexedDB-vs-WebSQL决战。我将其设置为10000个项目（一个相当适中的数字），并尝试使用我的ThinkPad T43-具有2GB RAM的单核2GHz PentiumM。

首先，除了运行Chromium之外，什么都没有执行，大多数选项卡都已挂起，其余选项卡未使用任何CPU：

在IndexedDB的整个“插入”时间内，该选项卡使用100％CPU，并且系统通常无法使用。（我可以浏览一下-屏幕重绘的速度确实很慢-但我并不是为了获得准确的基准）。

当我有很多其他事情发生时，我也碰巧在使用该选项卡，并且系统恰好要交换死机（在这台特定的机器上发生了很多事情）：

然而，在整个过程中，WebSQL的性能令人难以置信。即使在系统进行大量交换（到较慢的HDD）时，插入一排行也需要三秒钟，并且系统I / O受到很大影响。（注意：默认情况下，我知道SQLite3会将所有数据强制刷新到磁盘上以确保完整性，但是我不确定Chrome的实现是否为WebSQL禁用了此选项。）

在https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/（自2015年9月起）完成的基准测试似乎与我在此处介绍的内容基本一致；它表明，在2013年的Macbook Air上，IndexedDB的性能明显比WebSQL差。

考虑到这些考虑因素，我有两个问题。

1. WebSQL 作为Web标准的实际未来是什么？SQLite3可以在任何地方（它是ANSI C）运行，并且WebSQL似乎得到了广泛支持（？）。

   我的问题本来是要专门询问有关Chrome扩展程序的支持（请参阅下一点），但是现在我考虑了一下，如果我想要替代localStorage（及其5MB的限制），我想使用WebSQL作为主要解决方案，而很少（如果曾经）使用过IndexedDB或localStorage作为后备。通过这种方法，我成功的机会是什么？

2. 浏览器供应商是否有可能很快放弃对网站和/或扩展的WebSQL支持？

   我正处于Chrome扩展程序的设计初期，该程序需要存储可能大量的信息-它将管理历史记录/书签/等，这些数据将永远增长而永不缩减。我要在所有计算机上使用此扩展，包括上面显示的基准测试中的T43。

   在我看来，这是WebSQL还是什么都没有；我不同意IndexedDB。如果WebSQL看起来将要消失，我将在Go或类似的服务器上制造一个小型应用服务器，然后简单地与之交谈。

   同样，如果有一天WebSQL从Chrome随机“离开”，即使Web支持消失了，对它的扩展支持也将继续吗？