webusb VS postgres-wasm

> WebUSB is actually a W3C open standard.

This is misleading at best. Here’s what the actual spec says <https://wicg.github.io/webusb/>:

> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

It’s an experimental spec by Google (observe the affiliation of the three editors: all Google); Mozilla has adopted a negative position on it <https://mozilla.github.io/standards-positions/#webusb>; WebKit has not remarked upon it.

This is such a lame argument. You want it to be true but have no evidence that it actually is true.

A lot of the Chrome team's "standards" have problems with accessibility, workability on mobile, security[0], privacy[1], or just battery life. Some are neat experiments that are or only will be used in the wild by advertisers to track and identify users.

Because the Safari/WebKit team doesn't have to chase users for revenue like Mozilla does they can afford to be more conservative with what Google "standards" they support. Being able to offer a tighter privacy posture or efficiency is part of the iOS/macOS sales pitch.

[0] https://github.com/WICG/webusb/issues/50

[1] https://www.theverge.com/2021/4/16/22387492/google-floc-ad-t...

Limiting it to installed apps still has the problem of users blindly agreeing to something that is fundamentally super dangerous. I don’t believe installing PWAs currently exposes any new security surface, so this would be a significant change, and worse still a persistent hazard with probably no indication of what’s going on when it’s in use. I think there’s still potential in the general concept, but it’d take work and is certainly not ready yet in any browser.

Yes, certain classes are restricted from access via WebUSB for security, https://wicg.github.io/webusb/#protected-interface-classes. But as the note says, it’s about balance: that list is necessary for security, but not sufficient.

Also: https://github.com/copy/v86 - more productized browser x86 runtime, used by eg https://github.com/snaplet/postgres-wasm

> forcing SQLite

It might be the case that it's running SQLite via wasm. If so, then other database engines would need to be runnable in a browser too.

PostgreSQL has been shown to work in the browser (eg https://www.crunchydata.com/blog/learn-postgres-at-the-playg..., and also https://github.com/snaplet/postgres-wasm), so that might be an option.

Not sure about others.

Thanks, I've been looking at WASM, for ex https://github.com/snaplet/postgres-wasm/tree/main/packages/... , it would certainly simplify everything to "download a fat file".

Hey! Peter from Snaplet here. This is really exciting stuff. We created the OSS postgres-wasm (https://github.com/snaplet/postgres-wasm) example a few weeks ago. An idea I'm playing around with is something like:

  1. Visit https://postgresql.com/try?version=14.x

Other in-memory alternatives for PostgreSQL embedded-postgres (I haven't tried it yet) postgres-wasm (currently it only runs in the browser).

"/s" is obsolete as of now: https://github.com/snaplet/postgres-wasm I'm so sorry

Today we're open sourcing postgres-wasm with our friends at Snaplet.

Peter from Snaplet here. A month ago I saw the CrunchyData post and wanted to play around with the code that made it happen, it wasn't OSS so I asked for help:

> If anyone out there wants to work on an open source version of this full-time please reach out to me. [0]

Paul reached out and we started working on it almost immediately. Check out the repo here: https://github.com/snaplet/postgres-wasm

We have a blog post about some of the interesting technical challenges that we faced whilst building this: https://www.snaplet.dev/post/postgresql-in-the-browser

Like most things, this is built on-top of the amazing open-source projects that made this possible, but special mention goes to v86.js and buildroot. We just glued it together.

---

[0] Request for collaboration: https://news.ycombinator.com/item?id=32500526