What next? Crosswords in the paper?

I don't understand why designers refuse to pay attention to typographic guidelines. 95 characters per line is not very readable. To be fair, Wikipedia already suffers from this problem. Between 100-character lines and sans-serif body copy, Wikipedia's current typography is abysmal.

Otherwise this concept is fine. I'd love to see Wikipedia reset in Meta Serif or Tisa at 66-72 characters-per-line.

Reducing the number of characters per line on Wikipedia is as easy as making your web browser narrower.

You'd be surprised how many times I have to fire up the Dev Tools on websites just to have a sane line-length.

You may want to install Stylish, create an empty stylesheet with sth like

  html * {line-height:170%;}

and enable it when needed - that's what I do from time to time; I also have one with

  html * {color:black !important;}

and one with

  html body, 
  html div,
  html span,
  html p 
   {font-family:Georgia !important;}

With this, tightly packed gray-on-gray websites with unreadable typeface no longer bother me.

I totally wouldn't be intimidated. We all just love what we do. The best way to get a job is often to get to know the folks on the team, hack with them on projects. I'd really hate to work at a place that I felt was exclusive.

Oh I didn't mean to imply it was exclusive, just that I'd feel like I was out of my league. Like I've built a few things with D3 but I still find myself getting confused sometimes, and I've gone through some of David Nolen's clojurescript posts / tutorials and I'm still not 100% clear on the advantages of core.async...but then again I don't use them all that often either.

Well, if you ever wanna chat about core.async or PourOver or jobs or life, I'm more than happy to do so: erik.hinton@nytimes.com Nolen's also a great guy and really serious about helping folks out with stuff like core.async. I'm sure he wouldn't mind jumping in an IRC chat to guide you along!

This looks really cool. I wouldn't say PourOver is focuses on speed as much as focused on being fast enough to get 60fps for 100k items. Cheers!

There are some benchmarks against the base underscore filter methods in the tests. These are what Backbone uses by default. However, the real utility of PourOver is less in its raw speed -- I'm sure that it could be improved by smarter folks than I -- but in the patterns it abstracts. I hope you find it useful.

Hi, all.

A lot of folks are asking for a demo and, you're right. I should have included one. My apologies. I'll get to working on one as soon as I can.

In the meantime, I encourage readers to check out the source for http://www.nytimes.com/interactive/2014/02/02/fashion/red-ca... That's probably the clearest "demo" of PourOver at the moment.

More to come!

Thanks for doing your 'open source gardening'¹ so exuberantly!

I didn't see any contact info on your profile to let you know that the proportion of folks here using Ghostery² or Disconnect³ is probably higher than normal. Installing one will reveal how things break when JavaScript libraries [usually orthogonal to page functionality] are blocked.

--

¹https://news.ycombinator.com/item?id=7593242

²https://www.ghostery.com/

³https://disconnect.me/

Crossfilter was absolutely the inspiration. I just wanted to make a Crossfilter that worked with the arbitrary boolean composition, could be dynamically added to and updated, and supported some of the less numerical patterns I was encountering.

Coolies =).

Would you ever add some of the Crossfilter functionality, to make it easy for people to plug in their own data to PourOver?

I would absolutely like to add a Crossfilter Filter type. I'd even accept a pull request ... ;)

Oh this is great! I really should port something like this to the docs.

This is exactly what PourOver offers. You can chain filter results to any boolean complexity, as well extend the default filter types to optimize indexing and caching. Indeed, PourOver was trivial to make, an outgrowth of the very pattern you define above. PourOver is just an attempt to scrap that boilerplate, allow for the queries to be indexed, combined with sorts, and automatically rebuild when the collection changes.

Thinking about it more, I believe that my visceral reaction was to the imperative nature of the library. I was imagining trying to code something that generated a filter (e.g. PourOver.makeExactFilter("mythology", ["greek","norse"]);) and it seems like it would be unnecessarily complex without data-binding propagation/invalidation.

If I wanted to add "roman" mythology to that filter I would imagine something like:

    var mythologies = ["greek", "norse"];
    // ... create a collection with filters
    mythologies.push("roman");
    PourOver.makeExactFilter("mythology", mythologies);

But you don't get that last statement for free, nor the one where you join it into a collection, nor do I see a way to replace the previous mythologies filter. Any time you need to reprocess a filter you've got to run it through a series of imperative actions triggered from one of the events, and possibly throw away the collection and regenerate it (if you can't remove disjoint filters).

I would be pushing for a Object.observe/dirty checking/get-set version of this to take PourOver to the next level of utility. (?/Angular/Ember)

I think I'm a little confused. Why wouldn't you have just added the "roman" possibility from the get go? Could you provide an example of a situation when you don't know the universe of possibilities in advance?

If the user adds one, or new data enters from an outside source (pub/sub, sockets, etc)

Alright, this is a great point. It would be trivial for me to add addPossibilities. I think I'll do that! Thanks. This will really help for using PourOver to power tagging selection fields where you can ... add possibilities!

Exactly what @rattray said. It's something you get nearly for free in data-binding world and is much harder to accomplish in imperative code. I wish you luck, and make sure you blog about it when it's done! (I want to see how it's implemented.)

"If you are not paying, then you are the product" is not logically equivalent to "if you are paying, then you are not the product". !A -> B != A -> !B Denying the antecedent.