5 ms·

Looks like it's just an ORM for SQLite. Isn't SQLite too large to be included in the web?

radex 8y ago
Yeah :/ There used to be this thing called Web SQL (which really… was SQLite)… but… people didn't like it and it didn't catch on. So on the web, Watermelon uses LokiJS, which isn't perfect, but still works well.
- aikah 8y ago
  > but… people didn't like it and it didn't catch on. Mozilla didn't like, developers liked it. Mozilla's excuse was "which SQL spec?" which could have been solved with a bit of work. Same as the File System API proposals by google. I'm sorry but indexed-db is not a replacement for these 2. indexed-db is slow and inefficient when it comes to data storage and is horrible to query.
  - radex 8y ago
    Agreed! IDB is simpler in some ways, but having a real relational database is a lot better for many advanced applications — and also can be more easily used for porting to different platforms, since you can run SQLite on any native platform
  - invaliduser 8y ago
    IndexedDB used to be slow, but is it still yet? Not so sure, performance does not seem that bad (see http://reyesr.github.io/html5-storage-benchmark/ http://reyesr.github.io/html5-storage-benchmark/ ) Do you have some benchmark that shows it is indeed slow as of today?
  - detaro 8y ago
    Wanting a specified query language for a database API isn't really an excuse IMHO. (and if it really were just "a bit of work", one has to ask why the proposers then didn't bother to just do that. As cool as sqlite is, tying browsers to a specific version of it seems questionable)
- garyclarke27 8y ago
  WebSQL was killed by Mozilla and Microsoft. A huge idiotic mistake, probably related to the anti RDBMS NOSQL sentiment and fashion at that time. Browsers should ignore this crazy decision and keep (or add) SQLite in the browser - is still in Chrome but deprecated. SQLite is faster and way more capable than Indexdb and free and open source and runs on all platforms and devices - at least keep it as an option.
  - WorldMaker 8y ago
    Mozilla and Microsoft both agreed that the web needs standards that are easy to implement multiple times, otherwise you wind up with another IE6 compatibility nightmare situation. Even though SQLite is open source, there's still only one SQLite. If browsers had to embed SQLite, then the web would have to deal with compatibility issues from SQLite bugs for decades. It doesn't matter that IndexedDB is less capable than SQLite, it matters that IndexedDB is a well defined standard that can be easily implemented and optimized independently by each browser. It was polyfillable on day one on Chrome's SQLite install, and the other browsers were free to choose where and how to implement IndexedDB. Also, IndexedDB has gotten quite fast in recent browser versions and is only getting faster, thanks to the browsers being able to compete on how they optimize it (versus all of them trying to pass competing PRs to SQLite, or working on increasingly divergent forks of it). A goal for IndexedDB was that it might be low level enough that you could build RDBMS database APIs on top of it (whereas you're hard pressed to build certain types of key/value stores or document stores more directly on top of SQLite). The Browsers weren't anti-RDBMS, they were anti-lock-in to a single vendor's bugs. Microsoft learned from their IE mistakes, and don't want Chrome to repeat them (as hard as Google sometimes seems to be trying to make the same mistakes).
    - garyclarke27 8y ago
      Yes standards are great and SQL is a fine example of this, but the standards don’t make anything - developers make stuff from tools and the software they write or build upon. It is stupid to handicap a browser, to throw away an incredibly useful, already made, battle tested piece of software (SQLite) just for the sake if the almighty standard! And to replace it with a feeble slow key value db. So we now have the ridiculous situation of umpteen man hours being wasted reinventing the wheel, trying to build relational databases on top of IDB, it’s crazy.
- dvlsg 8y ago
  I worked on an application which was essentially a multi master, offline capable, synchronizing app that utilized websql heavily. Websql wasn't perfect (it was essentially an old version of sqlite, I think), but as a whole it worked pretty well. Was sad to see it die.
