3 ms·

Which was the right choice, web standards shouldn't be tied to a single project.

by doliveira 4y ago

LAC-Tech 4y ago
Making a standard for WebSQL would have been the path of least resistance.
- matharmin 4y ago
  SQLite is a massive library, with a lot of functionality and optional extensions, and behaviour is added or changed over versions. Codifying all the behaviour into a standard would be a massive effort. And then you're either stuck on that version of SQLite, or your standard depends on what an external project is doing with new releases - which is really not what you want for a web standard. Alternatively, you need to pick a small stable subset of SQLite functionality to expose. But that would mean you can't just use plain SQLite anymore - you either need to modify it significantly, or need to wrap it somehow. Which either way adds a lot of overhead again.
simula67 4y ago
Usually standards will have holes. Therefore, it is necessary to ask: what happens when a competing standard notices a hole in the current standard? In this case, it is better to have a reference implementation, matching which, the competing implementation should have programs that depend on the standard to continue to work. Therefore, tying a standard to a reference implementation, especially one as reputed as SQLite, might not have been a bad outcome overall.
brigandish 4y ago
It's an open source project, they could've forked it and got their wish to keep the API unaffected by any changes to SQLite. This blog post[1], this amazing blog post gives us all the insight needed to know this was going to go badly. The bit about whiteboarding a replacement, is that better or worse than believing Javascript is really a replacement for SQL? Or that IndexedDB is somehow elegant? I can't tell, the whole thing makes me cringe. [1] https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

Which was the right choice, web standards shouldn't be tied to a single project.

LAC-Tech 4y ago

Making a standard for WebSQL would have been the path of least resistance.

matharmin 4y ago
SQLite is a massive library, with a lot of functionality and optional extensions, and behaviour is added or changed over versions. Codifying all the behaviour into a standard would be a massive effort. And then you're either stuck on that version of SQLite, or your standard depends on what an external project is doing with new releases - which is really not what you want for a web standard. Alternatively, you need to pick a small stable subset of SQLite functionality to expose. But that would mean you can't just use plain SQLite anymore - you either need to modify it significantly, or need to wrap it somehow. Which either way adds a lot of overhead again.

simula67 4y ago

Usually standards will have holes. Therefore, it is necessary to ask: what happens when a competing standard notices a hole in the current standard? In this case, it is better to have a reference implementation, matching which, the competing implementation should have programs that depend on the standard to continue to work. Therefore, tying a standard to a reference implementation, especially one as reputed as SQLite, might not have been a bad outcome overall.

brigandish 4y ago

It's an open source project, they could've forked it and got their wish to keep the API unaffected by any changes to SQLite. This blog post[1], this amazing blog post gives us all the insight needed to know this was going to go badly. The bit about whiteboarding a replacement, is that better or worse than believing Javascript is really a replacement for SQL? Or that IndexedDB is somehow elegant? I can't tell, the whole thing makes me cringe. [1] https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...