So, basically you're saying it's OK that the abstraction layer for RethinkDB creates nasty code because it's native JS? I don't agree. I think nasty code is never OK.

Why can't the RethinkDB abstraction layer just be better? Why isn't:

    var dateFilter = new Date();
    dateFilter = dateFilter.setDate(dateFilter.getDate() - 30);
    rdb.table('users').get([ { column: signup_date, gt: dateFilter } ]).each(function (err, user) {
        // Do stuff
    });

Possible? That's just off the top of my head how I would do it in a way that's native JS and far better than what's presented in the article.

You can do this in RethinkDB:

    r.table('users').filter(r.row('signup_date').gt(signupFilter)).run()

Using an anonymous function like in the first example is optional. `r.row` can be very convenient. In this case, you only need to use `r.row` because you're using the `gt` comparison. If you're just doing a direct match, you can use this syntax:

    r.table('users').filter({signup_date: dateFilter})

Maybe we can agree that we have different definitions of what 'better' is. I can understand the design decisions and trade-offs that would likely have been considered in designing the API as presented.

I'm also a bit wary of trying to introduce too much 'magic' just to make things convenient.

Doesn't look like your solution would compose very well. You would need a solution to combine arbitrary terms in a nice way.