This is potentially less-than-ideal for a couple of reasons. First, it forces the client to keep a growing number of posts in memory. 10-20 posts probably isn’t a big deal, depending on your app, but if you’re displaying hundreds of photographs (or animated GIFs), this could get pretty annoying. Granted, you can minimize the impact by only loading elements that are visible on screen, but it’s a headache that you don’t have to deal with traditional pagination.
The other potential issue is that, because Meteor is a real-time framework, the server needs to constantly monitor changes to the database and pass along those changes to the client. As the number of documents inside a database query grow, the number of updates being passed back increases as well. I haven’t been using Meteor long enough to know how much of an impact this makes in practice, but updating off-screen data is, at least, a sub-optimal use of bandwidth.
So, how do we work around this?