Hacker News new | ask | show | jobs
by krrishd 4403 days ago
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.
4 comments

That is a good reason to stick with Angular.

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.

I've used Meteor for a frontend project (websockets using wamp.ws talking to a hardware box, local databases being websql and indexeddb). Meteor is a build toolchain (minify etc) and a collection of packages, each providing a feature that you can (usually) opt in/out of. Seen this way, Meteor can be used in all sorts of ways, beyond the perceived server & client mongo-only implementation.
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?
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.
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.