Blaze's reactivity is an incredibly nifty feature of Meteor. It does away with a huge amount of boilerplate code and is mostly really nice to work with. However, nothing really comes for free, does it. The problem with reactivity is that unless you do some relatively awkward things, you may easily lose a lot of control over what gets called…

MongoDB's find method allows us to specify a projection, i.e., what fields should be included in or omitted from the result set. Meteor, connected to a database on both the server side and client side, can benefit from using projection in two major and different ways. Published Cursor Projection (Server-side) The benefits of using projection on a published cursor…

When it comes to determining what goes where from the server, Meteor does some pretty cool optimisations to be fast and effective. Yet, I’ve found in certain special cases - especially if you’re deploying to RAM-tight environments such as Heroku or DigitalOcean - it can be surprisingly easy to kill your server if you’re not a bit…

It's a sad fact that Blaze (Meteor's reactive UI library) doesn't play particularly well with contenteditable elements. The corresponding ticket in GitHub is marked as closed but the issue itself is unfortunately far from resolved. This makes implementing e.g. autosave for contenteditable elements quite annoying - say you're throttling the keypress event and saving every two or three seconds.…

In the latest blog post we've touched the topic of parallelism in the Meteor framework using node-fibers. We've shown how to do multiple HTTP requests at the same time. As we've seen, unbounded parallelism in Meteor is relatively easy. There are, however, cases when you wish to limit the degree of concurrency (akin to async's eachSeries). For example when issuing…