Why would you need to understand the whole code base of Meteor to write an app? I mean, you don’t need to know everything about a car to be able to drive it.
I’m currently rewriting the client files from this example todos app into manuel:viewmodel to make a short tutorial out of it. It makes it use much less lines.
As for the Todos app itself. If it is an example app for the Guide, it should utilize the best practice and knowledge that we can find in Guide and Docs. Yet, we can find there Meteor.defer() which still isn’t covered in the docs even if the Github issue asking to add it will be 2 years old in May.
Todos is not a “hello world” app, it tries to be as complete as possible by implementing routing, server-side methods, account handling and more, so you can learn more from it
when you don’t count tests, it’s 2245 LoC. While that’s still a lot to chew on, I personally think it’s managable.
if one is looking for a more “hello world” type of example app, there’s always simple-todos which does it’s job perfectly
setTimeout used in this context feels like a hack (or actually is a hack). Meteor.defer() sounds more like there is an official feature for such a use case. I agree there’s no big benefit, but the least is to decide on one way and stick to it both in docs and recommendations like guide or example apps.
Maybe Meteor.defer should also be discussed in the Meteor Guide with common use cases for client (wait for dom update) and server (defer async function like send mail).
and then back to focus on my SF based startup, Clozer.