jedschmidt

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."))._

Gaunt in 128 bytes of JavaScript:

    function(a,b){return a[b="replace"](/./g,a=function(a){return a[1]?String.fromCharCode(parseInt(a,2)):+(a==" ")})[b](/.{7}/g,a)}

http://www.blackhat.com/presentations/bh-usa-08/Hoffman/Hoff...

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.

[1] http://www.flickr.com/photos/tr4nslator/sets/721576332659462...

[2] https://github.com/jed/rndr.me

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.

Does anyone know how often they update their containers for other platforms? The maximum node.js version on Beanstalk is 0.8.21, but the current stable is now 0.10.0.

this is apparently blogspam that embeds the original article from iA:

http://informationarchitects.net/blog/the-web-is-all-about-t...

You're being redirected because JavaScript is disabled. I should make this more clear.

Put your domo code into a function that takes data and returns a DOM object. BAM, there's your template.

Your JavaScript code can only have one global object, I don't see a reason to pass it in instead of finding it for you.

This is great feedback, will definitely look into this.

Thanks for the reference to crate, I'd never heard of it. I'd imagine the pushback on ideas like this is much less in homoiconic lanugages like clojure, since when all is said and done everything is an AST.

I don't know much about Mason, but this isn't a templating engine; it's just a wrapper library on top of the DOM API. Since it doesn't need any compilation or coordination outside of the JavaScript process, it's much less complex, and composes well without passing partials and other cruft into the template data.

This is great feedback.

- The caps are there to prevent global namespace collisions, since the chances of UPPERCASE global variables existing is smaller. I don't want to add lowercase names to the global, but they would be fine on the domo object itself, so maybe I should put both UPPER and lower there anyway.

- The CSS may be more verbose that LESS in JavaScript, but it compiles much faster and there's only 228 of code needed to get it. If you want sugar, just use CoffeeScript and it's probably even cleaner than LESS.

https://github.com/jed/domo/blob/master/docs/index.coffee#L1...

- The STYLE keyword is just there because that's where the "on" function lives. You could assign it to a local variable make the reference shorter.

- Yes, with bare JavaScript this is probably true, but the idea is to make sugar optional. Add your own and it looks like HAML:

https://github.com/jed/domo/blob/master/docs/index.coffee#L3...

I (the author) agree. It's not for nostalgia's sake, but to avoid namespace collisions on the global object.

Right. This entire page could've been rendered on the server. The point is that you can choose the best tradeoff for your app.