What does HackerNews think of lz-string?
LZ-based compression algorithm for JavaScript
You should definitely consider adding save to / load from localStorage, IndexedDB, or URL.
Nice thing about URL is you can send pages to other people like this:
https://unli.xyz/tabsender/?links=%22open%20a%20bank%20accou...
Or use LZString https://github.com/pieroxy/lz-string like this:
https://unli.xyz/html/edit.html?t=%22DwBwfALghgTgXlAdsA9OYAz...
An accidental page refresh shouldn't eliminate all your TODOs :/
For local net, setting up pi-hole is do-able, whilst setting it up over a VPN involves a bit of additional tooling.
A 100% uptime DNS on public internet is tricky, but if you're okay with just DoH [0], the https://workers.dev free-tier would you give you a 100% uptime "anycast", low-latency DoH enough for a single device's worth of queries for a month. At $5, you'd have enough for a 100 devices.
I've one setup with adblock forwarding queries to 1.1.1.1 and I see e2e latencies as low as 50ms regardless of location. This setup is a bit involved: You'd need to convert blocklists (the one I use has a million entries) to either a long-string, custom LZ-compress it (~6 MiB) [1] and do a boyer-moore needle-haystack search on it for incoming questions (v8's native String#index impl uses a variant of boyer-moore) [2], or use a json-map at a cost of higher RAM usage but blazing-fast lookups (~25 MiB), or use succinct radix-trees for optimal RAM usage (~1.5 MiB) but relatively slower lookups, or use bloom-filters with low false-positive but fast membership queries at extremely frugal RAM usage (~200 KiB) [3].
That said, the simplest way to ad-block would be to point the workers instance to adguard-doh.
[0] https://news.ycombinator.com/item?id=21598413
[1] https://github.com/pieroxy/lz-string/
[2] https://stackoverflow.com/questions/5562297/fast-search-in-c...
I built something similar[1] a while ago, but the urls are still too long for sharing without a shortener. I'm using lz-string[2].
Also, if you are storing larger strings in local/sessionStorage, websql or indexdb, you should use lz-string[1] to try to minimize storage impact.
Aside: if you want something with a nicer interface for underlying storage you may want to look at pouchdb[2], which has a localized couch interface and supports remote synching to coudchdb, which is pretty nice.
[1] https://github.com/pieroxy/lz-string [2] https://pouchdb.com/
Done naively, it will have the same problems others mentioned here: it barely shortens the URL. However, in the case of my specific app - a browser for data sets for single cell RNA sequencing - the state is largely dependent on the data set being viewed, and the data set is unchanging. What that means is that we can "externalise" the data being referred to, to pre-transform my JS object (which is an object tree) to nested arrays with integers (so a kind of "array tree") that use the data set as a look-up to reverse the operation. The latter is already a lot shorter when stringified, but also more compressible: the character set is limited to ten digits, commas and square brackets, and different values may be transformed into the same numbers, being distinguished by their position in the array tree.
To make this operation easier, I created a few helper functions to declare a "schema" that creates a recursive function for transforming the original JS object to said array of arrays, and vice-versa:
https://gist.github.com/JobLeonard/a47692a1f77bebc06c2518f32...
As you can see in the gist, that transformation shrunk a URL of 2466 characters down to a (admittedly still crazy) 638 characters.
I was thinking on putting it on NPM but it looked so specific in its applicability that I haven't bothered turning it into a proper package yet.