Today I realized (with @littlecalculist) that the web is AWESOME at dealing with low-disk-space situations (or just generally phones with little disk space).
-
-
At the limit, eviction still possible, but combined with UI changes, much less likely
-
I think this is roughly right for "web apps" (user agent specified limits, not many specified guarantees), but I think you still want something more guaranteed via something that looks like app installs. On balance, this situation is still great though, and best in class!
-
Persistent Storage is probably what we need to evolve to handle hard cases. I.e., would you trade isolation for real persistence?
-
E.g., requiring a CSP value that opts the app into its own storage partition at all times in order to gain real persistence at install time
-
Would this mean you would have to use the same origin for all content (what about fonts?)
-
Wouldn't need to be same-origin only, but all cookies, caches, etc. etc. would be effectively double-keyed. E.g.: `Content-Security-Policy: sandbox-storage; ...`
-
What would the effect of the double-keying be?
- 9 more replies
New conversation -
-
The web’s usual solution for protecting against eviction is auto-syncing app logic, which is necessary for collaborative editing anyway (and which is ofc also in the web’s wheelhouse).
-
I think this is good at a first approximation. Another way to say this is that the web is mostly focused on a "content" abstraction, which treats network (online, offline, flaky) as an orthogonal characteristic to content creation.
-
Today, we expect browsers to paper over network entirely for us, with some amount of control by content creators. We probably need some control by end users too, but we shouldn't give up the separation of network and content, which makes all of this work to begin with.
-
Basically what this comes down to is sometimes you definitely want to pin content locally, but you want network handled automatically for you often enough that automatic fetching/caching is the right default.
End of conversation
New conversation -
-
-
Also browser algorithms (but also app algorithms) are bad at negotiating the sometimes free/sometimes not internet access spectrum.
-
Generally speaking, stronger hints have really helped here. There's potential for abuse, but it's a lot easier to deal with than figuring out which cache headers indicate a real desire by end users. I think direct signals by end users would help too.
-
Yeah, knowing which things I'm willing to use cellular data for is not something that's "hintable", I think.
-
OS APIs don't give us high-fidelity understanding of metering situation. It's crazy complex.
End of conversation
New conversation -
-
-
"hard-offiline" and minorities. People in the US/EU tend to forget reports about how bad network situations get around the world in terms of availability (cost asside) It would be a major deal for people to have "keep for a week" on a browser that works on cheap phones
-
Yeah I realized afterwards I may have sounded like I was saying expensive/intermittent connectivity aren’t major issues. They for sure are, which is why the web has to keep growing its offline capabilities. My point was more that online seems like the better default mode.
-
I’ve also longed for better browser-wide offline storage controls for years. I want to be able discrete, large assets (movies, game levels, presentations, etc) offline and then delete them when I’m done. But ofc when network is cheap it’s nicer to experience them streaming.
-
The fact that web APIs are very low level is both a strength and a weakness of the medium. At the same time Service Workers are great for solving that, adoption is gated by steep learning curve and somewhat high ongoing cost to keep it
-
And since Service Workers and offline features in general are not on spotlight, wrappers are unlikely to be as ubiquitous as jQuery once were or React is now for UI. But it would be great to see some library drop the “bar to offline implementation” super low
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.