Another choice made by Meteor for the developer is Handlebars for templating. Would you prefer to use a different template engine? Too bad. The engineering side of my mind rebels at this restriction ("The reason I write code is to have more options!") but the management side likes it: Meteor pragmatically chose a common solution first while in the background they're inventing a new, more sophisticated technology to replace it later. It's this kind of thinking that gets usable solutions into the hands of developers today, creating a virtuous cycle of attracting mindshare and generating resources for future development, in contrast to technically exciting but still not-yet-usable alternatives like Derby.
Meteor invented its own package manager. "What?!" you cry, yet another one? Didn't Debian already solve the package management problem well enough and isn't npm too young to be replaced so soon? That was my kneejerk reaction. Upon deeper inspection, however, I saw that npm solves only the server side of the package equation and there's still a need to manage packages on the client side. Outside of Meteor I've been using Bower for this but unlike npm it's not a widely accepted solution and it's still impossible to create packages that install code on the server and client side simultaneously. Therefore, Meteor's opininated decision makes sense. Another simple, but appreciated time saver: When including a Meteor package, you don't need to
require it in your code. The globals show up automatically. Pure? No. Practical? Yes.
I enjoyed the experience of creating my first Meteor app and I would recommend it to anyone who wants to create a single page application quickly. What's most exciting to me about Meteor is not just the time saving tools provided today but that the team is also innovating new solutions for improving the web development process in the future.