Meteor vs. Angular

Meteor is still way too magic for me. Seems great for rapid prototyping of real-time applications, and perhaps things like games... But I don&#x27;t think I would feel comfortable building a large application on it.<p>The problem space that it solves is not that hard, it just provides an extremely magical way to go about it. I imagine this makes things a lot harder to change, debug and maintain.<p>But then I&#x27;m the type of person who prefers boring and predictable, with a very big separation between front and back-end concerns.<p>I&#x27;ve been leaning towards the opposite architecture of what Meteor does, creating 3 entirely different layers for 1) core business logic, 2) web backend, 3) web frontend, whereas Meteor seems to want to blur the lines where things are happening.

The thing that has me sticking with Angular over Meteor is that Angular doesn&#x27;t care about your backend or infrastructure. With Meteor, I feel limited due to the tight integration of the server and client. Due to that, I feel like its harder to scale, and perhaps only suitable for prototyping.

I would recommend Meteor _with_ Angular. Although there are some things that don&#x27;t work perfectly together, using AngularJS as a frontend and MeteorJS as a backend works like magic....I loved creating (internal) applications with it.<p>An example (not written by me)<p><a href="https://github.com/tommuhm/angular-meteor-example/blob/master/angular-meteor-example.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tommuhm&#x2F;angular-meteor-example&#x2F;blob&#x2F;maste...</a>

One important difference between Meteor&#x27;s front-end and Angular is how we track data dependencies and changes. As it happens we&#x27;ve been working on a Meteor manual and just published the first chapter on Deps, our 1kb library for doing this.<p><a href="https://meteor.hackpad.com/Understanding-Deps-aAXG6T9lkf6" rel="nofollow">https:&#x2F;&#x2F;meteor.hackpad.com&#x2F;Understanding-Deps-aAXG6T9lkf6</a>

Nice write up. I too have evaluated almost every MV* framework. I started with knockout a few years back and extended it to fit the mvc pattern. Eventually I went all in with angular and have found it ideal for a few reasons, one which you mentioned; it&#x27;s decoupling from a full stack. I currently have built rails application templates to generate an ideal angular full stack, and also rake tasks to compile the code base into Cordova mobile builds. I can say that without a doubt there is no going back. Complete decoupling of the client and server is the Golden goose. As far as being more meteor like it&#x27;s pretty easy to spin up a websocket layer for the client and server. I personally think a Swiss army knife is a good representation of angular due to its flexibility to integrate with existing stacks. One could in theory slowly replace the entire front-end of any stack.

I would just say that the &quot;X versus Y&quot; approach to frameworks (as opposed to tools) is not very productive in a lot of cases. The best way to approach it is to define and understand the needs of your project, research, and choose.<p>For example, it might be the case that simple, real-time-ish data is very important. Meteor might be an excellent choice.<p>It could instead be the case that lock-in (and Meteor is definitely encouraging lock-in on both sides of the http request) is a concern for your team, and you feel it important to have flexibility or maturity on the server-side. Meteor might be a terrible choice.<p>X can be better than Y in one circumstance, and must worse in another. Define, research, pick.

From a cursory glance, it seems to me that Meteor syncs MongoDB instances on the client and the server, and therefore can only be used with MongoDB as the database. Is that correct, or is there any way to use it with a Postgres app?

BTW, it is called &quot;AngularJS&quot;, not &quot;Angular&quot;.