Warning: clicking "execute" on the demo page made my machine unresponsive and caused the hard drive to thrash for about five minutes before I could finally kill chrome.exe (I'm running a recent version on the Chrome beta channel).

As mentioned in the article, this could be adapted to make a useful polyfill for those browsers which don't offer SQLite access natively.

I may be wrong, but I doubt there are people using WebSQL storage as an in memory database that will be wiped out as soon as the page is closed.

It does open up some really interesting scenarios, though. For instance, I know a company that displays a large amount of data to it's users, so sticking that in WebSQL is useful to them as it makes that data easily queryable. However, since data is their thing they don't want it to persist!

I understand when this is done in a server, where you have control of how big your instance can be, but wouldn't that put too much memory pressure on the browser? What if the browser client is 32-bit? Even in Chrome where each page has a separate process one can make it go out of memory.

I think he was referring to the data manipulation capabilities of SQL, things like GROUP BY and WHERE and ORDER BY that can be offloaded to the client, not as a data caching benefit.

For a second I thought polyfill, as in polygon fill :)

From the [readme](https://github.com/kripken/sql.js/blob/master/README.markdow...):

>sql.js is a port of SQLite to JavaScript, by compiling the SQLite C code with Emscripten.

sql.js itself is 1 line of (incomprehensible) code, 907kB in size.

Uh, wow.

Could this be embedded inside NodeJS thus eliminating the need for a driver?

I'd much rather use a driver than use this. Both require installing 3rd-party packages, so why would you want to do this?

It would be interesting to see the performance of Emscripten SQLite.

Can node.js and the V8 engine itself be compiled to JS? Could be interesting for sandboxing.

>I'd much rather use a driver than use this. Both require installing 3rd-party packages, so why would you want to do this?

If you're running Windows and can't compile the existing driver.

Well for one, this SQLite.js is completely useless without persistence. All you need is some way to get the contents of the database and save it to a file.

That way if you have some new type of architecture that's not supported by SQLite, but you do have a JavaScript VM available you could really easily whip up an SQLite based app without going to the trouble of porting SQLite itself.

It would be nice if you could bake in schema and data with SQL.js itself; it might be useful for querying static data, such as a local auto-complete.

not sure how useful this is, is the database stored in memory? how is it persistent? also non-blocking access is key otherwise you can easily freeze the UI.

in memory data bases can be very useful! they allow you to slice and dice and aggregate data without you having to write the logic to do that yourself.

I'm guessing this is in memory, the main purpose would be for you to use sqlite in the browser since node already has a sqlite driver, as such, IO blocking is not an issue because there is no IO, it can block the same way that cpu intensive code can block however

You can avoid blocking by running SQL.js in a Web Worker.

I think it's memory for now, but I'm hoping for an IndexedDB backend as a polyfill for WebSQL. As for non-blocking... that's what Web Workers are for :)

Actually, I'd love to be able to write SELECT queries in Javascript that were identical to the queries that I write on the server. Yeah, the data comes from an AJAX-JSON call, but then I deal with it exactly the same. I'd love that.

great for teaching SQL, perhaps? super easy example queries, etc.