[Image via Meteor]

We're all pretty excited about playing with Meteor. There are number of interesting things about the technology that allude to great promise. Plus, it is a Shiny New Thing, with lots of venture backing so it seems like the next big thing.

However, even the Shiniest of New Things will have some unvarnished spots. Here are Meteor's:

1. Steep Learning Curve

Meteor relies today on a series of underlying technologies that each in turn have significant learning curves. MongoDB is growing in popularity but not really mainstream. jQuery, node.js, CSS are all web technologies that have been around, but have never been bundled quite the way Meteor does things. Additionally, it takes awhile to wrap a new developer's head around Meteor's symmetric realtime data model. While there is the notion of the client calling the server in a traditional way, that's more for specific actions rather than the typical usage model.

2. Application Spread Across Multiple Tightly Coupled Files

There are various Meteor parts that must in perfect alignment for everything to work well, due to symmetric nature of the data. A change in schema requires changes in the client, server and template code, all of which must be wired-up by hand. Since there is no checking by the tools, any misspellings are ignored and do not produce error messages. Instead, it simply doesn't work, with no clue as to the cause, except perhaps a problem in the Chrome JavaScript console window. This also makes merging parallel development efforts potentially problematic. Which leads me to unvarnished spot number 3:

3. Debugging

Server-side debugging is a real problem. Some people have managed to cobble together a debugger, but it looks painful. Thank goodness for Chrome's developer tools. They are effectively the client side debugger for Meteor. A Meteor developer will spend a lot of time in the Inspector.

4. Excessive Server Round Trips

It appears that the client is round-tripping to the server every 10 seconds. On a mobile device, or over a slow connection, where the locally cached symmetric model would be most useful, utility is questionable. We have not run low-bandwidth tests yet. We'll see. In the meantime, I can't leave a mobile browser window open to a Meteor site as it consumes a lot of resources.

5. Maintenance Burden with Complexity.

As the application grows in complexity and scope, it may be very hard to maintain. All classes and templates are in a single high level namespace so collisions could occur without attention.

It's not all bad, is it?

No - the symmetric model definitely has multiple advantages over the alternatives or writing our own. Meteor is fun for prototyping as changes are effortlessly immediately visible. Whether it is viable in a production environment remains to be seen. The model of realtime rich client web interfaces certainly seems interesting. It's been attempted many times with client side plugins, Flash being the most popular example. Meteor's approach has potential, but lots of hurdles still to cross.