(Replying to this and other comments in unison)

A SQL standard never precluded a separate filesystem access standard and implementing databases on top of it.

But rejecting the Web SQL standard means that every SQL-using webapp will be tied to its own database - replicating the SQL incompatibility mess when we had a chance to finally enforce a little standardization based on current SQL standards - and require depending on WASM when WASM might have not been necessary.

> But rejecting the Web SQL standard means that every SQL-using webapp will be tied to its own database - replicating the SQL incompatibility mess when we had a chance to finally enforce a little standardization based on current SQL standards

Web SQL was dropped for precisely this reason:

> The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.

http://www.w3.org/TR/webdatabase/

Without a magic want to force multiple implementations, all of those web apps would have been tied to a single implementation anyway _and_ it would have been harder to update it so even after something was fixed you'd need to wait until the oldest browsers were updated before you could rely on it. That is possible, of course, but it's a recipe for problems with something like a SQL database.

This ignores the fact that SQL already has standards with multiple implementations and is very well established. You can have a basic portable subset - the problem was already very well specified at the offline level.

A simple SQL standard would therefore not have incurred an unnecessary dependency on SQLite (had WASM/filesystem existed at the time, I suspect we could have also supported Web SQL with it).

--

Bugs of course, exist with IndexedDb as well and will exist with these new WASM implementation.

> This ignores the fact that SQL already has standards with multiple implementations and is very well established. You can have a basic portable subset - the problem was already very well specified at the offline level.

This is only partially true, as you can see from the many apps which only support one SQL database even if they're using something like an ORM which is ostensibly portable. Sometimes that's caused by use of things like using extensions but in other cases it can be caused by differences in things like data validation and conversion or how transactions are processed. That doesn't mean that portability is impossible but everyone doing it seriously tests continuously against multiple implementations to make sure they aren't inadvertently introducing a dependency on one flavor. Both SQLite and MySQL are especially notorious for this because you'd have cases where code which was invalid would either be automagically converted (hopefully to what you wanted) or the error silently suppressed so you'd have code which only works, for example, on a database where DATE can be "0000-00-00".

As simple example, at the time Web SQL was proposed as a standard, SQLite did not support foreign key checks at all. It still does not implement full Unicode support so you'd have to require all implementations enable that extension with the same configuration or you'd have data-dependent application bugs.

I would not personally have minded terribly if SQLite was effectively standardized like this but I understand why people wanted to see n>1 implementations. The browser developers are going to be supporting things for many years and as soon as a new feature launches any and all behaviors it exposes will become an API which has to be managed carefully to avoid breaking someone's production application.

Standards are for platform implementors. Developers inevitably ignore standards, and instead code "empirically" to whatever the implementation they're developing against is willing to expose—both in terms of features (guaranteed by the standard or not), and in terms of bugs.

