111–120 of 191 posts
I think "single HTML file" sets up a certain expectation that a five-thousand-line long HTML file with ~3500 lines of embedded JS doesn't really live up to. I mean, hey, everything can be a single HTML file if you embed the bundle inline in your HTML! Cool project, though - don't mean to take away anything from it.
I wish there was some browser solution for apps like this where you could save and share your app state between your own devices, and push/share that state with others, all without any server backend involvement e.g. so you could have a Kanban board shared with others and the state would be stored locally and/or in bring-your-own cloud storage. There's so many apps like this that could be simple, but for robust state…
`roamingStorage` as a relative to `localStorage` sort of like Windows' "Local App Data" versus "Roaming App Data' would be nice to have in theory. Of course even if you kept it to the simple KV store interface like `localStorage` you'd need to define sync semantics and conflict resolution mechanics. Then you'd have to solve all the security concerns of which pages get access to `roamingStorage` and how it determines…
It would be great to have this standardized. Custom two way syncing is a nightmare to implement correctly, and it doesn't make sense for apps to have to keep reinventing the wheel here.
I think "single HTML file" sets up a certain expectation that a five-thousand-line long HTML file with ~3500 lines of embedded JS doesn't really live up to. I mean, hey, everything can be a single HTML file if you embed the bundle inline in your HTML! Cool project, though - don't mean to take away anything from it.
> I mean, hey, everything can be a single HTML file if you embed the bundle inline in your HTML! Yes, they could be. And then they would have the same super power is this file: you can put it on a flash drive and run it anywhere with no setup or installation.
I wish there was some browser solution for apps like this where you could save and share your app state between your own devices, and push/share that state with others, all without any server backend involvement e.g. so you could have a Kanban board shared with others and the state would be stored locally and/or in bring-your-own cloud storage. There's so many apps like this that could be simple, but for robust state…
You can already do this using things like the Chrome Storage APIs (obviously chrome only, and you need to be signed in, and bundle an extension) https://developer.chrome.com/docs/extensions/reference/api/s...
> If syncing is enabled, the data is synced to any Chrome browser that the user is logged into. If disabled, it behaves like storage.local. Chrome stores the data locally when the browser is offline and resumes syncing when it's back online. The quota limitation is approximately 100 KB, 8 KB per item.
Earlier quoted context omitted.
What's wrong with that statement? Can you access the filesystem without a dialog?
The point is that you can save the file and then use it offline. The exact set of clicks to make that happen are completely irrelevant to the core point.
I'm very color oriented, so my forked version does colors to help me organized. (Yes I've sent it in as a pull request).
I hope any Scrum Master who comes across this thread takes the absence of those terms as an indicator of the value of those things and all the related feature bloat that bedevils Agile project management tools.
I really think we are as developers underusing setups like this. If you could somehow figure out a simple but effective sync between devices then that would be able to cover many use-cases. Maybe we just need an sqlite with better support for replicas? Then people have one tiny server with a bunch of sqlite’s to which the apps can sync?
CouchDB + PouchDB
I have it setup self-hosted, and as long as I have internet I can connect to it and update it. Of I don't have internet I can browse the contents as per the most recently cached version.
(I can also save it to a single HTML file and back that up in numerous off site locations).