i went super deep on 140-byte code golfing[1] back when twitter was taking off, and it changed the way i think about code. for a brief while we had a small community collaborating on byte-squeezing techniques[2], and i was constantly amazed at the creativity that this constraint brought about, from mandelbrot renderings to sudoku solvers. possibly the best part was more than a decade later when i found my golfed UUID implementation[3] deep in my employer's codebase.
A service worker would work fine; the connection would be instantiated from the SW and each window/worker could communicate with it via navigator.serviceWorker.
Instead of adding a non-standard API to opt-out of existing networking functionality, it would be great to see a lower-level networking primitive to unlock these kinds of use cases. I wrote more (with a proof-of-concept) here: https://readable.writable.stream
Absolutely. The downside of running a full-blown eval() exists in JSON too, it's just that the eval() there is taking place in the reviver function, which requires a lot more coordination than a self-contained file.
As far as efficiency, I'd think for most uses the issue would be on the JSON.parse end. In this case, lave might be more efficient, since JSON reviving often ends up creating temporary objects that need to GC'ed after reification.
My situation is for an intranet environment, so I suppose I could just ask nicely that they don't change validations. But chances are most of my target users aren't familiar enough with Google Spreadsheets to even get that far.
I really like the idea of using Google Spreadsheets as a quick and familiar GUI for entry or querying on data sets, as long as you understand the tradeoffs (write latency isn't great and they max out at 400,000 cells).
But this is especially nice when you build a layer on top of Google reduces lock-in, instead of adding another proprietary API. This is what I did with sheet-down[1], which turns a Google Spreadsheet into a LevelDB-compatible data store that can be swapped out with a file system or other compatible backend[2] once you outgrow Google.
tl;dr: URLs with all periods prepended by a zero-width space evade Twitter DM malware detection, but are still recognized (and clickable) by Chrome, Firefox, Safari, and Twitter's own client.
This is an awesome solution for folks using Backbone and who don't mind a tight framework coupling.
But if you're not on Backbone, or don't want to add another constraint to how your app is built, it's pretty easy to set up your own PhantomJS server; I presented on this very topic at TXJS this week[1], and created a library[2] that makes it a snap to set up.
As a fairly regular user of Punchfork, I definitely wish it were still around, but this feels self-entitled.
Let's not forget that the data Punchfork is letting users take out is the exact information they put in: a list of liked recipes. The original recipe data is just one click away.
I'm not sure how this is any different than a personal Twitter archive; it contains only your tweets, not those of the folks you interacted with.
I (and all Punchfork users, I assume) received a notification on January 3rd, including the following:
Initially, support for Punchfork will continue, but
we will soon be retiring the Punchfork site, API and
mobile apps. We believe that a unified destination
benefits our users in the long run, and the Punchfork
team (me) will focus on contributing to Pinterest as
the premier platform for discovering and sharing new
recipes and other interests on the web.
EDIT: Gmail binned this email in "Promotions"... I wonder if that explains why some didn't see it?
[1] https://youtu.be/JsAetmgJRss?si=AxIFySX7ktzu5GL5&t=193
[2] https://github.com/jed/140bytes/wiki/Byte-saving-techniques
[3] https://gist.github.com/jed/982883