(Yes, those devs are doing a bad thing. They should only obey the letter of the standard, and not "look through" to what the implementation is doing. But we can't just intentionally break support for the stuff they build through this empirical-discovery-of-features-and-bugs process. That would just hurt the innocent users who just want to access their websites — which might very well be abandonware by the point that we discover and fix whatever standard-nonconformance bug such sites relied upon.)

What we can do to control developer behavior, is to impose incentives.

If there are multiple implementations of the standard in popular use in different browsers, each with different bugs, then developers will feel the need to support those different browsers, and so will test in them, find where the deviations from the standard cause breakage, and so end up coding portably.

But if all the implementations in use in different browsers have the same bugs (perhaps because they're all actually the same implementation), then even supporting multiple browsers won't do anything to break people's assumption on those bugs; and so people will write brittle code that depends on exactly those bugs being present to work, and will break even if the platform implementor just upgrades the implementation to a newer version without the bug.

This is the "bug-for-bug compatibility" that Microsoft worries so much about across Windows versions. It's a royal PITA to support, and W3C/WHATWG/etc have thusfar assiduously avoided allowing anything into the standards which has only one implementation, and therefore which devs could ever "lock onto" the bugs of with brittle implementations.

---

Also, this ignores that most of the "pragmatics" of managing a SQL DBMS are not specified by the SQL standard. SQL is not as standard as people think it is! ANSI SQL is mostly concerned with specifying how DML queries work; the DDL stuff is almost entirely a mess of implementation-defined syntax that happens to share some conventions, but with no standards guarantees.

Check this out: https://www.postgresql.org/docs/current/sql-createindex.html...

> CREATE INDEX is a PostgreSQL language extension. There are no provisions for indexes in the SQL standard.

Do you really want to expose a SQL API where you can't create indices, because there's no portable syntax for creating indices? Would such an API even be useful?

If we really wanted a "web SQL API", the designers of said API couldn't just lean on the existing SQL standard; they would actually have to standardize what "web SQL" syntax is themselves — probably as a superset of ANSI SQL, but still laying out a bunch of additional requirements. It'd be similar in scope to WebGL. That's a big ask.

And even if they did that, that'd likely mean that they'd end up with no existing implementations of the standard! (Because it's not like you'd want to lock in all of SQLite's nonstandard DDL syntax choices as "the" WebSQL syntax, right? You'd want to think these out "from first principles", considering what's most "implementation-neutral.")

I don't think there was so much risk of relying on db behaviour much less bugs. There's a DML standard, breaking it would have had massive consequences far beyond the web platform - we could have relied on SQLite being broadly compatible within the simple INSERT/UPDATE/DELETE/SELECT subset (I think more could have been done, but this is enough for a start).

As for DDL, not much was initially required beyond CREATE TABLE, CREATE VIEW and CREATE (UNIQUE) INDEX (which in practice have a basic common syntax). IMHO the ask was not anywhere as complex as WebGL.

SQLite is the one project that deserves an exception. There is a near zero chance anyone else can do better with similar quality (and test coverage!)

Sometimes you need to be pragmatic IMHO.

SQLite fits one generic model, and is a row level data store. DuckDB is a column store, and other DBs are designed to operate for specific use cases. This is open to all options.

The point is that SQLite is a brilliant genetic option, but should not be the only option. WASM and OPFS is the right route forward to enable application developers to use the best data store architecture for their use case.

Even within SQLite there are extension that would never have been an available to WebSQL that with this design are.

But we have 0 options now and 1 is better than 0.

    sqlite> create table numbers (val int);
    sqlite> insert into numbers values (7);
    sqlite> insert into numbers values (8);
    sqlite> insert into numbers values (9);
    sqlite> insert into numbers values ("hi mom, I'm a number!");
    sqlite> select * from numbers;
    7
    8
    9
    hi mom, I'm a number!

I agree that SQLite is great, but do you really want to standardize on that behavior?

People will write applications that insert 41 characters into a varchar(40). And they will care when their sites break when constraints start to be enforced.

I certainly would agree that SQLite is exemplary but consider how many different things are handled under the aegis of the W3C: if you allow one exception, then you will have other people saying their favorite thing should also have one.

So how many implementations of widevine are around? Web standards are well past the point where anyone involved could claim the procedural, moral or intellectual high ground.

The apparent inconsistency here is because you're misunderstanding what Wide Vine is:

The standard is Encrypted Media Extensions: https://www.w3.org/TR/encrypted-media/

That provides a standard way for web developers to say “Our audio/video files are encrypted. Use this decoder to decrypt the bytes for playback.”. Wide Vine is a popular Content Decryption Module used by EME but it's not the only one (Apple devices use FairPlay, Microsoft ships PlayReady) and the standards process required interoperability to be demonstrated.

Web SQL's standardization process halted precisely because nobody was interested in building a second implementation. If Web SQL had a second implementation, it could have been standardized just like EME was.

A SQL-level standard wouldn't do much because different apps will be using different database schemas anyway. (It's similar to how two applications that both use JSON format usually aren't going to be compatible, because they use it to store different things.) Only generic, schema-independent database tools and libraries would be helped.

For a portable application file format, you'd want to pick a SQL implementation (probably SQLite), decide on a schema, and probably wrap it in a library, but once you do that it could be used in multiple apps.

Isn’t the logical conclusion of this view the end of web browsers, replacing them with executable software distribution?

Blasphemy! More fun to deal with compatibilities of running in different browsers. Seems like we have returned full circle (25 yrs later) to a new form of ActiveX plugins.