Live data from Hacker News

Meteor vs. Angular

differential.io

1–10 of 35 posts

Re: Meteor vs. Angular

#2
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.

Re: Meteor vs. Angular

#3
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.

Re: Meteor vs. Angular

#4
post #3

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 per…

You don't have to blur the lines if you don't want to, don't use globals if you want purity.

Re: Meteor vs. Angular

#5
post #3

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 per…

You don't have to blur the lines if you don't want to, don't use globals if you want purity.

I imagine that the further I would go away from Meteor's style of programming and go to two isolated code-bases (front and back) I would also lose a major part of why one would use Meteor in the first place.

Re: Meteor vs. Angular

#6
post #2

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.

I guess Meteor is a good choice for JS-only developers.

Re: Meteor vs. Angular

#7
post #6
post #2

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.

I guess Meteor is a good choice for JS-only developers.

I don't think the issue is so much that the backend has to be JavaScript so much as that the backend has to be precisely what Meteor wants it to be. You couldn't just stick a different JavaScript app conforming to the same interface in the back end — your application has to be more or less monolithic AFAIK.

Re: Meteor vs. Angular

#8
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.

Re: Meteor vs. Angular

#9
post #2

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.

IIRC that's not quite true. There's the DDP thingy 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.

Re: Meteor vs. Angular

#10
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...

Post reply on HN