Comment by mzarate06 | Hacker News Reader

Comment by mzarate06 | Hacker News Reader

From the first 1 minute and 15 seconds of the video:

> "With WebSQL being deprecated, and IndexedDB not providing structured queries, web developers need a tool to satisfy their structured query needs."

> "Web app developers need structured queries to work in the mobile world."

> "With IndexedDB ... there's a steeeep learning curve to make it useful for your app. Moreover, IndexedDB does not provide structured queries."

> "IndexedDB does not offer structured query features, such as sorting by multiple columns, or joining the results of multiple tables."

As someone that looked forward to WebSQL, this is painful to hear. Many of us realized the above from the beginning. Yet, some in the standards committee found a way to shoot down WebSQL, w/vague rationale such as "we don't feel it's the best path for the web".

Well, thank you. Instead of giving us one of the most well tested SQL implementations (SQL Lite) that addresses all of the above, and much more, we were shoved a harder to use, more verbose, and less powerful alternative (IndexedDB). And as a result, we're having to implement our own relational databases. In JavaScript. 4-5 years later.

No offense to Lovefield, but it represents everything wrong w/the decision to deprecate WebSQL and implement IndexedDB instead. It was also the single-most decision that made me lose faith in the standards committee.

The decision to not standardize WebSQL as proposed was correct -- because it wasn't a specification of behavior for which independent implementations were going to happen. It was, effectively even if not in principle, a mandate of a particular implementation.

That's not to say a web-platform relational API (even one based on SQL) standard would be a bad thing -- I think it would be a good thing. And its not to say that using SQLite as a key part of the stack in an implementation of such a standard would be a bad thing, either. But "behave exactly as version n of SQLite behaves" is not appropriate for a Web API standard, any more than "behave exactly as version n of Internet Explorer" would be.

I see the opposite. I see it as everything that was right about the decision not to include WebSQL. Specifically (a) you didn't needed WebSQL. See Lovefield. And (b) you can implement whatever you like that fits your needs instead if trying to shoehorn the one true solution.

The same is true of many other parts of the web. I'm glad O3D failed (I was on that team) and I'm glad something like Unity/X3D/VRML isn't built into the web. I'm glad instead we have something low-level like WebGL that people can build many and varied higher level solutions on (Three.js, X3D, Unity->WebGL, Unreal->WebGL, SceneGL, Babylon3D, Pixi.js, etc.) You pick the solution that best fits your project.

Lower-level building blocks are better IMO in most cases. They are easier to test. Have less incompatible edge cases and leave it up to devs to build or pick a solution that's right for their needs.

If you are ever curious about why WebSQL was shot down, how it happened in excruciating detail:

http://nolanlawson.com/2014/04/26/web-sql-database-in-memori...

> It was also the single-most decision that made me lose faith in the standards committee.

When I try to think of any product or service born of a standards committee that has been wildly successful, I can't think of any.

Standards committees are useful if the goal is to bring consensus-driven stagnation (and standards), so that things can evolve around a group of products/services rather than just individual products/services. But, there have been extremely complicated standards like some of those from OASIS: https://www.oasis-open.org/ that made developers waste countless hours trying to adhere when a high level of complexity wasn't necessary. And even well-used standards like SQL have not moved quickly enough with the times, e.g. if you look at the differences between the major databases (PostgreSQL, Oracle, SQL Server, etc.), there are still many DB-specific features that could be standardized.

> Instead of giving us one of the most well tested SQL implementations (SQL Lite) that addresses all of the above, and much more

I wish embedding PostgreSQL would get to the point that people would think of it before SQLite, especially in situations like this that are generic, because there is so much more that could be done with it. Here's one recent effort in Java: https://github.com/yandex-qatools/postgresql-embedded and a slidedeck from a few years ago from the postgres lead at VMWare with that team's experience: http://www.slideshare.net/jkshah/pg-conf-eu2013embedded

> When I try to think of any product or service born of a standards committee that has been wildly successful, I can't think of any.

He says in a post submitted over HTTP, using DNS for name lookup, TCP for OSI layer 3 transport, implemented in client software via POSIX socket APIs, encapsulated in IEEE 802.2 frames traveling across IEEE 802.3 and IEEE 802.11-defined physical mediums, routed by BGP and maybe even some OSPF.

Come on. You really can't think of any?

Are any of those except maybe 802.11 born of a standards committee?

off the top of my head: HTTP came from CERN and w3c was years later; TCP is the alternative to the stillborn OSI standard; POSIX is a relatively recent AT&T UNIX-clone standardization effort; Ethernet was from Xerox PARC (although most of a modern implementation is from the IEEE era)

Exactly - most of these became standards after an entity produced a good solution in the real world and it became useful to formalize them and evolve collectively.

What qualifies as "born"?

Successful standards committees are just a group of implementing industry members. WebSQL, for example, was edited by Ian Hickson.

The work almost always predates the standards committee -- also just like WebSQL.

FYI, it's a common mistake, but it's just SQLite. :)

Reply on news.ycombinator.com