- The best thing by far is sharing the same code for both client and server. It is as good as it sounds, at least as far as productivity and having a small codebase goes
- Everybody is worried about security, but they got it covered. For each collection you can filer who can publish/insert/update or delete. Each go through a filter you attach a callback to, where you have the userId at hand and can easily only allow the owner of a document to be able to update or delete it. Or just as easy publish (for read) only the documents that a user owns, for all regular users, and publish all of them for an admin user.
- It takes a while to create an organized structure though, there is a loading order for certain folder names, but basically everything that is in your project will be loaded in the project asynchronously, w/out having any control on the order. This makes it painful when dealing with inheritance, but in the end you get around it using the folder order of loading they provide and using the Meteor.startup callback, where you can assume all files have loaded
- Another thing that I found a bit counter intuitive at first is that everything is template oriented. Usually you have a module of some sort, which loads a template. Here you have a template, which has _code_ attached to it. It's very easy to go the spaghetti-code no-framework JavaScript way. But if you like having control and are able to create a scalable pattern for modules/widgets, it becomes a very powerful tool