Make precisions in the README

We had several people opening issues because they did’nt understand that sql.js works only in memory.
This should make it clearer that sql.js is not the best choice in node or electron applications.

Fixes #193
Fixes #125
See #196
See #191
... and many others

Author: lovasoa

README.md

@@ -3,8 +3,9 @@
 
 For the impatients, try the demo here: http://kripken.github.io/sql.js/GUI/
 
-sql.js is a port of SQLite to JavaScript, by compiling the SQLite C code with Emscripten.
-no C bindings or node-gyp compilation here.
+*sql.js* is a port of [SQLite](http://sqlite.org/about.html) to JavaScript, by compiling the SQLite C code with [Emscripten](http://kripken.github.io/emscripten-site/docs/introducing_emscripten/about_emscripten.html). It uses a [virtual database file stored in memory](https://kripken.github.io/emscripten-site/docs/porting/files/file_systems_overview.html), and thus **does’nt persist the changes** made to the database. However, it allows you to **import** any existing sqlite file, and to **export** the created database as a [javascript typed array](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays).
+
+There is no C bindings or node-gyp compilation here, sql.js is a simple javascript file, that can be used like any traditional javascript library. If you are building a native application in javascript (using Electron for instance), or are working in node.js, you will likely prefer to use [a native binding of SQLite to javascript](https://www.npmjs.com/package/sqlite3).
 
 SQLite is public domain, sql.js is MIT licensed.