Hacker News Reader

Comment by SahAssar | Hacker News Reader

The justification was more that the standardization process requires at least 2 independent implementations, and nobody was working on rewriting SQLite from scratch.

I would have loved WebSQL, but it is reasonable to require multiple implementations for full standardization.

View on HN

> and nobody was working on rewriting SQLite from scratch.

One could also have embedded a trimmed-down PostgreSQL or MariaDB into browsers.

I don't know the reasoning being not doing it, but I'd guess it's related to those DB engines not being geared or interested in embedded use-cases and that no SQL engine seems to entirely agree with any other how to handle certain parts of SQL.

Indeed, it would have been a lot of work trimming down any of the major FOSS RDBMS towards embedding them in a browser.

Regarding the SQL dialect - that could have been handled by specifying a standard SQL dialect that's then dynamically translated to the target engine's dialetc.

That sounds great! Let's do it.

Those don't implement the same SQL as SQLite does, or as each other... What would the standard actually say?

I don't buy this reasoning because they could have standardized only the interface, letting it open for developers to choose SQLite or some other future implementation. There is no need to standardize SQLite behavior, including bugs.

That's not how the process works though. You could argue that they should change the process, but the reasoning behind it seems solid to me:

> Implementation experience is required to show that a specification is sufficiently clear, complete, and relevant to market needs, to ensure that independent interoperable implementations of each feature of the specification will be realized.

From https://www.w3.org/2015/Process-20150901/#implementation-exp...

What actually happens in that scenario is that one group now writes an adapter on top of SQLite to make it "standardized" to whatever interface you design, increasing the complexity and scope for bugs. To be clear: you're literally reimplementing something that SQLite already does, except probably much worse, in the name of the "standard."

Then that adapter is carbon copied by everyone, because again, nobody is going to reimplement an 80kLOC SQL database as well as whatever 10k LOC parser/lexer/typechecking adapter someone wrote, if they can avoid it. Then everyone just uses that forever, and you're back to square 1, using one implementation everywhere, which is the exact situation standards are supposed to avoid anyway.

The working group was correct to reject a "compromise" like that because that's never how it works out in practice; it's a submarine suggestion from the start. And a big part of this is all because, as evidenced by numerous responses in this thread, modern computer programmers seem to value their own immediate satisfaction and time over literally every other potential concern, no matter how significant.

Reply on news.ycombinator.com