Learning Meteor.js [Part 46]: Parting thoughts

After 45 posts, this series has come to an end. The sample application is live and it allows a stay-at-home dad like me to plan the week's meal and head out to the store with a shopping list :)

To wrap this up, here are some comments regarding meteor.js:

• Excellent for Prototyping. The speed of development is amazing. Just by typing 'meteor' in the command line you get browser auto-reload and mongodb hooked up for live updates so you can start developing fast. There are many atmosphere packages that can help to build an app faster and regular npm support to bring anything else that might be missing.
• Programming model leads you to the pit of failure. By making it super fast to prototype meteor sacrifices clarity of how to develop an application for the long term. There are many ways to do the same thing, but some are insecure or dangerous and it is not always clear which one is right. Especially, since the approach that the tutorials teach you are often not recommended for production. This creates a programming model that is full of pitfalls and gotchas and many people in forums confused.
• Fibers. Meteor's fibers implementation makes it natural and simple to write server side methods by eliminating or reducing callbacks. Bravo.
• Atmosphere.js. Finding meteor packages is not simple. Many don't work at all and then there is the problem of figuring out what meteor version they target. It doesn't help that some are just wrappers for libraries that you could get via npm. They created their own package repository whose contents cannot match npm, so now there is a fragmentation of what goes where.
• Eventual consistency. It 'just works', it enables a good user experience and it saves hours of development. The fact that methods are run on the client and the server can be confusing but once you get the hang of it the benefit of the experience is worth it.
• Pub/Sub Document Merging by Default. I mentioned in a previous post why I think this is a bad idea.
• Validation. Thanks to the use of node.js you can reuse exactly the same code in the server and the client to run validation. The same can apply for server methods if you want.
• Documentation is a mess. There are so many conflicting advice that is pretty much a dice roll to see if what you read applies to the version of meteor that you are using and if there won't be some unintended consequence that will come back to bite you later.
• Real time updates. I didn't need this for my sample application, but the fact that all connected clients get updates as the database is updated can be super useful. You get this for free, which again can save a ton of development time and may very well be a reason to choose meteor.js if your project needs this.
• Blaze is HORRIBLE. Blaze is the front-end rendering system of meteor and I grew to hate it. Just to name a few: the primitives available are very limited which forces you to write helpers for very simple evaluations, when hooking up events it is never clear what gets passed as the 'this' argument or how to get to the data of the originator, the dynamic template won't let you easily pass arguments to the child template. I would not recommend this to anyone. After I started writing my application I realized that you could also use react, and now I wish I had used it instead.

So there you have it, my brain dump of meteor after using it daily for two months. Thanks to anybody that made it this far in the series. The source code for the application is here and the live site will remain in heroku as I use it for my recipes and meal plans.