[dgreensp]

Joe, your criticisms are spot-on (I work at Meteor), though I feel you are not comparing Meteor to any existing framework, but rather to Meteor in a couple years. Most web developers are quite used to getting by without reactive templates, bidirectional binding, and server-side rendering (which are only just starting to be used together), and in what framework do efficient client-side database indexes (which we haven't implemented yet) come standard, let alone map-reduce? What's wrong with a better-than-REST protocol that is more or less like REST in the worst case?

If you're objecting to the principle of offering the Mongo API or HTTP.get on the client when it's not exactly the same API, we feel the benefits outweigh the costs. The client-side functionality will only get better over time, though there will always be some things you can only do on the server.

Since 3 touches on my area: We're fixing the unstable DOM problem with fine-grained DOM updates. Also, the flatness of Session is not related to how dependencies are tracked. Meteor has a better dependency-tracking system than Angular or Ember; it's more flexible and doesn't require annotations to tell the framework what's happening.