A lot of it has to do with the Minimongo library, the pub/sub subscription, whether there are classes being created, which rendering library you’re using, and how many components you’ve created.
The browser can certainly handle many thousands of JSON objects… just ask anybody who does mapping or graphing. But to cleanly render those objects, you need a functional programming library that uses pure functions. Blaze’s rerenders just don’t cut it. But D3 and React can.
So, if you’re just using D3 or React, it’s clearly easy to have an array of 1000 or 10000 JSON objects, and the browser renders super fast. So why does Minimongo bog down? Well, it’s monitoring the subscription and handling optimistic UI. For every component you create, there will be a Tracker item put on the heap that’s watching to be invalidated. It’s all those Tracker objects that bring it down an order of magnitude.
You can use
Meteor.call() functions to bypass the Minimongo cursor, and load up thousands of records client side; but you’ll loose reactivity and synchronization with the database.
tl;dr - your max of 225 documents isn’t simply a max of documents in the browser. It’s the max number of synchronized documents that will be synced with the database.