It'd be excellent if Export/Import has a standard format.
Especially if we see adoption on the Storage Buckets standard, sites will be able to partition up their storage into different concerns. Maybe there's some users data (xdg config[1]), some cache (xdg cache[1]), some app state ([1]), and each can be saved into a different bucket. Then a standard export/import standard would let folks save and load data easily? Maybe in interesting cross-site ways, where we import/export data? https://specifications.freedesktop.org/basedir-spec/basedir-...
I was super scared this article was going to glorify an impractical disconnected imo useless "simple." Very glad to see import/export handled; simple, but very much in users power to let connectivity happen, to spread their data, as connected apps have so powerfully let us do.
Are there any ideas / draft proposals about browser access to shared cloud storage? (Google Drive, Dropbox, OneDrive, etc.) The ability to store data on the user-side in a way that they control and is still cloud-available to multiple devices may be a feature that's just too user-empowering to be supported.
I think many of us run our own NAS or document server or something... or even just an rsync and off-site system. But delivering this to users as a turn-key solution is a challenge. If your role is to just provide software that works together, there are some not-too-difficult solutions out there but still a lot of ways to mess up the replication or keep things from getting pwned. If your role is to provide availability and reliability, the economies of scale and totality of control that a centralized system provides just wins out over an indexing of the user's systems.
EDIT: I missed that your question was specifically about browser access. tbh I think it makes the most sense to deliver the files directly by the server, with maybe some media controls for specific file types but even that is something the browser can basically take care of out-of-the-box.
I have seen one web app [0] uses the remote storage library [1]. It does fit your criteria. It would be nice if the big cloud storage companies adopt this or create something similar.
Can't you already do this with the regular file api? If you've got the cloud storage app installed, it will show your cloud storage as a folder to use in the file picker.
Or do you mean websites automatically saving stuff to your cloud storage without any UI interaction. That sounds far too abuse prone.
The later. Browsers already save files to my local disk (cookies, web storage) and many of them sync data to the cloud (Chrome syncs passwords, extensions, bookmarks). I'm suggesting browser should also sync the 10MB of web storage.
It sounds possible but pretty limited in usefulness. Almost all cookie usage is session tokens and tracking tokens. There is no point syncing these.
I suppose you could sync locally stored preference data but this is pretty uncommon since you could just store the data with your account. Would just be adding more complexity to the browser for a feature that very few would use properly, and likely many would abuse.
> They can only last if they’re simple to maintain, otherwise keeping them working becomes tedious and the author eventually gives up.
This, x1000.
I cannot count how many hobby projects I have outright abandoned at the first failure, never to return. The fix may have been simple too! I'll never know, though: the startup effort required to re-contextualize myself with the complex mess I'd made was never worth it at the time, and the longer you let them languish the less-likely you are to return. RIP, projects.
Cookie clicker does something similar for importing and exporting saves, and it is an absolute joy to not have to fiddle with accounts and be able to backup your own data. I’d love to see more applications move to this model, it’s very user-friendly.
I've recently been making much simpler projects, and simplifying old projects too. I don't have as much time for maintenance as I did during COVID.
On the other hand, my most complicated project ran just fine for 3 years. I dreaded touching it because it was too hard to reason about, but it worked.
Why do you think prompts are necessary?
If you don't send any data to third parties or let them store data on the users device you don't have to prompt anything GDPR related.
The GDPR is concerned with using cookies or storage for tracking users without their consent, not with using cookies or storage as such. You don't need to ask for permission to use cookies (or similar techniques) in general – only when using them for evil. GitHub wrote a blog post [0] on this a few years ago.
Most cookie banners try to conflate the different uses of cookies to trick users into consenting to the tracking the law is meant to protect against. They are essentially the equivalent of a restaurant asking you "Knife Consent: This restaurant uses knives for 1) cutting vegetables and 2) removing your organs to sell on the black market. CONSENT TO ALL?"
I wonder if you do not have more interesting things to see in Paris than crude Space Invader pixel art. That would be really neat if it was all over Chelyabinsk or Sao Paolo, or maybe some derelict US suburbia. But Paris? Come on!
Same thing with London and Banksy, btw. Of all the things you could see.
Sometime people really like to complicate instead of keeping things simple. Not just for show off but they genuinely believe something more complicated is better. Better such as it has better security, it has better extendability and is more generic. Even if those features were never in the actual business requirements.
I am amazed no one has written Hello World Microservice Edition. So you can have a fancy React UI, a Gateway, an User service, an Authorisation service, a Notification service, an Audit service, a Pricing service and a Printing service.
That "Hello World Enterprise Edition" looks dangerously under-engineered - I could understand it! Far better to follow the best practices demonstrated in the Fizz Buzz Enterprise Edition...
I don't know all the reasons individual developers would want a more complicated piece of software. Might be to show off, yes, or to learn about a new technology to the detriment of those developers that come after and the Ops people who will have to maintain it. Or they genuinely believe complicated is better.
But the one thing that ultimately adds a lot of unneeded complexity to basically every software project at my work are requirements. That kind of requirement that nobody thought of when the project kicked off. And this kind of requirement that a few months later everyone realizes nobody actually needed. And that you possibly remove after a while. But in the meantime this feature influenced your entire data model or worse.
This is the point where your previously fun work turns into a slog for the duration of said project. Well at least we can still have fun with our hobby projects!
When I look back, I see my "overengineering everything" era as a phase, a live lesson to be learnt. I overengineered a couple of things massively because I didn't know what lied ahead and that helped me, but then I learnt that it's harmful as the "default mode of programming".
As I understood how performance worked, what's maintainability and minimalism (as a general concept), the code I write became minimal and simpler.
Currently I'm working in a mode which can be called "overgrow and extend". I start with the most simplistic code which satisfies the design and my requirements, then refactor any part which cracks under the design to satisfy the requirements without being hacky. This philosophy works like a charm for me. Coupled with my "needless comments", getting back into context and extending/maintaining the code is easier than ever.
I even started to finish and deploy my personal projects. It's that effective for me.
Now I'm learning live documentation, which allows me to write the documentation of the things I'm working on simultaneously. When things finish I also have a workable documentation as a result.
You are of course right that developers have to learn to keep things simple and that skill comes from overengineering stuff. Maybe I have been overly negative on my original comment. As long as it's just a "phase" the long-term benefits of going through that phase should be much higher than the short-term costs to your org.
Good on you for having success with your personal projects!
Those are noble goals; I think the problem arises when devs forget that "change the code" and "replace with something else" are perfectly valid options. Adding a plugin interface and override hooks, just in case they might be needed, for an internal library, then it's a classic case of YAGNI. When an implementation is so configurable that passing it a config is more effort than writing a bespoke implementation, then it may be an example of the "inner platform effect".
Scalable Hello World with a dynamic server pool size policy, a comprehensive health check so you can restart your instances in case of failure, performance observability, and centralized logging!
Using offline storage is the approach I use in most of my hobby projects. It's simpler, and faster (in developing and in usage) and there are no loading screens.
In my kindle-clippings-manager (https://github.com/karlosos/kindle_clippings_webapp) I import highlights from Kindle and store them in localStorage. The major drawback is a size limitation (10MB). This should not be a problem in most cases but if you need to store more data then indexedDB (with bigger limits but more complexity) can solve the issue.
>Hobby projects are fragile. They can only last if they’re simple to maintain, otherwise keeping them working becomes tedious and the author eventually gives up.
Literally why I always choose Windows over Linux, Intel/Nvidia over AMD, air cooling over water cooling, etc. for all my computers.
Life is short, ain't nobody got time for jank no more.
Local Storage falls apart on iPad/iPhone, unfortunately. The data is deleted if you don’t visit the site often enough. I lost my Wordle stats over a vacation this way.
Even worse, if you have an HTML game hosted on itch.io (which uses a cross-domain iframe, for security), Safari just silently discards all Local Storage when you close the tab, with no option to disable this behavior on a specific site.
I know Local Storage is supposed to be just a cache, but I really wish we had opt-in durable storage…
> Safari proactively evicts data when cross-site tracking prevention is turned on. If an origin has no user interaction, such as click or tap, in the last seven days of browser use, its data created from script will be deleted.
34 comments
[ 3.9 ms ] story [ 112 ms ] threadEspecially if we see adoption on the Storage Buckets standard, sites will be able to partition up their storage into different concerns. Maybe there's some users data (xdg config[1]), some cache (xdg cache[1]), some app state ([1]), and each can be saved into a different bucket. Then a standard export/import standard would let folks save and load data easily? Maybe in interesting cross-site ways, where we import/export data? https://specifications.freedesktop.org/basedir-spec/basedir-...
I was super scared this article was going to glorify an impractical disconnected imo useless "simple." Very glad to see import/export handled; simple, but very much in users power to let connectivity happen, to spread their data, as connected apps have so powerfully let us do.
EDIT: I missed that your question was specifically about browser access. tbh I think it makes the most sense to deliver the files directly by the server, with maybe some media controls for specific file types but even that is something the browser can basically take care of out-of-the-box.
[0]: https://petrolette.space/
[1]: https://remotestorage.io/
The library for that seems to support their custom protocol as well as Dropbox and Google Drive these days.
There's also Solid which attempts to do something similar: https://solidproject.org/
Or do you mean websites automatically saving stuff to your cloud storage without any UI interaction. That sounds far too abuse prone.
I suppose you could sync locally stored preference data but this is pretty uncommon since you could just store the data with your account. Would just be adding more complexity to the browser for a feature that very few would use properly, and likely many would abuse.
This, x1000.
I cannot count how many hobby projects I have outright abandoned at the first failure, never to return. The fix may have been simple too! I'll never know, though: the startup effort required to re-contextualize myself with the complex mess I'd made was never worth it at the time, and the longer you let them languish the less-likely you are to return. RIP, projects.
Simple Lasts Longer.
A next level up is to use Glitch, running something like PocketDB.
On the other hand, my most complicated project ran just fine for 3 years. I dreaded touching it because it was too hard to reason about, but it worked.
How come? Is WebStorage exempt from GDPR? (I searched a bit and found both yes and no answers.)
Most cookie banners try to conflate the different uses of cookies to trick users into consenting to the tracking the law is meant to protect against. They are essentially the equivalent of a restaurant asking you "Knife Consent: This restaurant uses knives for 1) cutting vegetables and 2) removing your organs to sell on the black market. CONSENT TO ALL?"
[0] https://github.blog/2020-12-17-no-cookie-for-you/
avoiding third-party services/APIs and fickle build tools will get you 99% there. not always possible.
i remember the days when APIs and aggregation was the trend. yahoo pipes was the peak.
Same thing with London and Banksy, btw. Of all the things you could see.
Sometime people really like to complicate instead of keeping things simple. Not just for show off but they genuinely believe something more complicated is better. Better such as it has better security, it has better extendability and is more generic. Even if those features were never in the actual business requirements.
I am amazed no one has written Hello World Microservice Edition. So you can have a fancy React UI, a Gateway, an User service, an Authorisation service, a Notification service, an Audit service, a Pricing service and a Printing service.
with versioning and diffs: https://ftp.gnu.org/gnu/hello/
I'm guessing the WebASM Privacy browser equiv must be: Hello Brave GNU World
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
But the one thing that ultimately adds a lot of unneeded complexity to basically every software project at my work are requirements. That kind of requirement that nobody thought of when the project kicked off. And this kind of requirement that a few months later everyone realizes nobody actually needed. And that you possibly remove after a while. But in the meantime this feature influenced your entire data model or worse.
This is the point where your previously fun work turns into a slog for the duration of said project. Well at least we can still have fun with our hobby projects!
As I understood how performance worked, what's maintainability and minimalism (as a general concept), the code I write became minimal and simpler.
Currently I'm working in a mode which can be called "overgrow and extend". I start with the most simplistic code which satisfies the design and my requirements, then refactor any part which cracks under the design to satisfy the requirements without being hacky. This philosophy works like a charm for me. Coupled with my "needless comments", getting back into context and extending/maintaining the code is easier than ever.
I even started to finish and deploy my personal projects. It's that effective for me.
Now I'm learning live documentation, which allows me to write the documentation of the things I'm working on simultaneously. When things finish I also have a workable documentation as a result.
Good on you for having success with your personal projects!
Those are noble goals; I think the problem arises when devs forget that "change the code" and "replace with something else" are perfectly valid options. Adding a plugin interface and override hooks, just in case they might be needed, for an internal library, then it's a classic case of YAGNI. When an implementation is so configurable that passing it a config is more effort than writing a bespoke implementation, then it may be an example of the "inner platform effect".
I wrote about this sort of thing on StackExchange a few years ago https://softwareengineering.stackexchange.com/a/382229/11211...
In my kindle-clippings-manager (https://github.com/karlosos/kindle_clippings_webapp) I import highlights from Kindle and store them in localStorage. The major drawback is a size limitation (10MB). This should not be a problem in most cases but if you need to store more data then indexedDB (with bigger limits but more complexity) can solve the issue.
Linear (https://linear.app/) uses its sync engine to store the data in Web Storage. With optimistic updates, it feels like an offline app. You can read more about the sync engine here: https://news.ycombinator.com/item?id=36519448
https://herman.bearblog.dev/building-software-to-last-foreve...
Literally why I always choose Windows over Linux, Intel/Nvidia over AMD, air cooling over water cooling, etc. for all my computers.
Life is short, ain't nobody got time for jank no more.
Even worse, if you have an HTML game hosted on itch.io (which uses a cross-domain iframe, for security), Safari just silently discards all Local Storage when you close the tab, with no option to disable this behavior on a specific site.
I know Local Storage is supposed to be just a cache, but I really wish we had opt-in durable storage…
> Safari proactively evicts data when cross-site tracking prevention is turned on. If an origin has no user interaction, such as click or tap, in the last seven days of browser use, its data created from script will be deleted.