jedschmidt

i do the same for Content Security Policy: `default-src 'none'` by default, then add what i need when i need it.

agreed. i think the economics of ramen make less sense outside of japan, where it’s more expensive and turnaround is slower because folks linger longer (often to amortize the cost of waiting to get seated in the first place).

this reminds me of a naive and happier time in tech, when i built a game called ramendan with twitter’s open API. you had to eat ramen every day for dinner, and tweet proof with the hashtag #ramendan, link to a photo (this was before twitter supported images), and geotag it so that we could make sure it was after sundown in your timezone.

https://www.pechakucha.com/presentations/the-savory-month-of...

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.

[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

In my experience, as long as a controlled window is communicating with the SW, the connection will remain alive.

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

If there's demand for it, would love to look into that.

Sure, as it could with any part of your app, including wherever your JSON.parse code lives.

Not _quite_ arbitrary; the only code run is that generated by lave. Arbitrary code present in functions is parsed, but not run.

My original HN submission was clearer, but alas didn't go anywhere: https://news.ycombinator.com/item?id=11185365

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.

[1] https://github.com/jed/sheet-down

[2] https://github.com/rvagg/node-levelup/wiki/Modules#storage

I wish `void` would get more love for IIFEs instead of just sitting there in a dark corner of JS, unloved.

    var foo = 'bar'
    var baz = 'bletch'
    
    void function (global) {
      //module pattern code here ...
    })(this)

Having gotten more accustomed to the VM approach over the past year since I wrote this post, I agree.

Are you sure he was saying "ore"? Given the fact that his grammar is otherwise pretty tight, I wouldn't be surprised if he were instead using "ware".

You might also want to consider whether a B Corporation would make sense: http://www.bcorporation.net

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.

    javascript:prompt(0,location.href.replace(/\./g,"\u200b."))._