p0peax 8y ago
In WatermelonDB's case, I bet most people will run it using React Native (ie mobile apps for iOS and Android), so that wouldn't really be an issue. On the other hand, sql.js (https://github.com/kripken/sql.js/ https://github.com/kripken/sql.js/) packs to about 2,6MB (see http://kripken.github.io/sql.js/js/worker.sql.js http://kripken.github.io/sql.js/js/worker.sql.js). I don't know about performance under heavy use of that. I don't know what SQLite backend WatermelonDB uses from ReactJS either.

Yeah :/ There used to be this thing called Web SQL (which really… was SQLite)… but… people didn't like it and it didn't catch on. So on the web, Watermelon uses LokiJS, which isn't perfect, but still works well.

aikah 8y ago
> but… people didn't like it and it didn't catch on. Mozilla didn't like, developers liked it. Mozilla's excuse was "which SQL spec?" which could have been solved with a bit of work. Same as the File System API proposals by google. I'm sorry but indexed-db is not a replacement for these 2. indexed-db is slow and inefficient when it comes to data storage and is horrible to query.
- radex 8y ago
  Agreed! IDB is simpler in some ways, but having a real relational database is a lot better for many advanced applications — and also can be more easily used for porting to different platforms, since you can run SQLite on any native platform
- invaliduser 8y ago
  IndexedDB used to be slow, but is it still yet? Not so sure, performance does not seem that bad (see http://reyesr.github.io/html5-storage-benchmark/ http://reyesr.github.io/html5-storage-benchmark/ ) Do you have some benchmark that shows it is indeed slow as of today?
- detaro 8y ago
  Wanting a specified query language for a database API isn't really an excuse IMHO. (and if it really were just "a bit of work", one has to ask why the proposers then didn't bother to just do that. As cool as sqlite is, tying browsers to a specific version of it seems questionable)
garyclarke27 8y ago
WebSQL was killed by Mozilla and Microsoft. A huge idiotic mistake, probably related to the anti RDBMS NOSQL sentiment and fashion at that time. Browsers should ignore this crazy decision and keep (or add) SQLite in the browser - is still in Chrome but deprecated. SQLite is faster and way more capable than Indexdb and free and open source and runs on all platforms and devices - at least keep it as an option.
- WorldMaker 8y ago
  Mozilla and Microsoft both agreed that the web needs standards that are easy to implement multiple times, otherwise you wind up with another IE6 compatibility nightmare situation. Even though SQLite is open source, there's still only one SQLite. If browsers had to embed SQLite, then the web would have to deal with compatibility issues from SQLite bugs for decades. It doesn't matter that IndexedDB is less capable than SQLite, it matters that IndexedDB is a well defined standard that can be easily implemented and optimized independently by each browser. It was polyfillable on day one on Chrome's SQLite install, and the other browsers were free to choose where and how to implement IndexedDB. Also, IndexedDB has gotten quite fast in recent browser versions and is only getting faster, thanks to the browsers being able to compete on how they optimize it (versus all of them trying to pass competing PRs to SQLite, or working on increasingly divergent forks of it). A goal for IndexedDB was that it might be low level enough that you could build RDBMS database APIs on top of it (whereas you're hard pressed to build certain types of key/value stores or document stores more directly on top of SQLite). The Browsers weren't anti-RDBMS, they were anti-lock-in to a single vendor's bugs. Microsoft learned from their IE mistakes, and don't want Chrome to repeat them (as hard as Google sometimes seems to be trying to make the same mistakes).
  - garyclarke27 8y ago
    Yes standards are great and SQL is a fine example of this, but the standards don’t make anything - developers make stuff from tools and the software they write or build upon. It is stupid to handicap a browser, to throw away an incredibly useful, already made, battle tested piece of software (SQLite) just for the sake if the almighty standard! And to replace it with a feeble slow key value db. So we now have the ridiculous situation of umpteen man hours being wasted reinventing the wheel, trying to build relational databases on top of IDB, it’s crazy.
dvlsg 8y ago
I worked on an application which was essentially a multi master, offline capable, synchronizing app that utilized websql heavily. Websql wasn't perfect (it was essentially an old version of sqlite, I think), but as a whole it worked pretty well. Was sad to see it die.

p0peax 8y ago

In WatermelonDB's case, I bet most people will run it using React Native (ie mobile apps for iOS and Android), so that wouldn't really be an issue. On the other hand, sql.js (https://github.com/kripken/sql.js/ https://github.com/kripken/sql.js/) packs to about 2,6MB (see http://kripken.github.io/sql.js/js/worker.sql.js http://kripken.github.io/sql.js/js/worker.sql.js). I don't know about performance under heavy use of that. I don't know what SQLite backend WatermelonDB uses from ReactJS either.