That’s not true. findOne is syncronous on both client and server. It’s just that the document you’re trying to find on the client sometimes isn’t there yet (e.g. subscription isn’t ready).
The thing is reactive functions (computations) act like callback since they are called on data change, but findOne give you a result (or nothing) immediately.
I like think is ‘async’ cause it help remember that I cannot expect inmediate result from the call. Is erroneous treat it like a normal ‘sync’ function.
I high porcentage of meteor incomers, me include, bitter this until understand Tracker and reactive approach.
On server side findOne is really ‘sync’, it block the code flow until call return with a ‘valid’ value.
You’re confusing async functions with a function that is being called syncronously when the data isn’t there yet.
If the document is in minimongo, findOne returns it immediately, blocking on the client (albeit for a very short amount of time) until is has done so. If the document is not in minimongo, findOne returns immediately with null (again, blocking until it does so).
The part that is actually async is getting the document(s) into minimongo from the server (usually via pub/sub). When Meteor.subscribe is called, that sends a request for documents off to the server and the client side code keeps running, so Meteor.subscribe is an async function.
Reactive…
The flow of the program is modified, you don’t write imperative code (do A, then B, then C) but more declarative (B depends on A value like this). You don’t bother anymore about “when” (too late or too early…) you code is firing, since in the end it will fire to do something useful when data is ready. Which means you should be prepared for your code to run multiple times, and that should not cause a problem.