I recently used the Meteor framework to create a demonstration to do list manager. It was the first time I've used Meteor so I have an opportunity to reflect on my experience.


Meteor is a highly opinionated front- and back- end JavaScript framework for creating single-page applications. Many of the choices it makes are the right ones for reducing waste in a typical web development cycle.

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.

For example, if I want to create a web page with CSS and JavaScript files, I would traditionally have to write it with link and script elements like this:

<!DOCTYPE html>
  <title>Sample page</title>
  <link rel="stylesheet" href="style.css">
  <h1>Sample page</h1>
  <p>This is a <a href="demo.html">simple</a> sample.</p>
  <script src="script.js"></script>

With Meteor, I'm able to just throw the CSS and JavaScript files into a folder on the server named 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.

One of the huge wins of an all-JavaScript framework is that you can write code once and have it run on both the server and the browser, such as for schema validation. Yay! However, this symmetry falls down a notch because of Meteor's choice for mitigating callback hellFibers, which unfortunately work only on the server, unlike promises which work everywhere.

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.