[subpixel]

That's a good question. I've been learning and using Meteor for a few months and my projects do not require reactivity at their core.

Meteor is built around reactivity, and there is some overhead built in to the platform to make it possible, but it's pretty easy to design things so your app isn't overloaded by trying to "real time all the things".

The simplest step is to structure publications so as to deliver the least amount of reactive data needed at each step of the user experience. Another important approach is to understand what forces re-computations and re-renderings and try to minimize them when you can.

It's also possible to serve non-reactive data (meteor-dumb-collections) and obviate many performance concerns related to reactivity.

The speed and relative ease of working with Meteor makes this approach well worth it to me.

Also worth noting is that many of the production apps built with Meteor are not billed as a "real time solution to x". I suspect they have also spent a good amount of time designing around reactivity so they only take advantage of it where it's useful.

[mmikeff]

Thnx, good suggestions