3 ms·

WebSql was just about a single open source project - SQLite. IndexedDB seems to move away from the requirement that a standard is based on a product. Also, the

WebSql was just about a single open source project - SQLite. IndexedDB seems to move away from the requirement that a standard is based on a product. Also, the SQL used in WebSql was not standardized.

TazeTSchnitzel 14y ago
Yes. But SQLite 3 is Public Domain, and I expect you could reimplement it in the browser if you really wanted to.
- MatthewPhillips 14y ago
  But the parent's point stands; IndexedDB is just a set of APIs. A browser vendor can implement it on the backend any way they want. Chrome uses LevelDB and Firefox uses SQLite. When WebSQL they were stuck with improving SQLite.
  - ef4 14y ago
    Unfortunately they chose a set of APIs that is strictly weaker than what we have access to via WebSql. When I port from WebSql to IndexDb, I will need to implement in Javascript a bunch of things that sqlite3 is already doing for me in C. I actually started out with a very NoSQL-like architecture on top of WebSql that's closer to the IndexDb model. But when I started taking more advantage of sqlite3 to do the heavy lifting (joins, nested subqueries, etc) I got an order of magnitude better performance. Switching to IndexDb means going back to the slow way.
ef4 14y ago
I agree that those are drawbacks, but they're drawbacks of the standards process used, not the technology itself. They could have standardized around the subset of SQL supported and alleviated those concerns. IndexDB seems to be deliberately dumbed down in capability just to make it easier to describe in a standards document. If we were all suffering from interoperability problems with WebSql there might be an argument for something simpler. But that's not the case -- wherever it's implemented, WebSql works the same. It turns out a good open source implementation makes a really good standard. It leaves no room for ambiguity. And anybody who really wants to do their own implementation has free access to everything they need to know to be compatible. The fact that no one has done so just shows that sqlite3 is already good enough, and it's silly not to just use it.

TazeTSchnitzel 14y ago

Yes. But SQLite 3 is Public Domain, and I expect you could reimplement it in the browser if you really wanted to.

MatthewPhillips 14y ago
But the parent's point stands; IndexedDB is just a set of APIs. A browser vendor can implement it on the backend any way they want. Chrome uses LevelDB and Firefox uses SQLite. When WebSQL they were stuck with improving SQLite.
- ef4 14y ago
  Unfortunately they chose a set of APIs that is strictly weaker than what we have access to via WebSql. When I port from WebSql to IndexDb, I will need to implement in Javascript a bunch of things that sqlite3 is already doing for me in C. I actually started out with a very NoSQL-like architecture on top of WebSql that's closer to the IndexDb model. But when I started taking more advantage of sqlite3 to do the heavy lifting (joins, nested subqueries, etc) I got an order of magnitude better performance. Switching to IndexDb means going back to the slow way.

ef4 14y ago

I agree that those are drawbacks, but they're drawbacks of the standards process used, not the technology itself. They could have standardized around the subset of SQL supported and alleviated those concerns. IndexDB seems to be deliberately dumbed down in capability just to make it easier to describe in a standards document. If we were all suffering from interoperability problems with WebSql there might be an argument for something simpler. But that's not the case -- wherever it's implemented, WebSql works the same. It turns out a good open source implementation makes a really good standard. It leaves no room for ambiguity. And anybody who really wants to do their own implementation has free access to everything they need to know to be compatible. The fact that no one has done so just shows that sqlite3 is already good enough, and it's silly not to just use it.