When I first encountered Meteor a year and a half ago I was turned off by how opinionated it was. I was a newcomer to Node.js and didn't want to learn about Node with decisions already made for me. This time as I got to know Meteor better I've come to appreciate the choices it makes on my behalf.
script elements like this:
<!DOCTYPE html> <html> <head> <title>Sample page</title> <link rel="stylesheet" href="style.css"> </head> <body> <h1>Sample page</h1> <p>This is a <a href="demo.html">simple</a> sample.</p> <script src="script.js"></script> </body> </html>
client. Meteor bundles, minifies, and creates the DOM elements to include the files in my HTML automatically. I don't even have to refresh the browser when adding a new file to see it update. Magic!
Meteor includes a new authentication technology which doesn't require passwords (nor their hashes) to be stored on the server. How cool is that?
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.