Meteor vs. Angular(differential.io)
differential.io
Meteor vs. Angular
http://differential.io/blog/meteor-vs-angular
9 comments
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.
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://3.14.by/en/read/why-google-appengine-sucks
http://www.carlosble.com/2010/11/goodbye-google-app-engine-g...
http://3.14.by/en/read/why-google-appengine-sucks
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.
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.
I'm curious about your choices here, I would not really trust MongoDB with my data for a few reasons, but at the same time, building on Google's services seems even more risky - if they shut down those services (which is not inconceivable), you'd be facing a pretty nasty rewrite + migration to a new platform.
One cool thing about all of Meteor's magic is that it's quite understandable. Chris Mather's EventedMind and Arunoda's MeteorHacks are good resources for looking behind that curtain.
In my experience, once the magic becomes more of an understanding of the Meteor-y way of doing things, then debugging and maintaining isn't any harder than a more traditional architecture.
I wouldn't say that Meteor is a suitable framework for any type of app, but I would say its design is suitable for a lot more than just prototyping and games (with a pre-1.0 caveat).
In my experience, once the magic becomes more of an understanding of the Meteor-y way of doing things, then debugging and maintaining isn't any harder than a more traditional architecture.
I wouldn't say that Meteor is a suitable framework for any type of app, but I would say its design is suitable for a lot more than just prototyping and games (with a pre-1.0 caveat).
I have to agree with separating the concerns. Different patterns for each are better. This leans towards higher flexibility and understanding of the domain.
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.
Having tried to build several businesses where I separated concerns across code bases, it always ended up painful in the end for me.
Perhaps being an older (nee wiser?) developer, I could pull the idea off in a more nuanced way, but I bet I will still hit painful points down the road.
Perhaps being an older (nee wiser?) developer, I could pull the idea off in a more nuanced way, but I bet I will still hit painful points down the road.
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.
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.
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.
[deleted]
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...
An example (not written by me)
https://github.com/tommuhm/angular-meteor-example/blob/maste...
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
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.
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.
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.
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.
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.
>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.
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.
I would master your tools and somehow afford yourself the luxury to build things just for those tools. Fortunately meteor is opening up possibilities for a whole new world of realtime apps. Forget angular if u can start from scratch and build new realtime stuff. The closest option is React combined with maybe firebase or something. But even then reacts way of defining HTML inline (compiled with jsx or standard) doesn't compare to how meteor uses HTML templates which a designer can easily edit like usual. As great as react is, nobody wants to code inline HTML. And you don't have to in order to get the same effect.
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?
MongoDB is the only officially supported DB atm, but after 1.0 I have heard that Postgres will be the next big feature.
BTW, it is called "AngularJS", not "Angular".
.. try telling that to bower. `bower install angularjs` pulls down the public website / docs / etc. `bower install angular` pulls down the actual framework.
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.