SQLite Wasm in the browser backed by the Origin Private File System
developer.chrome.com
developer.chrome.com
There's one problem though, this new API is for the web, so the nature of this storage is temporary - obviously the user must be able to clear it when clearing site data and this what makes it currently an unviable solution for a persistent extensions data storage. https://bugs.chromium.org/p/chromium/issues/detail?id=138321...
This is already possible with the file system access API. Clearing site data has no impact on these files. But you do have to re-grant permission every time you reload the page.
https://developer.mozilla.org/en-US/docs/Web/API/File_System...
I haven't tried it yet, but I thought it did.. the first 3 paragraphs of the comment you're responding to all mention directories
> This API allows interaction with files on a user's local device, or on a user-accessible network file system. Core functionality of this API includes reading files, writing or saving files, and access to directory structure.
> Most of the interaction with files and directories is accomplished through handles. A parent FileSystemHandle class helps define two child classes: FileSystemFileHandle and FileSystemDirectoryHandle, for files and directories respectively.
> The handles represent a file or directory on the user's system. You can first gain access to them by showing the user a file or directory picker using methods such as window.showOpenFilePicker() and window.showDirectoryPicker(). Once these are called, the file picker presents itself and the user selects either a file or directory. Once this happens successfully, a handle is returned.
From https://news.ycombinator.com/item?id=32953286 https://westurner.github.io/hnlog/#story-32950199 :
> - [ ] UBY: Browsers: Vary the {color, size, fill} of the tab tabs according to their relative resource utilization
And then that tabs are (sandboxed) subprocesses running as the same user though.
Containers may have unique SELinux MCS labels, and browser tab processes probably should too.
containers/container-selinux: https://github.com/containers/container-selinux
https://github.com/kai5263499/awesome-container-security/iss...
> - [ ] ENH,SEC: Browsers: specify per-tab/per-domain resource quotas: CPU, RAM, Disk, [GPU, TPU, QPU] (Linux: cgroups,)
Like Flash
What are you suggesting here? That extensions should have some special storage, that can't be (easily) deleted? Noooooooo thank you. Firefox has "forget about this site" and similar tools, which I use near daily. Don't fuck with my ability to do housekeeping.
asking for permission to a longer storage.local exemption for the user? noooo let's not even think about giving user control of things. let's the European union pass post-fact legislation after file system access is abused by adnetworks. then they get the blame of being annoying, not the browser vendor who sell ads.
let's stop being naive. there are a million ways to fix that bug with better UX and respect for user control, but this is a scape goat to have that feature.
EDIT: I saw from your other comments on this post that Firefox has implemented at least the origin private file system part in nightly builds; that's useful info that I was looking for.
However the sqlite demo page says OPFS is unavailable for me in Safari https://sqlite-wasm-opfs.glitch.me/ ...unsure whether it only supports a subset of the APIs that the official sqlite build uses?
What happens is Chrome releases a Chrome-only non-standard (at a rate of 400 APIs per year). It cobbles together a barely legible spec [1], and then uses its multiple propaganda channels like web.dev to present them as actual completed standards that other browsers are just slow to implement.
Even if other browsers only learn about this a few days before Chrome ships, or have multiple objections.
[1] Example, File System API https://wicg.github.io/file-system-access/ "not a W3C Standard nor is it on the W3C Standards Track."
We're literally in the discussion about File System API that is:
- not on any standards track
- considered harmful by other browser vendors
- shipped by default in Chrome
Edit: I can give several examples from Web Transport to HID to Constructible Stylesheets that were either shipped with no input from other vendors, or shipped against the multiple objections from other browser vendors. And that's just the ones I know about.
Web Transport is shipped by default. What was the input from other browsers?
Here's the timeline for HID: https://github.com/mozilla/standards-positions/issues/459#is...
Constructible Stylesheets: the spec contained a trivially reproducible race condition, the API was badly specified. Google shipped against any objections and refused to bring it back under the flag. Full discussion here: https://github.com/WICG/construct-stylesheets/issues/45. Shipped in Chrome https://github.com/WICG/construct-stylesheets/issues/45#issu... (may be hidden on mobile) despite multiple unresolved issues. Two years later Chrome did add a better API that people originally requested, other issues potentially remain.
You may believe in benevolent Google working hand in hand with others for the betterment of the web. The reality is radically different.
Edit: more about hardware APIs: https://news.ycombinator.com/item?id=34356651
Edit2: As to the number of APIs, Chrome actually tracks how much they ship: https://web-confluence.appspot.com/#!/confluence
> We're literally in the discussion about File System API that is:
> - not on any standards track
As others have pointed out the standard is here:
> - considered harmful by other browser vendors
It is literally being drafted in conjunction by all the major browsers.
> - shipped by default in Chrome
So what? I for one am thankful that Chromium enables features earlier than other browsers. If you don't want the Chromium implementation then don't use it.
As others also pointed out, it's a different standard.
File System: Mozilla isn't opposed
File System Access API: considered harmful
There are parts (of whichever spec) that neither Mozilla nor Safari are opposed to like Private Origin File System. That one ships across all browsers.
> So what?
Ah yes. So what if a dominant browser ships features without any consensus, against objections, with badly written specs, or with glaring issues.
As to "don't use it", https://news.ycombinator.com/item?id=31905404
- File System Access API, https://wicg.github.io/file-system-access/
- File Handling, https://github.com/WICG/file-handling/blob/master/explainer....
- Origin Private File System, https://github.com/WICG/file-system-access/blob/main/AccessH...
There was also Storage Foundation API to which the reaction was "I don't think it's an acceptable outcome for the web platform to have that many ways to work with files" :) https://github.com/mozilla/standards-positions/issues/481 This one never saw the light of day.
At wich point will the user just blindly click "yes" on all of those?
Sites shouldn't be asking for permissions that don't really need, and users should default to "no" instead of yes, but these are orthogonal problems.
Browsers could batch them up. One dialog that lists what permissions the site wants with checkboxes next to each of them to agree.
There really is no way around that for file system access. Users must consent and consent to a small subset of files, or the whole thing is effed.
Edit:
Note: those three are the ones I remember because I was reading about them at the time, or participating in some form in the discussion. How many are there that just slip through? Well, you can kinda see for yourself (second hand guessing, by proxy etc.):
1. MDN lists various web APIs, including experimental ones: https://developer.mozilla.org/en-US/docs/Web/API Almost every single one that's marked "experimental" is shipped by default in Chrome
2. Mozilla lists its position on various standards. Almost all of those marked as "considered harmful/negative" are shipped by default in Chrome https://mozilla.github.io/standards-positions/ (exceptions are a few deprecated and removed ones like HTML Imports)
3. Chrome currently ships 1100 more APIs more than Firefox: https://web-confluence.appspot.com/#!/confluence (note: a single standard like "File System Access API" may expose dozens of these APIs) Is it because Firefox is lagging, or is it because Chrome just powers through, all consensus be damned?
Context: I was a member of both the Firefox and Chrome development teams at different points.
https://developer.mozilla.org/en-US/docs/Web/API/FileSystemF...
Discussion from back when the SQLite project announced this last year: https://news.ycombinator.com/item?id=33374402
There isn't an "official" NPM package or ES6 model yet, but I believe they are working on it. It's also very much designed for the browser currently, but again I believe they are intending to support server WASM environments too eventually.
(The sqlite team's JS/WASM Guy here...)
An ES6 module build was added shortly after the 3.40 release.
NPM/node.js are nowhere on our radar. Our build is structured such that people who want to plug it in the resulting JS file to whatever their favorite toolchain is are welcomed to do so, but we have neither the ambition nor the bandwidth to support every build/bundling platform out there, especially ones none of us otherwise use.
> It's also very much designed for the browser currently, but again I believe they are intending to support server WASM environments too eventually.
The JS code is targeted solely at browsers and there are no plans on changing that in the foreseeable future.
The WASM build itself, we are working to provide server-side support for. We have a branch which builds under wasi-sdk, but we cannot create a JS binding for that build until/unless we find some substitute for Emscripten's transparent translation of POSIX I/O APIs.
For what it's worth (though it seems like the decisions is done), there's no need to support every build/bundling platform - the NPM registry is rather 'tooling agnostic' and publishing there would make it available to a lot more people with a lot less effort.
The sqlite project is populated entirely by C coders (my primary language), none of whom have either experience with, nor a need for, NPM, so we're not eager to claim any level of support for it. Trying to support a tool one neither uses nor understands is like trying to wave away darkness with one's hand.
> ... with a lot less effort.
A lot less effort on their own parts and a lot more on ours ;).
Future NPM support has not been outright ruled out, but it is admittedly nowhere even close to currently being on our radar.
The JavaScript world is culturally so dependent on npm now that adoption of SQLite in that world would massively increase given the availability of a good "official" package.
And without an official one I imagine there will quickly emerge dozens of unofficial ones, many of which will end up poorly maintained in the future.
Seeing as none of us in the sqlite project use NPM or node in any capacity whatsoever, nor do we have any interest in doing so, i'll opine that "unofficial" ones would be of much higher quality than any we would put out.
To repeat what i just said in another comment on this topic: Trying to support a tool one neither uses nor understands is like trying to wave away darkness with one's hand.
It seems like Chrome is paying them for the “deliverable” of a JS version, but the spec did not include “npm installable”.
None of us in the sqlite use npm in any way, shape, or form, so there's nothing at all unusual about us not publishing anything there.
> It seems like Chrome is paying them for the “deliverable” of a JS version, but the spec did not include “npm installable”.
Like all deliverables released via the sqlite project, this one was conceived and created as a deliverable which can be distributed through the existing project-level infrastructure. What other people do with it, through whatever infrastructure they like, is entirely up to them. Getting involved with such tooling is way out of scope for us.
https://developer.mozilla.org/en-US/docs/Web/API/File_System...
What's next, mmap() for javascript?
For example, it should be possible to build websites for downloading YouTube videos that does not use server side code execution or bandwidth. These were popular at some point but disappeared after Java applets stopped being supported by most browsers.
WebSockets are already a problem because many web devs don't know that other origins can connect to them and potentially fetch data they're not supposed to (even ignoring the fact you can construct these without a browser), unleashing raw sockets to the web platform would be hell.
WebRTC and WebSockets provide more than enough already. If you need even more, your browser just isn't the place for this type of code IMO.
Devs who don't need the high performance but want wider compatibility will probably continue to use the "unofficial" versions.
Also, last I checked, you could definitely load web assembly in a page that has a File:/// origin.
My use case is an entirely offline webapp that I'm building as a side project, partly just to see what is possible. I've tried indexeddb, pouchdb, absurd-sql, and various others, and have ended up back at localstorage, which is plain but low on edge cases.
The other big pain point I am hacking around is cross device sync; I'm leaning towards simple chrome and firefox extensions that'll slurp data into your profile in order to sync, which'll work for cross computer sync for my needs. However, chrome on android doesn't support extensions, and there's no other good way that I've found to sync between a user's chrome profile and android, so that is still a hole in the story. Some kind of webrtc based thing is imaginable, but it's clunky.
[1] https://jlongster.com/future-sql-web
[2] https://developer.chrome.com/docs/web-platform/storage-found...
IMO, the Chrome team is being a bit deceptive with their phrasing on synchronous file handles. The problem is that the entire API is wrapped up in an asynchronous ceremony. `createSyncAccessHandle` is only available in a worker context. So you can only communicate with the worker using an asynchronous postMesssage event dispatcher. And even when you’re in the worker, file handles can only be accessed through methods that return a promise.
I understand the need for such boundaries when working with a single threaded language, but limiting the synchronous APIs to just workers seems like one too many layers of indirection. I recently attempted to write a POSIX-style BusyBox library and this sort of thing was a total show stopper.
An unresponsive script is slowing this window down - kill process ot wait?
I would be delighted if handlers were more akin to byte arrays that could be written and read synchronously, albeit with an asynchronous function to persist changes to the disk.
The File System Access API does give the webpage the ability access files on the users file system, with permission. However not at the block level, that is only enabled for the OPFS. In order to provide ACID compliance SQLite needs to be able to hold a lock to a file and write at the block level, which is only possible within the OPFS sandbox.
It's frustrating that the web community first build File System Access, but made a number of design choices compromising performance. Then AccessHandles/whatwg-fs, which unlocks performance, but severely limits it's usability to things users can't really interact with. And only release a sync implementation.
I love the web platform, but this feels so unfortunate.
Example of syncing your app across tabs with SQLite here: https://vlcn.io/docs/guide-solving-tabs
It's mostly works with OPFS but with a few edge cases. They are working with the browser vendors on improving this in OPFS.
Alternatively run it in a SharedWorker (https://developer.mozilla.org/en-US/docs/Web/API/SharedWorke...), which seems to have made a comeback after being dropped for security concerns. Or do some sort of leader election with browser tabs and use a BroadcastChannel.
Given the use of SharedArrayBuffers and that SharedArrayBuffers can't be used in a shared worker (funny), SQLite WASM doesn't work in shared workers.
If getSyncAccessHandle was made synchronous then maybe everything would just work. It'd also improve SQLite WASM perf by 30% according to their measurements [1]
[1] https://sqlite.org/forum/forumpost/af64f73911e5410cf9a640c9e...
Something relevant is absurd-sql, but unfortunately that's not even close to production ready :/
683KB plus 300KB is less than many web pages these days.
Just because everything is already shit doesn't mean it's a good idea to pile more on top.
Hm.. 1 MB is good (just zero app code) ..okay.
On use cases, you can give your web app offline support by locally caching data in an SQL database and have it be fully queryable.
Say you are building an app like Notion, they already have "offline mode" for the mobile and desktop apps, this would enable you to build that for the web app.
This is very much one of the final jigsaw pieces needed to make PWAs (progressive web apps) competitive for the majority of use cases. We just need Apple to catch up and fill in a few other blanks too.
A design pattern that is beginning to emerge is "offline/local first". You design your app to fundamentally work offline, using things such as this, and the server component only works to synchronise clients. It's a bit like the design move to "mobile first" that happed 10 years ago, but going to another level.
It reminds me of an old concept, that has a catchy name I can't recall, positing an endless cycle in systems evolution where local peripherals grow processing capability until someone notices and (re)centralizes it, only for the local processing capability to quietly begin growing again, and so on.
If you want relational tables, joins, aggregations etc, you want something like this (or the original Web SQL that was deprecated).
There is definitely a use case for it.
If only. It’s much closer to DBM than it is to Mongo.
SQLite, which has a SQL database engine, is, by definition, a relational database. IndexedDB is a non-relational, or noSQL, database. One can't be basically the same as the other :-)
IndexedDB seems like a whole bag of gotchas. SQLite + simpler browser provided file backing seems interesting to me.
Think Redis vs PostgreSQL.
Apple wants to handicap web apps to encourage people to build for iOS.
I think Safari has also made progress over the last couple of years, and there is indication of them being more receptive to PWAs. I'm going to cheerlead for that.
It's also worth noting that the EU and UK competition authorities are looking at forcing Apple to make changes to some of their rules around web browsers on iOS. They have a big stick, I don't, hence my nicer words.
You also have mixed (“just right”) consistency systems and techniques to introduce and optimise the use of runtime coordination where necessary.
For example see https://electric-sql.com/docs/reference/consistency
> In our blog post Deprecating and removing Web SQL, we promised a replacement for Web SQL based on SQLite. The SQLite Wasm library with the Origin Private File System persistence backend is our fulfillment of this promise.
I'd venture to guess the best answer is "whatever the hell people used Web SQL for." Doesn't really answer the question, but alas.
Or need to collaborate on the data (i.e. a company with empoyees)
Or have regulations/controls on where data lives 'at rest'
This is a really powerful capability. You could build the equivalent of full desktop applications - things like Word, Excel, Access, Evernote, task trackers, Blender... all without any server side storage mechanism at all.
And it's an app that runs in a very robust sandbox, so much less risky than installing software.
Well, you need to have a computer, and download and install an operating system first.
For me, it is the last missing piece to make web apps as comfortable as native apps.
I use a lot of web apps I fine-tuned exactly to my liking. I do all my writing in this web app for example: https://www.gibney.org/writer - I hit F11 and boom! I am in distraction free writing heaven :)
If Firefox would support the File System Access API, it would be much more comfortable to load and save my writings.
File System Access considered harmful, will not be implemented: https://mozilla.github.io/standards-positions/
Note: in true Google fashion Chrome team implemented and released at least three different APIs all having something to do with files.
Status of File System Access? "not a W3C Standard nor is it on the W3C Standards Track." https://wicg.github.io/file-system-access/ Shipped in Chrome, of course.
https://mozilla.github.io/standards-positions/ is positive on it
and implementation is well underway: https://bugzilla.mozilla.org/show_bug.cgi?id=1748667
To hopefully add a bit of clarity: indeed, that page has OPFS flagged as positive under the label "File System." Further down the page is a "File System Access" entry which is flagged negative.
I didn't want to dig through all of them on mobile when I was responding.
Both Safari and Mozilla are open (and implement/have implemented) to Origin Private File System. Because it gives web sites an access to a file system without a chance of escaping and damaging user data. Can't remember which spec introduced it, and it doesn't really matter at this point.
For the more general part of File System Access Mozilla's and Safari's positions are: nope. https://github.com/mozilla/standards-positions/issues/154
There was also Storage Foundation API but it was thankfully never shipped (it was like a third way of handling files or something),and also received negative responses: https://chromestatus.com/feature/5670244905385984
They seem quite positive to parts of the spec. Don't know if that's the parts relevant here or not.
Coup d'état: French, "stroke (coup) over/of the State (état)".
https://en.wikipedia.org/wiki/Coup_d%27%C3%A9tat
/pedantry
Chrome is the young IE, the one disregarding the competition and imposing their own standards.
Safari is the old IE, the one that is behind other browsers in terms of standard as but that you cannot ignore because it ha too big of a market share
Hell, even the $LARGE_CORPORATION I work at has all its developer tooling (including documentation, custom extensions, etc.) on Chrome. I've reported countless Firefox-specific issues, often due to missing API support, because no one internally tests on anything other than Chrome. You have to meet your users where they are.
It's not broken because they are fussy on standards.
it's broken because their marketshare dropped so low companies that make money on developing web stuff are often not contractually obliged to even support it. Few of our clients have contracts where we're obliged to support any browser above 5% market share and FF is already below even that!
As a cautionary tale: the moment Firefox shipped support for a hardware API they immediately ran into sites abusing them. Of course, Chrome doesn't even hide them behind a user prompt. https://twitter.com/denschub/status/1582730985778556931 (and comment)
There are reasons Firefox opposes these standards. Chrome is neither your friend nor does it care for the web. Why are you so willing to give a carte blanche to a power struggle (Chrome/Web vs. Android) inside a web advertising company is beyond me.
Somehow "everything that Chrome ships" is core functionality now
> broken or slow on Firefox but work fine on Chrome.
Somehow you blame Firefox for this. Even though "only works in IE" isn't even ancient history
They might when their files get exfiltrated or encrypted. The file system access API UX is far too easily abused to misleading users into granting access to things they didn’t intend.
Nothing on my screen except two areas: The writing area and the margin around it.
I want to be able to easily resize the writing area the way I can resize the textarea.
I want to be able to easily change the font size via ctrl+ and ctrl-.
I have experimented with various distraction free vim plugins but they were all fragile and cumbersome.
If you have a solution, a screenshot would be very interesting.
In my attempts to use it, that created a bunch of issues.
And yes, of course Vim has spellcheck.
what's wrong with the so called "zen mode" that has been available on every moderately popular editor for decades?
See also JRR Martin still using WordStar 4.0 for DOS
https://cdn.eteknix.com/wp-content/uploads/2014/05/37719_2_g...
The result today: A single SQL implementation with no standard (beyond SQLite) and therefore no easy way for anyone to create a compatible alternate implementation.
SQLite not right for a project? DuckDB has a WASM build too.
Heck, so does PostgreSQL now! https://www.crunchydata.com/blog/crazy-idea-to-postgres-in-t...
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.
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.
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 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.
(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.")
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.
Sometimes you need to be pragmatic IMHO.
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.
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!
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.
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.
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.
Think about the DOM APIs: jQuery was super popular in the 2000s. Say all of the browsers had decided to bundle it like WebSQL bundled SQLite. Would you be happy using a copy of jQuery 1.7 until all of Apple, Microsoft, Mozilla, and Google shipped 1.8 and all of your users upgrade or would you prefer to update your site to reference the version with the features you want to use? (or switch to a different framework in 5 years)
Browser developers always have to balance the tension of adding something new with the knowledge that they're going to need to support it for long periods of time. WASM is a good compromise position because it reduces performance as the reason why something should live in the browser engine rather than being shipped as an app resource.
This ignores the fact that SQL already has standards with multiple implementations and is very well established. It's not a recent-ish JS library. It's not new tech. It's an almost 50 year old tech predating the internet.
Standardizing on a basic standard subset using the current SQL standards would have been enough for nearly all apps, and would have allowed alternate implementations without any real SQLite path dependency since SQL already has standards and well trotted paths for implementing them (at least a basic subset).
[EDIT: I don't wish to spam the comments. If you wish to reply to this, please use the other thread you also replied to? I should have done it myself, sorry about that.]
I'd polyfill 1.8 until enough browsers support it like is done for every other browser api
I miss when the web was essentially a document viewer.
said unironically on a web app
Yes, iOS is a black box hellscape. Android less so.
And webapps are the epitome of walled garden. The programs literally require a host server to function. All you get is front end.
I take your point on accessibility. And that is the main draw for a lot of people and devs I imagine: I can access the thing I like from nearly anywhere and anything!
And I can respect that. And it has its uses.
My complaint is that this won’t be a choice eventually for most things. It’ll be “use this web version or nothing”.
You are already seeing negative aspects of a lot of this even on desktop programs. Like look at Steam. It’s convenient. People have flocked to it.
If you are offline you lose access to everything. Unless a cached credential is still working.
If you lose access to your account, you’ve lost all your games. Blah blah.
I’ve had personal experiences with this. It blows.
It won’t stop it. People are fine till it happens to them. But then they forget it five seconds later and right back at it.
*aaS is irritating as fuck
So you end up with piss poor “web apps” that half the time require a specific browser to work remotely well and have kludged “offline” modes that break every other day.
Do not want. I know I’m probably in the minority but it’s damned irritating. The UX on most is atrocious and you have to deal with a complete hodgepodge of interface styles and ideas and designs and also hope your browser keeps running smoothly after trying to use multiple more advanced webapps simultaneously.
Oh, but all these advancements on wasm and all will continue improving performance and fixing problems!!!
… you mean stuff that was already solved with native programs? “But you can work on your stuff from anywhere with just an account!”
Oh, like a native app’s data synchronization?
But but…
It would be nice if we had both and both were equals. But that isn’t the case. It won’t be the case. And most companies see this as a wonderful way to vendor lock in even more than before and implement more and more IAP and subscription crap.
No thanks.
But if it’s a desktop app that does desktop things but still requires a network connection for a completely inane reason I don’t use it. I hate that shit. That’s the same sort of awful as a “webapp”.
And I knew people would start with the “that’s actually no different than desktop programs requiring specific versions of the apps or toolkit. Therefore your complaints are invalid.”
Difference here is I can keep my program. And use it via emulation or virtualization if necessary.
Webapps are another trend towards a “you own nothing. You rent everything.” Economy with computer software.
It’s shit.
And I’ll add that webapps /have/ their place. And I obviously use some.
My big gripe is, like with everything with humans, there’s always this push to extremes. It’s not “let’s use webapps where they make sense” it’s “let’s try to convince everyone webapps are perfect and we need everything to be that!!” cough ChromeOS trash
So if it would stay reasonable where traditional and web and even hybrids can coexist that’s fine.
It won’t. It never does. And I am not looking forward to the inevitable future of Always Connected being a requirement for literally everything. And you have to pay monthly fees for every little thing. And you lose access to your supposed data of you let you account lapse briefly. Blah blah.
It’s already happening and if you claim otherwise you are being willfully blind.
But people love the touted “convenience” and eat it up. And poo poo naysayers.
grumpy
Also, “completely offline webapp” is such a damn oxymoron lol.