
Meteor vs. Angular - tmetzner
http://differential.io/blog/meteor-vs-angular
======
treve
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't think I
would feel comfortable building a large application on it.

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.

But then I'm the type of person who prefers boring and predictable, with a
very big separation between front and back-end concerns.

I'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.

~~~
tedchs
It also depends on MongoDB as your sole backend database. I played with Meteor
when it came out and I concur maybe Meteor is OK for prototypes but for
something production ready I'd rather just use Angular + Google App Engine +
Google Cloud Endpoints.

~~~
goldenkey
Kind of silly that you wouldn't use MongoDB yet you'd use GAE. GAE is a turd,
Google has been struggling to compete in the cloud business and failed to come
out with any value. You get locked into a Heroku-like platform with awful
performance, awful stability, and arcane quotas.

[http://www.carlosble.com/2010/11/goodbye-google-app-
engine-g...](http://www.carlosble.com/2010/11/goodbye-google-app-engine-gae/)

[http://3.14.by/en/read/why-google-appengine-
sucks](http://3.14.by/en/read/why-google-appengine-sucks)

~~~
tedchs
Thanks for the feedback. I would encourage you to note that those blog posts
are from 2010 and 2009, and my understanding is the platform has improved
dramatically in the ensuing 4-5 years. I'm a Linux systems engineer, but for
an app where I'm not going to admin my own infrastructure, I have been happier
with App Engine than other PaaS options.

~~~
goldenkey
No competent Linux admin would use a PaaS. I find it very hard to believe that
you'd rather use GAE instead of a virtual dedicated.

------
krrishd
The thing that has me sticking with Angular over Meteor is that Angular
doesn'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.

~~~
adamnemecek
IIRC that's not quite true. There's the DDP thingy
[http://en.wikipedia.org/wiki/Distributed_Data_Protocol](http://en.wikipedia.org/wiki/Distributed_Data_Protocol)
which should theoretically let you use any backend implementing that protocol.
But I'm not sure if anyone actually uses it besides meteor.

~~~
krrishd
Yeah, but in that case, wouldn't you have to hack on the actual Meteor source
to let it use a different backend rather than Meteor's own provided one?

~~~
jaredsohn
My guess is that if your backend has the same interface as Meteor's, you would
just need to come up with your own deploy script and have it include the
Meteor client bundle. Also, you would lose the ability of sharing any code
between the server and the client.

------
xiphias
I would recommend Meteor _with_ Angular. Although there are some things that
don't work perfectly together, using AngularJS as a frontend and MeteorJS as a
backend works like magic....I loved creating (internal) applications with it.

An example (not written by me)

[https://github.com/tommuhm/angular-meteor-
example/blob/maste...](https://github.com/tommuhm/angular-meteor-
example/blob/master/angular-meteor-example.js)

------
debergalis
One important difference between Meteor's front-end and Angular is how we
track data dependencies and changes. As it happens we've been working on a
Meteor manual and just published the first chapter on Deps, our 1kb library
for doing this.

[https://meteor.hackpad.com/Understanding-Deps-
aAXG6T9lkf6](https://meteor.hackpad.com/Understanding-Deps-aAXG6T9lkf6)

~~~
zackbrown
First of all, Matt, you guys are killing it with Meteor; it's an awesome
framework. Angular is awesome, too. Echoing another commenter on this thread,
"X vs Y" comparisons, which encourage religious tensions, are not super
productive. These framework decisions come down to case-by-case technical
requirements (and personal preference + experience)

All of that said, my favorite thing about Angular is that it's a framework for
building frameworks, and the sky's the limit on how you want to handle just
about every piece of your app. You can set up your own reactive data models in
Angular, for example--but not as easily and immediately (from what I can tell
from this docs link) as you can with Deps.

Would you rather use Heroku or EC2? Write an application in C or Python? Buy
pasta from the store or make it from scratch? Depends on expertise and
requirements.

Sometimes low-level flexibility (e.g. with Angular) is invaluable, since each
project comes with unique requirements that can't always be addressed with
more abstracted, batteries-included solutions. More specifically, sometimes
you end up fighting against batteries-included frameworks when abstractions
prove too leaky.

Sometimes, though, batteries-included tools (e.g. Meteor) make all the
difference between needing to staff one engineer or four, or being able to
write and deploy an app in a few hours instead of a few days.

------
jaunkst
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'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'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.

------
mrcwinn
I would just say that the "X versus Y" 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.

For example, it might be the case that simple, real-time-ish data is very
important. Meteor might be an excellent choice.

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.

X can be better than Y in one circumstance, and must worse in another. Define,
research, pick.

~~~
jasode
>The best way to approach it is to define and understand the needs of your
project, research, and choose.

But reading someone's "X vs Y" is one way to " _research_ " and reading the
factors that the author compares can also feed back into the reader's "
_define and understand the needs of your project_ ". When there are new
technology options, novices often don't have the background to know "what or
how" to compare them. Reading some "x vs y" opinions is part of filling in
that background.

------
findjashua
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?

~~~
joshowens
MongoDB is the only officially supported DB atm, but after 1.0 I have heard
that Postgres will be the next big feature.

------
GUNHED_158
BTW, it is called "AngularJS", not "Angular".

~~~
grumblestumble
.. try telling that to bower. `bower install angularjs` pulls down the public
website / docs / etc. `bower install angular` pulls down the actual framework.

