Apple declined to implement 16 Web APIs in Safari due to privacy concerns

There is too much opinion in your statement.

Mozilla opposed it, rightfully so, in that it would dictate that SQLite be the implementation used everywhere. Mandating the inclusion of SQLite is not a spec.

As much as I like SQLite and looked forward to it being in 2/3 of browsers, Mozilla made the right call. The web should be implementable entirely by the specification.

Google likes to define the spec as the identity function of the implementation. Popeye specs, "I yam what I yam and dats all that I yam".

WebSQL would have been a spec, could have been a living spec too. Start out with SQLite in all the major browsers, and then gradually have them diverge. Blink and Webkit started the same way. Independent implementation does not mean "implementation of uncommon history".

But somehow "paving the cowpaths" doesn't apply to tech that they don't find attractive.

Similarly, and that is actually a statement loaded with opinion, I've seen way to many self proclaimed "spec hackers" at mozilla. People who relish in the joy of writing out ideas, I mean who doesn't love building castles in the skys, but who completely ditch the implementation. It doesn't matter if you have the most beautiful spec in the world if the implementations are shoddy, or if it specifies the wrong thing.

Web specs are the modern hackers "waterfall" design process. Sure everybody talks a lot, and there are many pretty documents that come out of it. But once you start implementing the stuff, you start to realise that all your assumptions were wrong, and now you've made a mess.

I think specs actually produce less diverse implementations. Because they are so easy to write, in comparison to code, and because writing them doesn't give you immediate feedback on when you've reached a good minimal feature set, it's almost inevitable that you end up with way more stuff than you actually need. There is a reason that there are essentially only 2 Multitrillion dollar companies that can keep up with that mess. And mozilla would have died long ago if google wasn't keeping them alive to avoid anti-trust investigations.

In all fairness Living Specs try to acknowledge this, but somehow we still collectively pretend that they are more than mere documentation, that by calling them a "specification" instead of "documentation" they somehow make the web run.

Specs don't run the web. Code does.

How would you migrate to a different SQL implementation? It would have to be 100% SQLite compatible in the early days because that's what all websites would expect. It makes migration nigh impossible.

That said, as long as the SQL implementation they choose is free and open source I'm not sure this is such a bad thing. I mean we are also stuck with Javascript in the browser and that hasn't been a total disaster. The whole point of standardization is to choose one particular solution and have everybody use it.

> WebSQL would have been a spec, could have been a living spec too. Start out with SQLite in all the major browsers, and then gradually have them diverge. Blink and Webkit started the same way. Independent implementation does not mean "implementation of uncommon history".

You need to think about the barriers to implementation: if everyone ships SQLite, developers will inevitably write code which depends on that exact implementation and anyone shipping something new will need to copy it - including unintentional behavior and bugs – to work with existing sites. That is extremely expensive and might lock in something we’re going to regret later if someone finds a behavior which wasn’t intended for this context and has security or performance issues.

Anyone working on the web should be especially sensitive to this since we came close to having the specs for all web technologies be “whatever IE6 does”.

> Start out with SQLite in all the major browsers, and then gradually have them diverge. Blink and Webkit started the same way. Independent implementation does not mean "implementation of uncommon history".

The point is that they would clearly never, ever diverge. Any sqlite quirks (of which there are plenty) would be enshrined into the backwards-compatibility requirements of any browser that used it. Plus building a database isn't simple - so why not just use sqlite? Setting out to fork or rewrite sqlite is not a task that makes any sense.

There is a lot to unpack in your post, but I get the gist.

You are free to use SQLite on Wasm, in your browser, you break no one and no one breaks you.

Wasm was designed well from a spec and community perspective, Google matured and Mozilla matured and in the end all the browser vendors go together and designed something that lots of folks can implement w/o multimillion dollar development efforts.

You know, I have written web apps that use SQLite and Lua running in the browser. They shouldn't be included inside the browser and nor should browser vendors have to worry about it.

Also SQLite wasn't designed to run untrusted SQL code. It's an embeddable SQL engine, not a web SQL engine.

The exact same argument could have been made for Blink and WebKit, which didn't turn out to be true.

I think your second argument also applies to the first no? Any technology that is implemented in a major browser, be it JS, Webkit, SQLite has incentives to port it to other platforms. Web developers don't expect 100% compatibility, they are so used to things behaving differently and broken across browsers that it's actually surprising if something just works from time to time.

If anybody was expecting 100% compatibility all the time, we wouldn't get any new standards, and would all use chromium.

Well that's kind of a different argument. But one I can get well on board with.

We should kill JS, and EVERY WebSpec, except for WASM and WASI. Take the best parts of html and css and implement a virtual dom / immutable data driven document format for WASI.

Focus all our efforts on carving useful capabilities for WASI and end this web nightmare once and for all.

Not realistic, but a man can dream...

How is that different from what we have now?

Living specs don't give any guarantees, yet they still "pave the cow paths" while keeping ridiculous bugs and behaviours for backwards compatibility, and breaking existing specs for convenience. It all depends on the person dealing with the problem.

Nobody expects compatibility with existing specs, why should they for WebSQL? Especially when it's a living standard.

If those things were true, we would all use the same browser by now and never see new standards, and Blink and Webkit would have never diverged from another.

Open source quarrels basically guarantee a steady supply of competing forks.

That doesn't make it any less of a solid foundation for a web SQl engine.

It's like getting gifted a car, and complaining that you'd rather have winter tires. So you start building one from raw metals.

I was under the impression that the "by specification" idea was generally tossed out with HTML 5, where the specification started to describe the current implementation. And this was cheered by everybody. What has changed?

It is realistic and at some point, one of the browsers will be a shell that runs Wasm and browser updates will just be Wasm.

The specification describes what implementations should do to be interoperable. As opposed to what someone wishes implementations were doing but has no hope of convincing them to do, which was the major change with HTML 5.

But the fact that there are multiple implementations remains. and it remains a goal that one should be able to create a _new_ implementation by implementing the spec. Notably, this goal was not achievable with the pre-HTML-5 specification.

In the specific case of WebSQL, if someone were to actually create a specification for it that didn't boil down to "run this exact version of SQLite and pass things on to it", that would have allowed for the "possible to create an implementation from the spec" goal to be achieved. But no one ever stepped up to do that.

The birth and death of javascript