undefined | Better HN

0 pointsEvanAnderson4y ago0 comments

My "web scale" bit is snark. The "because it was SQL based" comes from the feeling I got at the time that Mozilla absolutely wouldn't accept anything was SQL-based. I strongly believe anti-SQL attitudes at Mozilla, and little else, are what killed WebSQL.

This is also how I justify my opinion that the "no independent implementations" was more of an afterthought excuse, and less of a primary motivation on Mozilla's part.

(I'm a little pressed on time here, but I could probably find more examples if I had more time to search... Sorry!)

Quoting Jonas Sicking from a W3C IRC log[0]:

> we've talked to a lot of developers

...

> the feedback we got is that we really don't want SQL

Quoting Maciej Stachowiak from the "public-webapps@w3.org" list[1]:

> Hixie has said before he's willing to fully spec the SQL dialect used by Web Database. But since Mozilla categorically refuses to implement the spec (apparently regardless of whether the SQL dialect is specified),

...

> At the face-to-face, Mozilla representatives said that most if not all of the developers they spoke to said they wanted "anything but SQL" in a storage solution.

The comments relating to JOIN in the comments on Mozilla's blog post comparing IndexedDB and WebSQL[2] betray the anti-SQL (and, arguably, anti-relational database) stance at Mozilla.

Mozilla's people didn't like SQL, so any excuse for dismissing WebSQL (or even a simplified SQL dialect that didn't have the "quirks" of SQLite) was a foregone conclusion.

And now here we are shipping >1MB transpiled WASM payloads around when we could have agreed on a query language feature set implemented in native code using a consistent back-end standard storage format.

[0] https://www.w3.org/2009/11/02-webapps-irc

[1] https://lists.w3.org/Archives/Public/public-webapps/2009OctD...

[2] https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-we...

0 comments

roca4y ago

I have no doubt that Jonas told the truth that that's the feedback he got. I was never aware of Jonas or anyone else involved at Mozilla having some kind of "anti-SQL" prejudice.

WebDatabase, with or without a spec, boiled down to shipping SQLite. We didn't want the Web to depend on that. It might even have required shipping a specific version of SQLite to make sure that query planning matches other browsers.

It seems that IndexedDB has turned out poorly for various reasons but one of those reasons is that Chrome has botched their implementation and that's not Mozilla's fault.

TeMPOraL4y ago

> WebDatabase, with or without a spec, boiled down to shipping SQLite. We didn't want the Web to depend on that.

Ironically, all the popular browsers already ship SQLite - they just not expose it directly. So, in a way, the Web already depends on SQLite. So does a lot of other technology - we're talking about one of the, if not the, most widely distributed pieces of software on the planet.

roca4y ago

That's true, but "in a way" does a lot of work there. "In a way" the Web already depends on the C++ standard library, but we aren't exposing that as a JS API.

EvanAndersonOP4y ago

I don't think Jonas was dishonest in any way. I think Mozilla talked to front-end Javascript devs who came from a "NoSQL" background (after all, Javascript devs are what begat "web scale" MongoDB) and who had disdain for SQL. I think that disdain sealed the fate of any SQL-based API in HTML5, irrespective of the involvement of SQLlite.

The "no independent implementations" was certainly a convenient way to dismiss away the already-implemented SQLlite-based solution. It's a valid argument for rejecting SQLlite as the spec, for sure. Implementations notwithstanding it seems like Mozilla was unwilling to even consider anything SQL-based.

The same tone comes out in the "Beyond HTML5: Database APIs and the Road to IndexedDB" Mozilla blog post[0]:

> In order to really get Web SQL Database right, we’d have to first start with defining a meaningful subset of SQL for web applications. Why define a whole other language, when more elegant solutions exist within JavaScript itself?

...

> We were resolved that using strings representing SQL commands lacked the elegance of a "web native" JavaScript API ...

That sounds like the same rhetoric used in the early MongoDB / NoSQL craze days to dismiss RDMS, ACID, JOINs, etc. Never mind that SQL is a battle-hardened DSL that has proven itself to be suitable to the task-- it wasn't "elegant" enough for the front-end devs Mozilla surveyed.

As an aside, I also find the quote from that post very amusing:

> In another article, we compare IndexedDB with Web SQL Database, and note that the former provides much syntactic simplicity over the latter.

The example for a JOIN using IndexedDB in the referenced article[1] looks strained. It really doesn't look like it has "syntactic simplicity" compared to the WebSQL version above it.

[0] https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

[1] https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-we...

j / k navigate · click thread line to collapse

0 pointsEvanAnderson4y ago0 comments

This is also how I justify my opinion that the "no independent implementations" was more of an afterthought excuse, and less of a primary motivation on Mozilla's part.

(I'm a little pressed on time here, but I could probably find more examples if I had more time to search... Sorry!)

Quoting Jonas Sicking from a W3C IRC log[0]:

> we've talked to a lot of developers

...

> the feedback we got is that we really don't want SQL

Quoting Maciej Stachowiak from the "public-webapps@w3.org" list[1]:

...

> At the face-to-face, Mozilla representatives said that most if not all of the developers they spoke to said they wanted "anything but SQL" in a storage solution.

The comments relating to JOIN in the comments on Mozilla's blog post comparing IndexedDB and WebSQL[2] betray the anti-SQL (and, arguably, anti-relational database) stance at Mozilla.

Mozilla's people didn't like SQL, so any excuse for dismissing WebSQL (or even a simplified SQL dialect that didn't have the "quirks" of SQLite) was a foregone conclusion.

[0] https://www.w3.org/2009/11/02-webapps-irc

[1] https://lists.w3.org/Archives/Public/public-webapps/2009OctD...

[2] https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-we...

0 comments

roca4y ago

I have no doubt that Jonas told the truth that that's the feedback he got. I was never aware of Jonas or anyone else involved at Mozilla having some kind of "anti-SQL" prejudice.

It seems that IndexedDB has turned out poorly for various reasons but one of those reasons is that Chrome has botched their implementation and that's not Mozilla's fault.

TeMPOraL4y ago

> WebDatabase, with or without a spec, boiled down to shipping SQLite. We didn't want the Web to depend on that.

roca4y ago

That's true, but "in a way" does a lot of work there. "In a way" the Web already depends on the C++ standard library, but we aren't exposing that as a JS API.

EvanAndersonOP4y ago

The same tone comes out in the "Beyond HTML5: Database APIs and the Road to IndexedDB" Mozilla blog post[0]:

...

> We were resolved that using strings representing SQL commands lacked the elegance of a "web native" JavaScript API ...

As an aside, I also find the quote from that post very amusing:

> In another article, we compare IndexedDB with Web SQL Database, and note that the former provides much syntactic simplicity over the latter.

The example for a JOIN using IndexedDB in the referenced article[1] looks strained. It really doesn't look like it has "syntactic simplicity" compared to the WebSQL version above it.

[0] https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

[1] https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-we...

j / k navigate · click thread line to collapse