<p dir="auto">see the screenshot<br>
<a target="_blank" rel="noopener noreferrer nofollow" href="https://user-images.githubusercontent.com/69608605/156706522-63d03927-18a0-4c72-bf9b-e91c86aadecf.png"><img width="1919" alt="image" src="https://user-images.githubusercontent.com/69608605/156706522-63d03927-18a0-4c72-bf9b-e91c86aadecf.png" style="max-width: 100%;"></a></p>
<p dir="auto">❯ deno --version<br>
deno 1.19.1 (release, x86_64-apple-darwin)<br>
v8 9.9.115.7<br>
typescript 4.5.2</p>
<p dir="auto">test.js is</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="// Generated by CoffeeScript 2.6.1
(function() {
  //!/usr/bin/env coffee
  var i, ref;

  ref = [1, 2, 3, 4, 5];
  for (i of ref) {
    console.log(i);
    if (i &gt; 3) {
      throw new Error(i);
    }
  }

}).call(this);

//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoidGVzdC5qcyIsInNvdXJjZVJvb3QiOiIuLiIsInNvdXJjZXMiOlsic3JjL3Rlc3QuY29mZmVlIl0sIm5hbWVzIjpbXSwibWFwcGluZ3MiOiI7QUFBcUI7RUFBQTtBQUFBLE1BQUEsQ0FBQSxFQUFBOztBQUVyQjtFQUFBLEtBQUEsUUFBQTtJQUNFLE9BQU8sQ0FBQyxHQUFSLENBQVksQ0FBWjtJQUNBLElBQUcsQ0FBQSxHQUFJLENBQVA7TUFDRSxNQUFNLElBQUksS0FBSixDQUFVLENBQVYsRUFEUjs7RUFGRjtBQUZxQiIsInNvdXJjZXNDb250ZW50IjpbIiMhL3Vzci9iaW4vZW52IGNvZmZlZVxuXG5mb3IgaSBmcm9tIFsxLi41XVxuICBjb25zb2xlLmxvZyBpXG4gIGlmIGkgPiAzXG4gICAgdGhyb3cgbmV3IEVycm9yIGlcbiJdfQ==
//# sourceURL=/Users/z/rmw/rcp/test/src/test.coffee```"><pre class="notranslate"><code class="notranslate">// Generated by CoffeeScript 2.6.1
(function() {
  //!/usr/bin/env coffee
  var i, ref;

  ref = [1, 2, 3, 4, 5];
  for (i of ref) {
    console.log(i);
    if (i &gt; 3) {
      throw new Error(i);
    }
  }

}).call(this);

//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoidGVzdC5qcyIsInNvdXJjZVJvb3QiOiIuLiIsInNvdXJjZXMiOlsic3JjL3Rlc3QuY29mZmVlIl0sIm5hbWVzIjpbXSwibWFwcGluZ3MiOiI7QUFBcUI7RUFBQTtBQUFBLE1BQUEsQ0FBQSxFQUFBOztBQUVyQjtFQUFBLEtBQUEsUUFBQTtJQUNFLE9BQU8sQ0FBQyxHQUFSLENBQVksQ0FBWjtJQUNBLElBQUcsQ0FBQSxHQUFJLENBQVA7TUFDRSxNQUFNLElBQUksS0FBSixDQUFVLENBQVYsRUFEUjs7RUFGRjtBQUZxQiIsInNvdXJjZXNDb250ZW50IjpbIiMhL3Vzci9iaW4vZW52IGNvZmZlZVxuXG5mb3IgaSBmcm9tIFsxLi41XVxuICBjb25zb2xlLmxvZyBpXG4gIGlmIGkgPiAzXG4gICAgdGhyb3cgbmV3IEVycm9yIGlcbiJdfQ==
//# sourceURL=/Users/z/rmw/rcp/test/src/test.coffee```
</code></pre></div>
<p dir="auto">So far I have been watching node compatibility features, wasm features, and ffi features all to serve one purpose for myself, to expose a a reliable, fast sqlite interface in deno. There are several good sqlite implementations that exist in deno userland thus far:</p>
<ul dir="auto">
<li><a href="https://deno.land/x/sqlite" rel="nofollow">https://deno.land/x/sqlite</a> (a wasm compilation)</li>
<li><a href="https://deno.land/x/sqlite3" rel="nofollow">https://deno.land/x/sqlite3</a> (an ffi binding)</li>
<li><a href="https://github.com/denodrivers/async-sqlite3">https://github.com/denodrivers/async-sqlite3</a> (ffi bindings using rusqlite)</li>
</ul>
<p dir="auto">These projects are usable, but they all have their own pitfalls. The wasm libraries are portable, but suffer a reduction in speed, and their memory usage is capped at 4GB. The FFI libraries are generally faster, but still cannot match native bindings, and have an added difficulty of requiring an external dependency. Developers of FFI libraries also have the headache of dealing with end users using different versions of sqlite underneath their js interface.</p>
<p dir="auto">Here is a small benchmark report given by the <code class="notranslate">async-sqlite3</code> library:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="  insert 10_000 rows in bench.db: 1114.5801ms
  query 10_000 rows in bench.db: 30.3004ms

