11–20 of 35 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
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…
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.
One of the great things about Meteor is the shared data between a server side mongodb instance and a mini mongodb running on the user's browser. If you are not or can not use mongodb for your app, at least for right now that seems like a deal killer for Meteor.
Meteor requiring sticky sessions can be another negative for scaling.
All that said, for apps that are not likely to have to scale much Meteor is really a sweet spot - everything you need for efficient development. I have read several articles about scaling Meteor, but I have never had a Meteor app that would not run well on a single server.
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.
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…
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…
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.
Earlier quoted context omitted.
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.
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?