x/sqlite3
  insert 10_000 rows in bench.db: 1306.1578ms
  query 10_000 rows in bench.db: 163.2021ms

node-sqlite3
  insert 10_000 rows in bench.db: 1165.0645ms
  query 10_000 rows in bench.db: 8.1728ms

better-sqlite3
  insert 10_000 rows in bench.db: 592.1117ms
  query 10_000 rows in bench.db: 11.3483ms

x/sqlite
  insert 10_000 rows in bench.db: 28672.3261ms
  query 10_000 rows in bench.db: 16.8747ms"><pre lang="deno_sqlite3" class="notranslate"><code class="notranslate">  insert 10_000 rows in bench.db: 1114.5801ms
  query 10_000 rows in bench.db: 30.3004ms

x/sqlite3
  insert 10_000 rows in bench.db: 1306.1578ms
  query 10_000 rows in bench.db: 163.2021ms

node-sqlite3
  insert 10_000 rows in bench.db: 1165.0645ms
  query 10_000 rows in bench.db: 8.1728ms

better-sqlite3
  insert 10_000 rows in bench.db: 592.1117ms
  query 10_000 rows in bench.db: 11.3483ms

x/sqlite
  insert 10_000 rows in bench.db: 28672.3261ms
  query 10_000 rows in bench.db: 16.8747ms
</code></pre></div>
<p dir="auto">Wherever I see a javascript interface to sqlite, better-sqlite3 always seems to win out. It uses NAN (Native Abstractions for Node.js). Deno already includes a rusqlite implementation inside it for things like <code class="notranslate">localStorage</code>, so exposing the library to users would not require pulling more dependencies into deno, just exposing more of the underlying systems. I feel (but dont know for certain) that if we had native rust v8 bindings to a library inside deno core, we could achieve some very impressive speeds, and avoid some of the traps that come with wasm compilations.</p>
<p dir="auto">The interface could be very simple, just exposing prepared statements, database open &amp; close and query execution. That alone would allow deno developers to write their own database abstractions with a solid foundation. The existing sqlite library authors do not need to go away if this is implemented,. Of course, an STD implementation of a sqlite database would be fantastic, but I think starting with the building blocks here makes the most sense.</p>
<h2 dir="auto">drawbacks to deno exposing rusqlite</h2>
<p dir="auto">So far as I can tell, here are the arguments against this:</p>
<ol dir="auto">
<li>This is another interface to maintain, and <code class="notranslate">localStorage</code> has its own special considerations, so making rusqlite exposed generically would be difficult</li>
<li>being able to pick and choose your version of sqlite is actually a feature, not a bug. Tying sqlite version to the deno version limits the flexibility of sqlite</li>
</ol>
<p dir="auto">I think these are valid points, but they certainly wouldnt be true for me, but Ill let others speak to their own concerns.</p>